draft-ietf-mboned-ssmping-06.txt   draft-ietf-mboned-ssmping-07.txt 
Network Working Group S. Venaas Network Working Group S. Venaas
Internet-Draft UNINETT Internet-Draft UNINETT
Intended status: Standards Track November 3, 2008 Intended status: Standards Track December 2, 2008
Expires: May 7, 2009 Expires: June 5, 2009
Multicast Ping Protocol Multicast Ping Protocol
draft-ietf-mboned-ssmping-06 draft-ietf-mboned-ssmping-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009. This Internet-Draft will expire on June 5, 2009.
Abstract Abstract
The Multicast Ping Protocol specified in this document allows for The Multicast Ping Protocol specified in this document allows for
checking whether an endpoint can receive multicast, both Source- checking whether an endpoint can receive multicast, both Source-
Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also
be used to obtain additional multicast related information like be used to obtain additional multicast-related information such as
multicast tree setup time etc. This protocol is based on an multicast tree setup time. This protocol is based on an
implementation of tools called ssmping and asmping. implementation of tools called ssmping and asmping.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5
3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6
4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 11
5. Message types and options . . . . . . . . . . . . . . . . . . 11 3.4. Message Types and Options . . . . . . . . . . . . . . . . 11
6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 13 3.5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 13
7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14
8. Recommendations for Implementers . . . . . . . . . . . . . . . 15 5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 6. Recommendations for Implementers . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
The Multicast Ping Protocol specified in this document allows for The Multicast Ping Protocol specified in this document allows for
checking multicast connectivity. In addition to checking reception checking multicast connectivity. In addition to checking reception
of multicast (SSM or ASM), the protocol can provide related of multicast (SSM or ASM), the protocol can provide related
information like multicast tree setup time, the number of hops the information such as multicast tree setup time, the number of hops the
packets have traveled, as well as packet delay and loss. This packets have traveled, as well as packet delay and loss. This
functionality resembles, in part, the ICMP Echo Request/Reply functionality resembles, in part, the ICMP Echo Request/Reply
mechanism, but uses UDP RFC 768 [2] and requires both a client and a mechanism [2], but uses UDP [3] and requires both a client and a
server implementing this protocol. Intermediate routers are not server implementing this protocol. Intermediate routers are not
required to support this protocol. They forward Protocol Messages required to support this protocol. They forward Protocol Messages
and data traffic as usual. and data traffic as usual.
The protocol here specified is based on the actual implementation of This protocol is based on the current implementation of the ssmping
the ssmping and asmping tools [4] which are widely used by the and asmping tools [5] which are widely used by the Internet community
Internet community to conduct multicast connectivity tests. to conduct multicast connectivity tests.
2. Architecture 2. Architecture
Before describing the protocol in detail, we provide a brief overview Before describing the protocol in detail, we provide a brief overview
of how the protocol may be used and what information it may provide. of how the protocol may be used and what information it may provide.
The typical protocol usage is as follows: A server runs continuously
to serve requests from clients. A client can test the multicast The typical protocol usage is as follows:
reception from this server, provided it knows a unicast address of
the server. It will then send a unicast message to the server asking A server runs continuously to serve requests from clients. A
for a group to use. Optionally the user may have requested a client has somehow learned the unicast address of the server and
tests the multicast reception from the server.
The client application will then send a unicast message to the
server asking for a group to use. Optionally a user may request a
specific group or scope, in which case the client will ask for a specific group or scope, in which case the client will ask for a
group matching the user's request. The server will respond with a group matching the user's request. The server will respond with a
group to use, or an error if no group is available. Next, for ASM, group to use, or an error if no group is available.
the client joins an ASM group G, while for SSM it joins a channel
(S,G). Here G is the group specified by the server, and S is the Next, for ASM, the client joins an ASM group G, while for SSM it
unicast address used to reach the server. joins a channel (S,G), where G is the multicast group address
specified by the server, and S is the unicast address used to
reach the server.
After joining the group/channel, the client unicasts multicast
ping requests to the server. The requests are sent using UDP with
the destination port set to the standardised multicast ping port
[TBD]. The requests are sent periodically, perhaps once per
second, to the server. These requests contain a sequence number,
and typically a timestamp. The requests are echoed by the server,
which may add a few options.
For each request, the server sends two replies. One reply is
unicast to the source IP address and source UDP port of the
requesting client. The other reply is multicast to the requested
multicast group G and the source UDP port of the requesting
client.
After joining the channel, the client unicasts multicast ping
requests to the server. The requests are sent using UDP with
destination port set to the standardised multicast ping port [TBD].
The requests are sent periodically, e.g., once per second, to the
server. The requests contain a sequence number, and typically a
timestamp. The requests are echoed by the server, except the server
may add a few options. For each request, the server sends two
replies. One reply is unicast back to the source IP address and
source UDP port of the request, while another is multicast to the
requested multicast group G and the source UDP port of the request.
Both replies are sent from the same port on which the request was Both replies are sent from the same port on which the request was
received. The server should specify the TTL used for both the received. The server should specify the TTL (IPv4 time-to-live or
unicast and multicast messages (we recommend at least 64) by IPv6 hop-count) used for both the unicast and multicast messages
including a TTL option; allowing the client to compute the number of (TTL of at least 64 is recommended) by including a TTL option.
hops. The client should leave the channel/group when it has finished This allows the client to compute the number of hops. The client
its measurements. should leave the group/channel when it has finished its
measurements.
By use of this protocol, a client can obtain information about By use of this protocol, a client (or a user of the client) can
several multicast delivery characteristics. First, by receiving obtain information about several multicast delivery characteristics.
unicast replies, it can verify that the server is receiving the First, by receiving unicast replies, the client can verify that the
unicast requests, is operational and responding. Hence, provided server is receiving the unicast requests, is operational and
that the client receives unicast replies, a failure to receive responding. Hence, provided that the client receives unicast
multicast indicates either a multicast problem or a multicast replies, a failure to receive multicast indicates either a multicast
administrative restriction. If it does receive multicast, it knows problem or a multicast administrative restriction. If it does
not only that it can receive; it may also estimate the amount of time receive multicast, it knows not only that it can receive multicast
it took to establish the multicast tree (at least if it is in the traffic, it may also estimate the amount of time it took to establish
range of seconds), whether there are packet drops, and the length and the multicast tree (at least if it is in the range of seconds),
variation of Round Trip Times (RTT). For unicast, the RTT is the whether there are packet drops, and the length and variation of Round
time from when the unicast request is sent to when the reply is Trip Times (RTT).
received. The measured multicast RTT also references the client's
unicast request. By use of the TTL option specifying the TTL of the
replies when they are originated, the client can also determine the
number of router hops it is from the source. Since similar
information is obtained in the unicast replies, the host may compare
its multicast and unicast results and is able to check for
differences in the number of hops, RTT, etc. The number of multicast
hops and changes in the number of hops over time, may also reveal
details about the multicast tree and multicast tree changes.
Provided that the server sends the unicast and multicast replies
nearly simultaneously, the client may also be able to measure the
difference in one way delay for unicast and multicast on the path
from server to client, and also differences in delay. Servers may
optionally specify a timestamp. This may be useful since the unicast
and multicast replies can not be sent simultaneously (the delay
depending on the host's operating system and load).
3. Protocol specification For unicast, the RTT is the time from when the unicast request is
sent to the time when the reply is received. The measured multicast
RTT also references the client's unicast request. By specifying the
TTL of the replies when they are originated, the client can also
determine the number of router hops it is from the source. Since
similar information is obtained in the unicast replies, the host may
compare its multicast and unicast results and is able to check for
differences such as the number of hops, and RTT.
There are four different message types. There are Echo Request and The number of multicast hops and changes in the number of hops over
Echo Reply messages used for the actual measurements; there is an time may reveal details about the multicast tree and multicast tree
Init message that SHOULD be used to initialise a ping session and changes. Provided that the server sends the unicast and multicast
negotiate which group to use; and finally a Server Response message replies nearly simultaneously, the client may also be able to measure
that is mainly used in response to the Init message. The messages the difference in one way delay for unicast and multicast on the path
MUST always be in network byte order. UDP checksums MUST always be from server to client, and also differences in delay.
used.
Servers may optionally specify a timestamp. This may be useful since
the unicast and multicast replies can not be sent simultaneously (the
delay is dependent on the host's operating system and load).
3. Protocol Specification
There are four different message types. Echo Request and Echo Reply
messages are used for the actual measurements. An Init message
SHOULD be used to initialise a ping session and negotiate which group
to use. Finally a Server Response message that is mainly used in
response to the Init message. The messages MUST always be in network
byte order. UDP checksums MUST always be used.
The messages share a common format: one octet specifying the message The messages share a common format: one octet specifying the message
type, followed by a number of options in TLV (Type, Length and Value) type, followed by a number of options in TLV (Type, Length and Value)
format. This makes the protocol easily extendible. The Init message format. This makes the protocol easily extendible.
generally contains some prefix options asking the server for a group
from one of the specified prefixes. The server responds with a Message types in the range 0-191 are reserved and available for
Server Response message that contains the group address to use, or allocation in an IANA Registry. Message types in the range 192-255
possibly prefix options describing what multicast groups the server are not registered and are freely available for experimental use.
may be able to provide. For an Echo Request the client generally See Section 8.
includes a number of options, and a server MAY simply echo the
contents (only changing the message type) without inspecting the The Init message generally contains some prefix options asking the
options if it does not support any options. This might be true for a server for a group from one of the specified prefixes. The server
simple Multicast Ping Protocol server. However, the server SHOULD responds with a Server Response message that contains the group
add a TTL option, and there are other options that a server address to use, or possibly prefix options describing what multicast
implementation MAY support, e.g., the client may ask for certain groups the server may be able to provide.
information or a specific behaviour from the server. The Echo
Replies (one unicast and one multicast) MUST first contain the exact For an Echo Request the client generally includes a number of
options from the request (in the same order), and then, immediately options, and a server MAY simply echo the contents (only changing the
message type) without inspecting the options if it does not support
any options. This might be true for a simple Multicast Ping Protocol
server. However, the server SHOULD add a TTL option, and there are
other options that a server implementation MAY support, e.g., the
client may ask for certain information or a specific behaviour from
the server. The Echo Replies (one unicast and one multicast) MUST
first contain the exact options (excluding the Session ID option)
from the request (in the same order), and then, immediately
following, any options appended by the server. A server MUST NOT following, any options appended by the server. A server MUST NOT
process unknown options, but they MUST still be included in the Echo process unknown options, but they MUST still be included in the Echo
Reply. A client MUST ignore any unknown options. Reply. A client MUST ignore any unknown options.
The size of the protocol messages is generally smaller than the Path The size of the protocol messages is generally smaller than the Path
MTU and fragmentation is not a concern. There may however be cases MTU and fragmentation is not a concern. There may however be cases
where the Path MTU is really small, or that a client sends large where the Path MTU is really small, or that a client sends large
requests in order to verify that it can receive fragmented multicast requests in order to verify that it can receive fragmented multicast
datagrams. This document does not specify whether Path MTU Discovery datagrams. This document does not specify whether Path MTU Discovery
should be performed, etc. A possible extension could be an option should be performed, etc. A possible extension could be an option
where a client requests Path MTU Discovery and receives the current where a client requests Path MTU Discovery and receives the current
Path MTU from the server. Path MTU from the server.
This document defines a number of different options. Some options do This document defines a number of different options. Some options do
not require processing by servers and are simply returned unmodified not require processing by servers and are simply returned unmodified
in the reply. There are, however, other client options that the in the reply. There are, however, other client options that the
server may care about, and also server options that may be requested server may care about, as well as server options that may be
by a client. Unless otherwise specified, an option MUST NOT be used requested by a client. Unless otherwise specified, an option MUST
multiple times in the same message. NOT be used multiple times in the same message.
3.1. Option format 3.1. Option Format
All options are TLVs formatted as specified below. All options are TLVs formatted as below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
| . | | . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 octets) specifies the option. The different options are Type (2 octets) specifies the option.
defined below.
Length (2 octets) specifies the length of the value field. Depending Length (2 octets) specifies the length of the value field. Depending
on the option type, it can be from 0 to 65535. on the option type, it can be from 0 to 65535.
Value. The value must always be of the specified length. See the Value must always be of the specified length. See the respective
respective option definitions for possible values. If the length is option definitions for possible values. If the length is 0, the
0, the value field is not included. value field is not included.
3.2. Defined Options 3.2. Defined Options
This document defines the following options: Version (0), Client ID This document defines the following options: Version (0), Client ID
(1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4),
Option Request Option (5), Server Information (6), TTL (9), Multicast Option Request Option (5), Server Information (6), TTL (9), Multicast
Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and
8 are reserved. The options are defined below. 8 are reserved. The options are defined below.
Option types in the range 0-49151 are reserved and available for
allocation in an IANA Registry. Option types in the range 49152-
65535 are not registered and are freely available for experimental
use. See Section 8.
Version, type 0 Version, type 0
Length MUST be 1. This option MUST always be included in all Length MUST be 1. This option MUST always be included in all
messages, and the value MUST be set to 2 (in decimal). Note messages, and for the current specified protocol this value
that there are implementations of older revisions of this MUST be set to 2 (in decimal). Note that there are
protocol that only partly follow this specification. They can implementations of older revisions of this protocol that only
be regarded as version 1 and do not use this option. If a partly follow this specification. They can be regarded as
server receives a message with a version other than 2 (or version 1 and do not use this option. If a server receives a
missing), the server SHOULD (unless it supports the particular message with a version other than 2 (or missing), the server
version) send a Response message back with version set to 2. SHOULD (unless it supports the particular version) send a
Client ID and Sequence Number options SHOULD be echoed if Server Response message back with version set to 2. Client ID
present. It SHOULD not include any other options. A client and Sequence Number options SHOULD be echoed if present. The
receiving a response with a version other than 2, MUST (unless server SHOULD NOT include any other options. A client
it supports the particular version), stop sending requests to receiving a response with a version other than 2 MUST stop
the server. sending requests to the server (unless it supports the
particular version).
Client ID, type 1 Client ID, type 1
Length MUST be non-zero. A client SHOULD always include this Length MUST be non-zero. A client SHOULD always include this
option in all messages (both Init and Request). The client may option in all messages (both Init and Echo Request). The
use any value it likes to be able to detect whether a reply is client may use any value it likes to detect whether a reply is
a reply to its Init/Request or not. A server should treat this a reply to its Init/Echo Request or not. A server should treat
as opaque data, and MUST echo this option back in the reply if this as opaque data, and MUST echo this option back in the
present (both Server Response and Reply). The value might be a reply if present (both Server Response and Echo Reply). The
process ID, perhaps process ID combined with an IP address value might be a process ID, perhaps process ID combined with
because it may receive multicast responses to queries from an IP address because it may receive multicast responses to
other clients. It is left to the client implementer how to queries from other clients. It is left to the client
make use of this option. implementer how to use this option.
Sequence Number, type 2 Sequence Number, type 2
Length MUST be 4. A client MUST always include this in Request Length MUST be 4. A client MUST always include this in Echo
messages and MUST NOT include it in Init messages. A server Request messages and MUST NOT include it in Init messages. A
replying to a Request message MUST copy it into the Reply (or server replying to an Echo Request message MUST copy it into
Server Response message on error). This contains a 32 bit the Echo Reply (or Server Response message on error). The
sequence number. The values would typically start at 1 and sequence number is a 32-bit integer. Values typically start at
increase by one for each request in a sequence. 1 and increase by one for each Echo Request in a sequence.
Client Timestamp, type 3 Client Timestamp, type 3
Length MUST be 8 bytes. A client SHOULD include this in Length MUST be 8 bytes. A client SHOULD include this in Echo
Request messages and MUST NOT include it in Init messages. A Request messages and MUST NOT include it in Init messages. A
server replying to a Request message MUST copy it into the server replying to an Echo Request message MUST copy it into
Reply. The timestamp specifies the time when the Request the Echo Reply. The timestamp specifies the time when the Echo
message is sent. The first 4 bytes specify the number of Request message is sent. The first 4 bytes specify the number
seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4
bytes specify the number of microseconds since the last second bytes specify the number of microseconds since the second
since the Epoch. specified in the first 4 bytes.
Multicast Group, type 4 Multicast Group, type 4
Length MUST be greater than 2. It MAY be used in Server Length MUST be greater than 2. It MAY be used in Server
Response messages to tell the client what group to use in Response messages to tell the client what group to use in
subsequent Request messages. It MUST be used in Request subsequent Echo Request messages. It MUST be used in Echo
messages to tell the server what group address to respond to Request messages to tell the server what group address to
(this group would typically be previously obtained in a Server respond to (this group would typically be previously obtained
Response message). It MUST be used in Reply messages (copied in a Server Response message). It MUST be used in Echo Reply
from the Request message). It MUST NOT be used in Init messages (copied from the Echo Request message). It MUST NOT
messages. The format of the option value is as below. be used in Init messages. The format of the option value is as
below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Multicast group address... | | Address Family | Multicast group address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for The address family is a value 0-65535 as assigned by IANA for
Internet Address Families [3]. This is followed by the group Internet address families [4]. This is followed by the group
address. Length of the option value will be 6 for IPv4, and 18 address. Length of the option value will be 6 for IPv4, and 18
for IPv6. for IPv6.
Option Request Option, type 5 Option Request Option, type 5
Length MUST be greater than 1. This option MAY be used in Length MUST be greater than 1. This option MAY be used in
client messages (Init and Request messages). A server MUST NOT client messages (Init and Echo Request messages). A server
send this option, except that if it is present in a Request MUST NOT send this option, except that if it is present in an
message, the server MUST echo it in replies (Reply message) to Echo Request message, the server MUST echo it in replies (Echo
the Request. This option contains a list of option types for Reply message) to the Echo Request. This option contains a
options that the client is requesting from the server. Support list of option types for options that the client is requesting
for this option is optional for both clients and servers. The from the server. Support for this option is optional for both
length of this option will be a non-zero even number, since it clients and servers. The length of this option will be a non-
contains one or more option types that are two octets each. zero even number, since it contains one or more option types
The format of the option value is as below. that are two octets each. The format of the option value is as
below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Type | | Option Type | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... | | ..... |
This option might be used by the client to ask the server to This option might be used by the client to ask the server to
include options like Timestamp or Server Information. A client include options like Timestamp or Server Information. A client
MAY request Server Information in Init messages; it MUST NOT MAY request Server Information in Init messages; it MUST NOT
request it in other messages. A client MAY request a Timestamp request it in other messages. A client MAY request a timestamp
in Request messages; it MUST NOT request it in other messages. in Echo Request messages; it MUST NOT request it in other
Subject to enforcing the above restrictions, a server messages. Subject to enforcing the above restrictions, a
supporting this option SHOULD include the requested options in server supporting this option SHOULD include the requested
responses (Reply messages) to the Request containing the Option options in responses (Echo Reply messages) to the Echo Request
Request Option. The server may according to implementation or containing the Option Request Option. The server may,
local configuration, not necessarily include all the requested according to implementation or local configuration, not
options, or possibly none. Any options included are appended necessarily include all the requested options, or possibly
to the echoed options, similar to other options included by the none. Any options included are appended to the echoed options,
server. similar to other options included by the server.
Server Information, type 6 Server Information, type 6
Length MUST be non-zero. It MAY be used in Server Response Length MUST be non-zero. It MAY be used in Server Response
messages and MUST NOT be used in other messages. Support for messages and MUST NOT be used in other messages. Support for
this option is optional. A server supporting this option this option is optional. A server supporting this option
SHOULD add it in Server Response messages if and only if SHOULD add it in Server Response messages if and only if
requested by the client. The value is a UTF-8 string that requested by the client. The value is a UTF-8 string that
might contain vendor and version information for the server might contain vendor and version information for the server
implementation. It may also contain information on which implementation. It may also contain information on which
options the server supports. An interactive client MAY support options the server supports. An interactive client MAY support
this option, and SHOULD then allow a user to request this this option, and SHOULD then allow a user to request this
string and display it. string and display it.
Reserved, type 7 Reserved, type 7
This option code value was used by early implementations for an This option code value was used by early implementations for an
option that is now deprecated. This option should no longer be option that is now deprecated. This option should no longer be
used. Clients MUST NOT use this option. Servers MUST treat it used. Clients MUST NOT use this option. Servers MUST treat it
as an unknown option (not process it if received, but if as an unknown option (not process it if received, but if
received in a Request message, it MUST be echoed in the Reply received in an Echo Request message, it MUST be echoed in the
message). Echo Reply message).
Reserved, type 8 Reserved, type 8
This option code value was used by early implementations for an This option code value was used by early implementations for an
option that is now deprecated. This option should no longer be option that is now deprecated. This option should no longer be
used. Clients MUST NOT use this option. Servers MUST treat it used. Clients MUST NOT use this option. Servers MUST treat it
as an unknown option (not process it if received, but if as an unknown option (not process it if received, but if
received in a Request message, it MUST be echoed in the Reply received in an Echo Request message, it MUST be echoed in the
message). Echo Reply message).
TTL, type 9 TTL, type 9
Length MUST be 1. This option contains a single octet Length MUST be 1. This option contains a single octet
specifying the TTL of a Reply message. Every time a server specifying the TTL of an Echo Reply message. Every time a
sends a unicast or multicast Reply message, it SHOULD include server sends a unicast or multicast Echo Reply message, it
this option specifying the TTL. This is used by clients to SHOULD include this option specifying the TTL. This is used by
determine the number of hops the messages have traversed. It clients to determine the number of hops the messages have
MUST NOT be used in other messages. A server SHOULD specify traversed. It MUST NOT be used in other messages. A server
this option if it knows what the TTL of the Reply will be. In SHOULD specify this option if it knows what the TTL of the Echo
general the server can specify a specific TTL to the host Reply will be. In general the server can specify a specific
stack. Note that the TTL is not necessarily the same for TTL to the host stack. Note that the TTL is not necessarily
unicast and multicast. the same for unicast and multicast. Also note that this option
SHOULD be included even when not requested by the client.
Multicast Prefix, type 10 Multicast Prefix, type 10
Length MUST be greater than 2. It MAY be used in Init messages Length MUST be greater than 2. It MAY be used in Init messages
to request a group within the prefix(es), it MAY be used in to request a group within the prefix(es) and it MAY be used in
Server Response messages to tell the client what prefix(es) it Server Response messages to tell the client what prefix(es) it
may try to obtain a group from. It MUST NOT be used in may try to obtain a group from. It MUST NOT be used in Echo
Request/Reply messages. Note that this option MAY be included Request/Reply messages. Note that this option MAY be included
multiple times to specify multiple prefixes. multiple times to specify multiple prefixes.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Prefix Length |Partial address| | Address Family | Prefix Length |Partial address|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for The address family is a value 0-65535 as assigned by IANA for
Internet Address Families [3]. This is followed by a prefix Internet address families [4]. This is followed by a prefix
length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special
'wildcard' use discussed below), and finally a group address. "wildcard" use discussed below), and finally a group address.
For any family, prefix length 0 means that any multicast For any family, prefix length 0 means that any multicast
address from that family is acceptable. This is what we call address from that family is acceptable. This is what we call
'wildcard'. The group address need only contain enough octets "wildcard." The group address need only contain enough octets
to cover the prefix length bits (i.e., the group address would to cover the prefix length bits (i.e., the group address would
have to be 3 octets long if the prefix length is 17-24, and have to be 3 octets long if the prefix length is 17-24, and
there need be no group address for the wildcard with prefix there need be no group address for the wildcard with prefix
length 0). Any bits past the prefix length MUST be ignored. length 0). Any bits past the prefix length MUST be ignored.
For IPv4, the option value length will be 4-7, while for IPv6, For IPv4, the option value length will be 4-7, while for IPv6,
it will be 4-19, and for the wildcard, it will be 3. it will be 4-19, and for the wildcard, it will be 3.
Session ID, type 11 Session ID, type 11
Length MUST be non-zero. A server SHOULD include this in Length MUST be non-zero. A server SHOULD include this in
Server Response and Reply messages. If a client receives this Server Response messages. If a client receives this option in
option in a message, the client MUST echo the Session ID option a message, the client MUST echo the Session ID option in
in subsequent Request messages, with the exact same value, subsequent Echo Request messages, with the exact same value.
until the next message is received from the server. If the The Session ID may help the server in keeping track of clients
next message from the server has no Session ID or a new Session and possibly manage per client state. The value of a new
ID value, the client should do the same, either not use the Session ID SHOULD be chosen pseudo randomly so that it is hard
Session ID, or use the new value. The Session ID may help the to predict. The Session ID can be used to prevent spoofing of
server in keeping track of clients and possibly manage per the source address of Echo Request messages. See the Security
client state. The value of a new Session ID should be chosen Considerations for details.
pseudo randomly so that it is hard to predict. This can be
used to prevent spoofing of the source address of Request
messages, see the Security Considerations for details.
Server Timestamp, type 12 Server Timestamp, type 12
Length MUST be 8 bytes. A server supporting this option, Length MUST be 8 bytes. A server supporting this option,
SHOULD include it in Reply messages, if requested by the SHOULD include it in Echo Reply messages, if requested by the
client. The timestamp specifies the time when the Reply client. The timestamp specifies the time when the Echo Reply
message is sent. The first 4 bytes specify the number of message is sent. The first 4 bytes specify the number of
seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4
bytes specify the number of microseconds since the last second bytes specify the number of microseconds since the second
since the Epoch. specified in the first 4 bytes.
4. Packet Format 3.3. Packet Format
The format of all messages is a one octet message type, directly The format of all messages is a one octet message type, followed by a
followed by a variable number of options. variable number of options.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Options ... | | Type | Options ... |
+-+-+-+-+-+-+-+-+ . | +-+-+-+-+-+-+-+-+ . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .....
There are four message types defined. Type 81 (the character Q in There are four message types defined. Type 81 (the character Q in
ASCII) specifies an Echo Request (Query). Type 65 (the character A ASCII) specifies an Echo Request (Query). Type 65 (the character A
in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I
in ASCII) is an Init message, and type 83 (the character S in ASCII) in ASCII) is an Init message, and type 83 (the character S in ASCII)
is a Server Response message. is a Server Response message.
The options directly follow the type octet and are not aligned in any The options immediately follow the type octet and are not aligned in
way (no spacing or padding), i.e., options might start at any octet any way (no spacing or padding), i.e., options might start at any
boundary. The option format is specified above. octet boundary. The option format is specified above.
5. Message types and options 3.4. Message Types and Options
There are four message types defined. We will now describe each of There are four message types defined. We will now describe each of
the message types and which options they may contain. the message types and which options they may contain.
Init, type 73 Init, type 73
This message is sent by a client to request information from a This message is sent by a client to request information from a
server. It is mainly used for requesting a group address, but server. It is mainly used for requesting a group address, but
it may also be used to check which group prefixes the server it may also be used to check which group prefixes the server
may provide groups from, or other server information. It MUST may provide groups from, or other server information. It MUST
skipping to change at page 11, line 34 skipping to change at page 12, line 12
MAY include Option Request and Multicast Prefix Options. This MAY include Option Request and Multicast Prefix Options. This
message is a request for a group address if and only if it message is a request for a group address if and only if it
contains Multicast Prefix options. If multiple Prefix options contains Multicast Prefix options. If multiple Prefix options
are included, they should be in prioritised order. I.e., the are included, they should be in prioritised order. I.e., the
server will consider the prefixes in the order they are server will consider the prefixes in the order they are
specified, and if it finds a group for a prefix, it will only specified, and if it finds a group for a prefix, it will only
return that one group, not considering the remaining prefixes. return that one group, not considering the remaining prefixes.
Server Response, type 83 Server Response, type 83
This message is sent by a server. Either as a response to an This message is sent by a server, either as a response to an
Init, or in response to a Request. When responding to Init, it Init, or in response to an Echo Request. When responding to
may provide the client with a multicast group (if requested by Init, it may provide the client with a multicast group (if
the client), or it may provide other server information. In requested by the client), or it may provide other server
response to a Request, the message tells the client to stop information. In response to an Echo Request, the message tells
sending Requests. The Version option MUST always be included. the client to stop sending Echo Requests. The Version option
Client ID and Sequence Number options are echoed if present in MUST always be included. Client ID and Sequence Number options
the client message. When providing a group to the client, it are echoed if present in the client message. When providing a
includes a Multicast Group option. It SHOULD include Server group to the client, it includes a Multicast Group option. It
Information and Prefix options if requested. SHOULD include Server Information and Prefix options if
requested.
Echo Request, type 81 Echo Request, type 81
This message is sent by a client, asking the server to send This message is sent by a client, asking the server to send
unicast and multicast replies. It MUST include Version, unicast and multicast Echo Replies. It MUST include Version,
Sequence Number and Multicast Group options. If the last Sequence Number and Multicast Group options. If a Session ID
message (if any) received from the server contained a Session was received in a Server Response message, then the Session ID
ID, then this MUST also be included. It SHOULD include Client MUST be included. It SHOULD include Client ID and Client
ID and Client Timestamp options. It MAY include an Option Timestamp options. It MAY include an Option Request option.
Request option.
Echo Reply, type 65 Echo Reply, type 65
This message is sent by a server in response to an Echo Request This message is sent by a server in response to an Echo Request
message. This message is always sent in pairs, one as unicast message. This message is always sent in pairs, one as unicast
and one as multicast. The contents of the messages are mostly and one as multicast. The contents of the messages are mostly
the same. The server echoes most of the options from the Echo the same. The server always echoes all of the options (but
Request (any options in the Request that are unsupported by the never the Session ID) from the Echo Request. Any options in
server, are always echoed). The only option that may be the Echo Request that are unsupported by the server, are also
present in the Request which is not always echoed, is the to be echoed. The two Echo Reply messages SHOULD both always
Session ID option. In most cases the server would echo it, but contain a TTL option (not necessarily equal). Both Echo Reply
the server may also change or omit it. The two Reply messages messages SHOULD also when requested contain Server Timestamps
SHOULD both contain a TTL option (not necessarily equal), and (not necessarily equal).
both SHOULD also contain Server Timestamps (not necessarily
equal) when requested.
For the reader's convenience we provide the matrix below, showing The below matrix summarises what options can go in what messages.
what options can go in what messages.
Option / Message Type | Init | Server Response | Request | Reply | \ Message Type | Init | Server | Echo | Echo |
-----------------------------------------------------------------+ Option \ | | Response | Request | Reply |
Version (0) | MUST | ECHO | MUST | ECHO | -----------------------+--------+----------+---------+--------+
Version (0) | MUST | MUST | MUST | ECHO |
Client ID (1) |SHOULD| ECHO | SHOULD | ECHO | Client ID (1) |SHOULD| ECHO | SHOULD | ECHO |
Sequence Number (2) | NOT | ECHO | MUST | ECHO | Sequence Number (2) | NOT | ECHO | MUST | ECHO |
Client Timestamp (3) | NOT | NOT | SHOULD | ECHO | Client Timestamp (3) | NOT | NOT | SHOULD | ECHO |
Multicast Group (4) | NOT | MAY | MUST | ECHO | Multicast Group (4) | NOT | MAY | MUST | ECHO |
Option Request (5) | MAY | NOT | MAY | ECHO | Option Request (5) | MAY | NOT | MAY | ECHO |
Server Information (6)| NOT | RQ | NOT | NOT | Server Information (6)| NOT | RQ | NOT | NOT |
Reserved (7) | NOT | NOT | NOT | ECHO | Reserved (7) | NOT | NOT | NOT | ECHO |
Reserved (8) | NOT | NOT | NOT | ECHO | Reserved (8) | NOT | NOT | NOT | ECHO |
TTL (9) | NOT | NOT | NOT |SHOULD | TTL (9) | NOT | NOT | NOT |SHOULD |
Multicast Prefix (10) | MAY | MAY | NOT | NOT | Multicast Prefix (10) | MAY | MAY | NOT | NOT |
Session ID (11) | NOT | MAY | ECHO | MAY | Session ID (11) | NOT | SHOULD | ECHO | NOT |
Server Timestamp (12) | NOT | NOT | NOT | RQ | Server Timestamp (12) | NOT | NOT | NOT | RQ |
-----------------------+--------+----------+---------+--------+
NOT means that the option MUST NOT be included. ECHO for a server NOT means that the option MUST NOT be included. ECHO for a server
means that if the option is specified by the client, then the server means that if the option is specified by the client, then the server
MUST echo the option in the response, with the exact same option MUST echo the option in the response, with the exact same option
value. ECHO for a client means that it MUST echo the option it got value. ECHO for a client only applies to the Session ID option. If
in the last message from the server in any subsequent messages it it is present in the Server Response, then it must be present with
sends. RQ means that the server SHOULD include the option in the the exact same option value in the following Echo Requests. RQ means
response, when requested by the client using the Option Request that the server SHOULD include the option in the response, when
option. requested by the client using the Option Request option.
6. Client Behaviour 3.5. Rate Limiting
Clients MUST by default send at most one Echo Request per second.
Servers MUST by default perform rate limiting, to guard against this
protocol being used for DoS attacks. The server MUST by default for
a given client, respond to on average at most one Echo Request
message per second. Server implementations should provide
configuration options allowing certain clients to perform more rapid
Echo Requests. If higher rates are allowed for specific client IP
addresses, then Init messages and the Session ID option MUST be used
to help prevent spoofing.
Implementers of applications/tools using this protocol SHOULD
consider the UDP guidelines [6], in particular if clients are to
send, or servers are to accept, Echo Requests at rates exceeding one
per second. See Section 9, "Security Considerations", for additional
discussion.
4. Client Behaviour
We will consider how a typical interactive client using the above We will consider how a typical interactive client using the above
protocol would behave. A client need only require a user to specify protocol would behave.
the unicast address of the server. It can then send an Init message
with a prefix option containing the desired address family and zero A client only requires a user to specify the unicast address of the
prefix length (wildcard entry). The server is then free to decide server. It can then send an Init message with a prefix option
which group, from the specified family, it should return. A client containing the desired address family and zero prefix length
may also allow a user to specify group address(es) or prefix(es) (for (wildcard entry). The server can then decide which group, from the
IPv6, the user may only be required to specify a scope or an RP specified family, it should return. A client may also allow the user
address, from which the client can construct the desired prefix, to specify group address(es) or prefix(es) (for IPv6, the user may
possibly embedded-RP). From this the client can specify one or more only be required to specify a scope or an RP address, from which the
prefix options in an Init message to tell the server which address it client can construct the desired prefix, possibly embedded-RP). From
would prefer. If the user specifies a group address, that can be this the client can specify one or more prefix options in an Init
encoded as a prefix of maximal length (e.g., 32 for IPv4). The message to tell the server which address it would prefer. If the
prefix options are in prioritised order, i.e., the client should put user specifies a group address, that can be encoded as a prefix of
the most preferred prefix first. maximal length (e.g., 32 for IPv4). The prefix options are in
prioritised order, i.e., the client should put the most preferred
prefix first.
If the client receives a Server Response message containing a group If the client receives a Server Response message containing a group
address it can start sending Request messages, see the next address it can start sending Echo Request messages, see the next
paragraph. If there is no group address option, it would typically paragraph. If there is no group address option, the client would
exit with an error message. The server may have included some prefix typically exit with an error message. The server may have included
options in the Server Response. The client may use this to provide some prefix options in the Server Response. The client may use this
the user some feedback on what prefixes or scopes are available. to provide the user some feedback on what prefixes or scopes are
available.
Assuming the client got a group address in a Server Response, it can Assuming the client got a group address in a Server Response, it can
start pinging. Before it does that, it should let the user know start the multicast pings, after letting the user know which group is
which group is being used. Normally, a client should send at most being used. Normally, a client should send at most one Echo Request
one ping request per second. When sending ping Requests, the client per second.
must always include the group option. If the last message from the
server contained a Session ID, then it must also include that with When sending the Echo Requests, the client must always include the
the same value. Typically it would receive a Session ID in a Server group option. If the Server Response contained a Session ID, then it
Response together with the group address, and then the ID would stay must also include that, with the exact same value, in the Echo
the same during the entire ping sequence. However, if for instance Requests. If a client receives a Server Response message in response
the server process is restarted, it may still be possible to continue to an Echo Request (that is, a Server Response message containing a
pinging but the Session ID may be changed by the server. Hence a
client implementation must always use the last Session ID it
received, and not necessarily the one from the Server Response
message. If a client receives a Server Response message in response
to a Request message (that is, a Server Response message containing a
sequence number), this means there is an error and it should stop sequence number), this means there is an error and it should stop
sending Requests. This may for instance happen after server restart. sending Echo Requests. This could happen after server restart.
The client may allow the user to request server information. If the The client may allow the user to request server information. If the
user requests server information, the client can send an Init message user requests server information, the client can send an Init message
with no prefix options, but with an Option Request Option, requesting with no prefix options, but with an Option Request Option, requesting
the server to return a Server Information option. The server will the server to return a Server Information option. The server will
return server information if supported, and it may also return a list return server information if supported, and it may also return a list
of prefixes it supports. It will however not return a group address. of prefixes it supports. It will however not return a group address.
The client may also try to obtain only a list of prefixes by sending The client may also try to obtain only a list of prefixes by sending
an Init message with no prefixes and not requesting any specific an Init message with no prefixes and not requesting any specific
options. options.
Note that a client may pick a multicast group and send Request Although not recommended, a client may pick a multicast group and
messages without first going through the Init - Server Response send Echo Request messages without first going through the Init -
negotiation. If this is supported by the server and the server is Server Response negotiation. If this is supported by the server and
okay with the group used, the server can then send Reply messages as the server is okay with the group used, the server can then send Echo
usual. If the server is not okay, it will send a Server Response Reply messages as usual. If the server is not okay, it will send a
telling the client to stop. Server Response telling the client to stop.
7. Server Behaviour 5. Server Behaviour
We will consider how a typical server using the above protocol would We will consider how a typical server using the above protocol would
behave. First we consider how to respond to Init messages. If the behave, first looking at how to respond to Init messages.
Init message contains prefix options, the server should look at them
in order and see if it can assign a multicast address from the given
prefix. The server would be configured, possibly have a default,
specifying which groups it can offer. It may have a large pool just
picking a group at random, possibly choose a group based on hashing
of the client's IP address or identifier, or just use a fixed group.
A server could possibly decide whether to include site scoped group
ranges based on the client's IP address. It is left to the server to
decide whether it should allow the same address to be used
simultaneously by multiple clients. If the server finds a suitable
group address, it returns this in a group option in a Server Response
message. The server should additionally include a Session ID. This
may help the server if it is to keep some state, for instance for
making sure the client uses the group it got assigned. A good
Session ID would be a pseudo random byte string that is hard to
predict. If the server cannot find a suitable group address, or if
there were no prefixes in the Init message, it may send a Server
Response message containing prefix options listing what prefixes may
be available to the client. Finally, if the Init message requests
the Server Information option, it should include that.
When the server receives a Request message, it may first check that If the Init message contains prefix options, the server should look
the group address and Session ID (if provided) are valid. If the at them in order and see if it can assign a multicast address from
server is satisfied, it will send a unicast Reply message back to the the given prefix. The server would be configured with, possibly have
client, and also a multicast Reply message to the group address. The a default, a set of groups it can offer. It may have a large pool
Reply messages contain the exact options and in the same order, as in and pick a group at random, or possibly choosing a group based on
the Request, and after that the server adds a TTL option and hashing of the client's IP address or identifier, or simply use a
additional options if needed. E.g., it may add a timestamp if fixed group. A server could possibly decide whether to include site
requested by the client. If the server is not happy with the Request scoped group ranges based on the client's IP address. It is left to
(bad group address or Session ID, request is too large etc), it may the server to decide whether it should allow the same address to be
send a Server Response message asking the client to stop. This used simultaneously by multiple clients.
Server Response must echo the sequence number from the Request. This
If the server finds a suitable group address, it returns this in a
group option in a Server Response message. The server should
additionally include a Session ID. This may help the server if it is
to keep some state, for instance to make sure the client uses the
group it got assigned. A good Session ID would be a pseudo random
byte string that is hard to predict. If the server cannot find a
suitable group address, or if there were no prefixes in the Init
message, it may send a Server Response message containing prefix
options listing what prefixes may be available to the client.
Finally, if the Init message requests the Server Information option,
the server should include that.
When the server receives an Echo Request message, it may first check
that the group address and Session ID (if provided) are valid. If
the server is satisfied, it will send a unicast Echo Reply message
back to the client, and also a multicast Echo Reply message to the
group address. The Echo Reply messages contain the exact options
(but no Session ID) and in the same order, as in the Echo Request,
and after that the server adds a TTL option and additional options if
needed. For example, it may add a timestamp if requested by the
client. If the server is not happy with the Echo Request (such as
bad group address or Session ID, request is too large), it may send a
Server Response message asking the client to stop. This Server
Response must echo the sequence number from the Echo Request. This
Server Response may contain group prefixes from which a client can Server Response may contain group prefixes from which a client can
try to request a group address. The unicast and multicast Reply try to request a group address. The unicast and multicast Echo Reply
messages have identical UDP payload apart from possibly TTL and messages have identical UDP payload apart from possibly TTL and
timestamp option values. timestamp option values.
Note that the server may receive Request messages with no prior Init Note that the server may receive Echo Request messages with no prior
message. This may happen when the server restarts or if a client Init message. This may happen when the server restarts or if a
sends a Request with no prior Init message. The server may go ahead client sends an Echo Request with no prior Init message. The server
and respond if it is okay with the group used. In the responses it may go ahead and respond if it is okay with the group used. If the
may add a Session ID which will then be in later requests from the group is not okay, the server sends back a Server Response.
client. If the group is not okay, the server sends back a Server
Response. The Response is just as if it got an Init message with no
prefixes. If the server adds or modifies the SessionID in replies,
it must use the exact same SessionID in the unicast and multicast
replies.
8. Recommendations for Implementers 6. Recommendations for Implementers
The protocol as specified is fairly flexible and leaves a lot of The protocol as specified is fairly flexible and leaves a lot of
freedom for implementers. In this section we present some freedom for implementers. In this section we present some
recommendations. recommendations.
Server administrators should be able to configure one or multiple Server administrators should be able to configure one or multiple
group prefixes in a server implementation. When deploying servers on group prefixes in a server implementation. When deploying servers on
the Internet and in other environments, the server administrator the Internet and in other environments, the server administrator
should be able to restrict the server to respond to only a few should be able to restrict the server to respond to only a few
multicast groups which should not be currently used by multicast multicast groups which should not be currently used by multicast
applications. A server implementation should also provide applications. A server implementation should also provide
flexibility for an administrator to apply various policies to provide flexibility for an administrator to apply various policies to provide
one or multiple group prefixes to specific clients, e.g., site scoped one or multiple group prefixes to specific clients, e.g., site scoped
addresses for clients that are inside the site. Clients could be addresses for clients that are inside the site.
identified by their IP address provided that clients are required to
send Init messages, and they receive an unpredictable Session ID.
See also Section 11.
Clients should by default send at most one request per second. As specified in Section 3.5, a server must by default for a given
Servers should perform rate limiting, to guard against this protocol client, respond to at most one Echo Request message per second. A
being used for DoS attacks. The server should for a given client, leaky bucket algorithm is suggested, where the rate can be higher for
respond to at most one Request message per second. A leaky bucket a few seconds, but the average rate should by default be limited to a
algorithm is suggested, where the rate can be higher for a few
seconds, but the average rate should by default be limited to a
message per client per second. Server implementations should provide message per client per second. Server implementations should provide
administrative control of which client IP addresses to serve, and may administrative control of which client IP addresses to serve, and may
also allow certain clients to perform more rapid requests. also allow certain clients to perform more rapid Echo Requests.
Implementers of applications/tools using this protocol should
consider the UDP guidelines [5], in particular if clients are to
send, or servers are to accept, requests at rates exceeding one per
second. If higher rates are allowed for specific IP addresses, then
Init messages and the Session ID option should be used to help
prevent spoofing. See Section 11.
9. Acknowledgments If a server uses different policies for different IP addresses, it
should require clients to send Init messages and return an
unpredictable Session ID to help prevent spoofing. This is an
absolute requirement if exceeding the default rate limit. See
specification in Section 3.5.
7. Acknowledgments
The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and
Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source
Specific Multicast, and also the Internet Draft Specific Multicast, and also the Internet Draft
draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with
several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave
Thaler have contributed in different ways to the implementation of Thaler have contributed in different ways to the implementation of
the ssmping tools at [4]. Many people in communities like TERENA, the ssmping tools at [5]. Many people in communities like TERENA,
Internet2 and the M6Bone have used early implementations of ssmping Internet2 and the M6Bone have used early implementations of ssmping
and provided feedback that have influenced the current protocol. and provided feedback that have influenced the current protocol.
Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Alfred Thanks to Kevin Almeroth, Tony Ballardie, Bill Cerveny, Toerless
Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui,
Sarac, Pekka Savola, Trond Skjesol and Cao Wei for reviewing and Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola,
providing feedback on this draft. In particular Hugo, Gorry and Trond Skjesol and Cao Wei for reviewing and providing feedback on
Bharat have provided lots of input on several revisions of the draft. this draft. In particular Hugo, Gorry and Bharat have provided lots
of input on several revisions of the draft.
10. IANA Considerations 8. IANA Considerations
IANA is requested to provide a well-known UDP port number for use by IANA is requested to assign a UDP user-port in the range 1024-49151
this protocol, and also to provide registries for message and option for use by this protocol, and also to provide registries for message
types. and option types. The string "[TBD]" in this document should be
replaced with the assigned port.
There should be a message types registry. Message types are in the There should be a message types registry. Message types are in the
range 0-255. Message types 0-191 require specification (an RFC or range 0-255. Message types 0-191 require specification (an RFC or
other permanent and readily available reference), while types 192-255 other permanent and readily available reference), while types 192-255
are for experimental use and are not registered. The registry should are for experimental use and are not registered. The registry should
include the messages defined in Section 5. A message specification include the messages defined in Section 3.4. A message specification
must describe the behaviour with known option types as well as the must describe the behaviour with known option types as well as the
default behaviour with unknown ones. default behaviour with unknown ones.
There should also be an option type registry. Option types 0-49151 There should also be an option type registry. Option types 0-49151
require specification (an RFC or other permanent and readily require specification (an RFC or other permanent and readily
available reference), while types 49152-65535 are for experimental available reference), while types 49152-65535 are for experimental
use and are not registered. The registry should include the options use and are not registered. The registry should include the options
defined in Section 3.2. An option specification must describe how defined in Section 3.2. An option specification must describe how
the option may be used with the known message types. This includes the option may be used with the known message types. This includes
which message types the option may be used with. which message types the option may be used with.
The initial registry definitions could be as follows: The initial registry definitions are as follows:
Multicast Ping Protocol Parameters: Multicast Ping Protocol Parameters:
Registry Name: Multicast Ping Protocol Message Types Registry Name: Multicast Ping Protocol Message Types
Reference: [this doc] Reference: [this doc]
Registration Procedures: Specification Required Registration Procedures: Specification Required
Registry: Registry:
Type Name Reference Type Name Reference
----------- ------------------------------------ ---------- ----------- ------------------------------------ ----------
skipping to change at page 17, line 42 skipping to change at page 18, line 42
5 Option Request Option [this doc] 5 Option Request Option [this doc]
6 Server Information [this doc] 6 Server Information [this doc]
7 Reserved [this doc] 7 Reserved [this doc]
8 Reserved [this doc] 8 Reserved [this doc]
9 TTL [this doc] 9 TTL [this doc]
10 Multicast Prefix [this doc] 10 Multicast Prefix [this doc]
11 Session ID [this doc] 11 Session ID [this doc]
12 Server Timestamp [this doc] 12 Server Timestamp [this doc]
49152-65535 Experimental 49152-65535 Experimental
11. Security Considerations 9. Security Considerations
There are some security issues to consider. One is that a host may There are some security issues to consider. One is that a host may
send a request with an IP source address of another host, and make an send an Echo Request with an IP source address of another host, and
arbitrary multicast ping server on the Internet send packets to this make an arbitrary multicast ping server on the Internet send packets
other host. This behaviour is fairly harmless. The worst case is if to this other host. This behaviour is fairly harmless. The worst
the host receiving the unicast replies also happen to be joined to case is if the host receiving the unicast Echo Replies also happens
the multicast group used. In this case, there would be an to be joined to the multicast group used. In this case, there would
amplification effect where the host receives twice as many replies as be an amplification effect where the host receives twice as many
there are requests sent. See below for how spoofing can be replies as there are requests sent. See below for how spoofing can
prevented. be prevented.
For ASM (Any-Source Multicast) a host could also make a multicast For ASM (Any-Source Multicast) a host could also make a multicast
ping server send multicast packets to a group that is used for ping server send multicast packets to a group that is used for
something else, possibly disturbing other uses of that group. The something else, possibly disturbing other uses of that group.
main concern is bandwidth. Since there is a well-known port, it However, server implementations should allow administrators to
should not be received by other applications. Due to this, a server restrict which groups a server responds to. The main concern is
on the Internet SHOULD perform rate limiting. bandwidth. To limit the bandwidth used, a server MUST by default
perform rate limiting, responding to at most one Echo Request per
second.
In order to help prevent spoofing, a server SHOULD require the client In order to help prevent spoofing, a server SHOULD require the client
to send an Init message, and return an unpredictable Session ID in to send an Init message, and return an unpredictable Session ID in
the response. The ID should be associated with the IP address and the response. The ID should be associated with the IP address and
have a limited lifetime. The server SHOULD then only respond to have a limited lifetime. The server SHOULD then only respond to Echo
Request messages that have a valid Session ID associated with the Request messages that have a valid Session ID associated with the
source IP address of the Request. source IP address of the Echo Request.
Server implementations should allow administrators to restrict which
groups a server responds to, and also perform rate limiting. This is
discussed in Section 8.
12. References 10. References
12.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[3] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[3] "IANA, Address Family Numbers", [4] "IANA, Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
12.2. Informative References 10.2. Informative References
[4] "ssmping implementation", [5] "ssmping implementation",
<http://www.venaas.no/multicast/ssmping/>. <http://www.venaas.no/multicast/ssmping/>.
[5] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for [6] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
Application Designers", draft-ietf-tsvwg-udp-guidelines-11 (work Application Designers", BCP 145, RFC 5405, November 2008.
in progress), October 2008.
Author's Address Author's Address
Stig Venaas Stig Venaas
UNINETT UNINETT
Trondheim NO-7465 Trondheim NO-7465
Norway Norway
Email: venaas@uninett.no Email: venaas@uninett.no
 End of changes. 90 change blocks. 
393 lines changed or deleted 431 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/