One document matched: draft-ietf-mboned-ssmping-08.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-mboned-ssmping-08.txt">
<front>
<title>Multicast Ping Protocol</title>
<author initials='S.' surname='Venaas' fullname='Stig Venaas'>
<organization>UNINETT</organization>
<address>
<postal>
<city>Trondheim</city>
<code>NO-7465</code>
<country>Norway</country>
</postal>
<email>venaas@uninett.no</email>
</address>
</author>
<date/>
<abstract><t>The Multicast Ping Protocol specified
in this document allows for checking whether an endpoint can receive
multicast, both Source-Specific Multicast (SSM) and Any-Source
Multicast (ASM). It can also be used to obtain additional
multicast-related information such as multicast tree setup time.
This protocol is based on an implementation of tools
called ssmping and asmping.
</t></abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>The Multicast Ping Protocol specified in this
document allows for checking multicast connectivity. In addition to
checking reception of multicast (SSM or ASM), the protocol can provide
related information such as multicast tree setup time, the number of hops
the packets have traveled, as well as packet delay and loss.
This functionality resembles, in part, the ICMP Echo Request/Reply
mechanism <xref target="RFC0792"/>, but uses UDP <xref target="RFC0768"/>
and requires both
a client and a server implementing this protocol.
Intermediate routers are not required to support this protocol. They
forward Protocol Messages and data traffic as usual.
</t><t>
This protocol is based on the current implementation of
the ssmping and asmping tools <xref target="impl"/> which are widely
used by the Internet community to conduct multicast connectivity tests.
</t>
</section>
<section title="Architecture" anchor="arch">
<t>Before describing the protocol in detail, we provide a brief
overview of how the protocol may be used and what information it may
provide.
</t><t>
The protocol is used between clients and servers. A server may be
configured with a set of ranges of multicast addresses that can be
used for testing, or it may use some implementation defaults.
Depending on the server configuration or the implementation it may
control which clients
(which unicast addresses) are allowed to use different group ranges,
and also whether clients can select a group address, or if the
group address is selected by the server. It also depends on
configuration and/or implementation whether several clients are
allowed to simultaneously use the same multicast address.
</t><t>
In addition to the above state, a server normally has runtime
soft state. The server must generally perform rate limiting to
restrict the number of client requests it handles. This rate
limiting is per client IP address. This state need only be
maintained for a few seconds (normally to have an average rate of
maximum one request per second). If the server provides unique
multicast addresses to clients, it must also have soft state tracking
which multicast addresses are used by which client IP address. This
state should expire if the server has not received requests within
a few minutes. The exact timeout should ideally be configurable to
cope with different environments. If a client is expected to perform
multicast ping checks continuously for a long period of time, and to
cope with requests not reaching the client for several minutes, then
this timeout needs to be extended. In order to verify the client IP
address, the server should perform a return routability check by
giving the client a non-predictable session ID. This would then also
be part of the server soft-state for that client.
</t><t>
A client must before it can perform a multicast ping test, know the
unicast address of a server. In addition it may be
configured with a multicast address or range to use. In
that case the client will tell the server which group or range it
wishes to use. If not, the server is left to decide the group.
Normally a client sends one request per second. It may however be
configured to use another rate.
</t><t>
At runtime, a client generates a client ID that is unique for the
ping test. This ID is included in all messages sent by the client.
Further, if not supplied with a specific group address, the client
will receive a group address from the server, that is used for the
ping requests. It may also receive a Session ID from the server.
The client ID, group address and Session ID (if received) will then
be fixed for all ping requests in this session. When a client
receives replies from a server, it will verify the client ID in the
reply, and ignore it if not matching what it used in the requests.
For each reply it may print or record information like round trip
time, number of hops etc. The client may once a ping session is
ended, calculate and print or record statistics based on the entire
ping session.
</t>
<list style="hanging">
<t hangText="The typical protocol usage is as follows:">
<vspace blankLines="1"/>
A server runs continuously to serve requests from clients. A client
has somehow learned the unicast address of the server and tests
the multicast reception from the server.
<vspace blankLines="1"/>
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 group matching the user's request. The
server will respond with a group to use, or an error if no group is
available.
<vspace blankLines="1"/>
Next, for ASM, the client joins an ASM group G, while for
SSM it 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.
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
Both replies are sent from the same port on which the request was received.
The server should specify the TTL (IPv4 time-to-live or IPv6 hop-count)
used for both the unicast and multicast messages
(TTL of at least 64 is recommended) by including a TTL option.
This allows the client
to compute the number of hops. The client should leave the group/channel
when it has finished its measurements.
</t>
</list>
<t>
By use of this protocol, a client (or a user of the client) can obtain
information about
several multicast delivery characteristics. First, by receiving
unicast replies, the client can verify that the server is receiving the
unicast requests, is operational and responding. Hence, provided that
the client receives unicast replies, a failure to receive multicast
indicates either a multicast problem or a multicast administrative
restriction. If it does receive multicast, it knows not only
that it can receive multicast traffic, it may also estimate the amount
of time it took to
establish the multicast tree (at least if it is in the
range of seconds), whether there are packet drops, and the length
and variation of Round Trip Times (RTT).
</t><t>
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.
</t><t>
The number of multicast hops and changes in the number of
hops over time may 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.
</t><t>
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).</t>
</section>
<section title="Protocol Specification" anchor="protocol">
<t>
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.
</t><t>
The messages share a common format: one octet
specifying the message type, followed by a number of options in
TLV (Type, Length and Value) format. This makes the protocol
easily extendible.
</t><t>
Message types in the range 0-191 are reserved and available for
allocation in an IANA Registry. Message types in the range 192-255
are not registered and are freely available for experimental use.
See <xref target="iana"/>.
</t><t>
The Init message generally contains some
prefix options asking the server for a group from one of the
specified prefixes. The server responds with a Server Response
message that contains the group address to use, or possibly
prefix options describing what multicast groups the server may
be able to provide.
</t><t>
For an Echo Request the client generally includes a number of
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, but it severly limits
what information a client can obtain, and hence makes the
protocol less useful. However, the server SHOULD add a TTL option
(allowing the client to determine the number of router hops a reply
has traversed), 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 from the request (in the same order),
and then, immediately following, any options appended by the server.
A server MUST NOT process unknown options, but they MUST still
be included in the Echo Reply. A client MUST ignore any unknown
options.
</t><t>
The size of the protocol messages is generally smaller than the
Path 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 requests in order to verify that it can receive
fragmented multicast datagrams. This document does not specify
whether Path MTU Discovery should be performed, etc. A possible
extension could be an option where a client requests Path MTU
Discovery and receives the current Path MTU from the server.
</t>
<t>
This document defines a number of different options. Some options
do not require processing by servers and are simply returned unmodified
in the reply. There are, however, other client options that the server
may care about, as well as server options that may be requested by a
client.
Unless otherwise specified, an option MUST NOT be used multiple
times in the same message.
</t>
<section title="Option Format" anchor="optformat">
<t>All options are TLVs formatted as below.
<figure><artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure></t>
<t>Type (2 octets) specifies the option.</t>
<t>Length (2 octets) specifies the length of the value field. Depending on
the option type, it can be from 0 to 65535.</t>
<t>Value must always be of the specified length. See the
respective option definitions for possible values. If the length is
0, the value field is not included.</t>
</section>
<section title="Defined Options" anchor="opts">
<t>This document defines the following options: Version (0),
Client ID (1), Sequence Number (2), Client Timestamp (3),
Multicast Group (4), Option Request Option (5),
Server Information (6), TTL (9), Multicast Prefix (10),
Session ID (11) and Server Timestamp (12). Values 7 and 8 are
reserved. The options are defined below.
</t><t>
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 <xref target="iana"/>.
</t>
<list style="empty">
<t>Version, type 0
<list style="empty"><t>
Length MUST be 1. This option MUST always be
included in all messages, and for the current specified protocol this
value MUST be set to 2 (in decimal).
Note that there are implementations of older revisions of this
protocol that only partly
follow this specification. They can be regarded as version 1 and do
not use this option. If a server receives a message with a version
other than 2 (or missing), the server SHOULD (unless it supports the
particular version) send a Server Response message back with version set to
2. This tells the client that the server expects version 2 messages.
Client ID and Sequence Number options SHOULD be echoed if
present, so that a client can be certain it is a response to one of
its messages, and exactly which message. The server SHOULD NOT include
any other options. A client receiving
a response with a version other than 2 MUST stop sending requests to the server
(unless it supports the particular version).
</t></list></t>
<t>Client ID, type 1
<list style="empty"><t>
Length MUST be non-zero.
A client SHOULD always include this option in all messages
(both Init and Echo Request). The client may use any value it likes to
detect whether a reply is a reply to its Init/Echo Request or not.
A server should treat this as opaque data, and MUST echo this option
back in the reply if present (both Server Response and Echo Reply).
The value might be a randomised string that is likely to be unique,
possibly combined with the client IP address. This is used by the
client to ensure that server messages are in response to its
requests. In some cases a client may receive multicast responses to
queries from other clients.
It is left to the client implementer how to use this option.
</t></list></t>
<t>Sequence Number, type 2
<list style="empty"><t>
Length MUST be 4.
A client MUST always include this in Echo Request messages and MUST NOT
include it in Init messages. A server replying to an Echo Request message
MUST copy it into the Echo Reply (or Server Response message on error).
The sequence number is a 32-bit integer. Values typically
start at 1 and increase by one for each Echo Request in a sequence.
</t></list></t>
<t>Client Timestamp, type 3
<list style="empty"><t>
Length MUST be 8 bytes. A client SHOULD
include this in Echo Request messages and MUST NOT include it in Init
messages. A server replying to an Echo Request message MUST copy it into
the Echo Reply.
The timestamp specifies the time when the Echo Request message is sent.
The first 4 bytes specify the number of seconds since the Epoch
(0000 UTC Jan 1, 1970). The next 4 bytes specify the number
of microseconds since the second specified in the first 4 bytes. This
option would typically be used by a client to compute round trip times.
</t></list></t>
<t>Multicast Group, type 4
<list style="empty"><t>
Length MUST be greater than 2. It MAY
be used in Server Response messages to tell the client what group
to use in subsequent Echo Request messages. It MUST be used in Echo
Request messages to tell the server what group address to respond to
(this group would typically be previously obtained in a Server Response
message). It MUST be used in Echo Reply messages (copied from the Echo
Request message). It MUST NOT be used in Init messages.
The format of the option value is as below.
<figure><artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Multicast group address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
</artwork></figure>
The address family is a value 0-65535 as assigned by IANA for Internet
address families <xref target="addrfamily"/>.
This is followed by the group address.
Length of the option value will be 6 for IPv4, and 18 for IPv6.
</t></list></t>
<t>Option Request Option, type 5
<list style="empty"><t>
Length MUST be greater than
1. This option MAY be used in client messages (Init and Echo Request
messages). A server MUST NOT send this option, except that if
it is present in an Echo Request message, the server MUST echo it
in replies (Echo Reply message) to the Echo Request.
This option contains a list of option types for options that
the client is requesting from the server. Support for this option
is optional for both clients and servers. The length of this option
will be a non-zero even number, since it contains one or more option
types that are two octets each. The format of the option value is as
below.
<figure><artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
</artwork></figure>
This option might be used by the client to ask the server to include
options like Timestamp or Server Information. A client MAY request
Server Information in Init messages; it MUST NOT request it in
other messages. A client MAY request a timestamp in Echo Request
messages; it MUST NOT request it in other messages.
Subject to enforcing the above restrictions, a server supporting this
option SHOULD include the requested options in responses (Echo Reply
messages) to the Echo Request containing the Option Request Option. The
server may, according to implementation or local configuration, not
necessarily include all the requested options, or possibly none. Any
options included are appended to the echoed options, similar to
other options included by the server.
</t></list></t>
<t>Server Information, type 6
<list style="empty"><t>
Length MUST be non-zero. It MAY
be used in Server Response messages and MUST NOT be used in other
messages. Support for this
option is optional. A server supporting this option SHOULD add
it in Server Response messages if and only if requested by the
client. The value is a UTF-8 string that might contain vendor
and version information for the server implementation. It may
also contain information on which options the server supports.
An interactive client MAY support this option, and SHOULD then
allow a user to request this string and display it. Although
support for this is optional, we say that a server SHOULD
return it if requested, since this may be helpful to a user
running the client. It is however purely informational, it is
not needed for the protocol to function.
</t></list></t>
<t>Reserved, type 7
<list style="empty"><t>
This option code value was used by early
implementations for an option that is now deprecated. This option
should no longer be used. Clients MUST NOT use this option.
Servers MUST treat it as an unknown option (not process it if
received, but if received in an Echo Request message, it MUST be
echoed in the Echo Reply message).
</t></list></t>
<t>Reserved, type 8
<list style="empty"><t>
This option code value was used by early
implementations for an option that is now deprecated. This option
should no longer be used. Clients MUST NOT use this option.
Servers MUST treat it as an unknown option (not process it if
received, but if received in an Echo Request message, it MUST be
echoed in the Echo Reply message).
</t></list></t>
<t>TTL, type 9
<list style="empty"><t>
Length MUST be 1. This option contains a single
octet specifying the TTL of an Echo Reply message. Every time a server
sends a unicast or multicast Echo Reply message, it SHOULD include
this option specifying the TTL. This is used by clients to
determine the number of hops the messages have traversed. It
MUST NOT be used in other messages. A server SHOULD specify this
option if it knows what the TTL of the Echo Reply will be. In general
the server can specify a specific TTL to the host stack. Note
that the TTL is not necessarily the same for unicast and
multicast. Also note that this option SHOULD be included even when not
requested by the client. The protocol will work even if this option is
not included, but it limits what information a client can obtain.
</t></list></t>
<t>Multicast Prefix, type 10
<list style="empty"><t>
Length MUST be greater than 2. It MAY
be used in Init messages 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 may try to obtain a group from. It MUST NOT be used
in Echo Request/Reply messages. Note that this option MAY be included
multiple times to specify multiple prefixes.
<figure><artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Prefix Length |Partial address|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
</artwork></figure>
The address family is a value 0-65535 as assigned by IANA for Internet
address families <xref target="addrfamily"/>.
This is followed by a prefix length (4-32 for IPv4, 8-128 for IPv6,
or 0 for the special "wildcard" use discussed below),
and finally a group address. For any family, prefix length 0 means
that any multicast address from that family is acceptable. This is
what we call "wildcard."
The group
address need only contain enough octets 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 there need be no group address for the
wildcard with prefix length 0). Any bits past the prefix length MUST
be ignored. 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.
</t></list></t>
<t>Session ID, type 11
<list style="empty"><t>
Length MUST be non-zero. A server SHOULD
include this in Server Response messages. If a client
receives this option in a message, the client MUST echo the
Session ID option in subsequent Echo Request messages, with the exact
same value. The Session ID may help the
server in keeping track of clients and possibly manage per client
state. The value of a new Session ID SHOULD be chosen pseudo
randomly so that it is hard to predict. The Session ID can be used
to prevent spoofing of the source address of Echo Request messages.
We say that this option SHOULD be used, because it is important for
security reasons. There may however be environments where this is
not required. See the Security Considerations for details.
</t></list></t>
<t>Server Timestamp, type 12
<list style="empty"><t>
Length MUST be 8 bytes. A server
supporting this option, SHOULD include it in Echo Reply messages,
if requested by the client. The timestamp specifies
the time when the Echo Reply message is sent. The first 4
bytes specify the number of seconds since the Epoch
(0000 UTC Jan 1, 1970). The next 4 bytes specify the number
of microseconds since the second specified in the first 4 bytes.
If this option is not included, the protocol will still work, but
it makes it impossible for a client to compute one way delay.
</t></list></t>
</list>
</section>
<section title="Packet Format" anchor="format">
<t>The format of all messages is a one octet message type,
followed by a variable number of options.
<figure><artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Options ... |
+-+-+-+-+-+-+-+-+ . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .....
</artwork></figure></t>
<t>There are four message types defined. Type 81 (the character Q in
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) is an Init message, and type 83 (the character S in ASCII) is a
Server Response message.</t>
<t>The options immediately follow the type octet and are not aligned in
any way (no spacing or padding), i.e., options might start at any
octet boundary. The option format is specified above.</t>
</section>
<section title="Message Types and Options" anchor="msgs">
<t>There are four message types defined. We will now describe
each of the message types and which options they may contain.
</t>
<list style="empty">
<t>Init, type 73
<list style="empty"><t>
This message is sent by a client to request
information from a server. It is mainly used for requesting a
group address, but it may also be used to check which group
prefixes the server may provide groups from, or other server
information. It MUST include a Version option, and SHOULD include
a Client ID. It MAY include Option Request and Multicast
Prefix Options. This message is a request for a group address
if and only if it contains Multicast Prefix options. If
multiple Prefix options are included, they should be in prioritised
order. I.e., the server will consider the prefixes in the order
they are specified, and if it finds a group for a prefix,
it will only return that one group, not considering the remaining
prefixes.
</t></list></t>
<t>Server Response, type 83
<list style="empty"><t>
This message is sent by a
server, either as a response to an Init, or in response to
an Echo Request. When responding to Init, it may provide the client
with a multicast group (if requested by the client), or it may
provide other server information. In response to an Echo Request, the
message tells the client to stop sending Echo Requests. The Version
option MUST always be included. Client ID and Sequence Number options
are echoed if present in the client message. When providing
a group to the client, it includes a Multicast Group option.
It SHOULD include Server Information and Prefix options if
requested.
</t></list></t>
<t>Echo Request, type 81
<list style="empty"><t>
This message is sent by a client, asking the server to send unicast
and multicast Echo Replies. It MUST include
Version, Sequence Number and Multicast Group options.
If a Session ID was received in a Server Response message,
then the Session ID MUST be included.
It SHOULD include Client ID and Client Timestamp options.
It MAY include an Option Request option.
</t></list></t>
<t>Echo Reply, type 65
<list style="empty"><t>
This message is sent by a server in response
to an Echo Request message. This message is always sent in pairs,
one as unicast and one as multicast. The contents of the messages
are mostly the same. The server always echoes all of the options
(but never the Session ID) from the Echo Request. Any options in the
Echo Request that are unsupported by the server, are also to be
echoed. The two Echo Reply messages SHOULD both always contain a
TTL option (not necessarily equal). Both Echo Reply messages SHOULD
also when requested contain Server Timestamps (not necessarily equal).
</t></list></t>
</list>
<t>The below matrix summarises what options can go in what messages.
<figure><artwork>
\ Message Type | Init | Server | Echo | Echo |
Option \ | | Response | Request | Reply |
-----------------------+--------+----------+---------+--------+
Version (0) | MUST | MUST | MUST | ECHO |
Client ID (1) | SHOULD | ECHO | SHOULD | ECHO |
Sequence Number (2) | NOT | ECHO | MUST | ECHO |
Client Timestamp (3) | NOT | NOT | SHOULD | ECHO |
Multicast Group (4) | NOT | MAY | MUST | ECHO |
Option Request (5) | MAY | NOT | MAY | ECHO |
Server Information (6) | NOT | RQ | NOT | NOT |
Reserved (7) | NOT | NOT | NOT | ECHO |
Reserved (8) | NOT | NOT | NOT | ECHO |
TTL (9) | NOT | NOT | NOT | SHOULD |
Multicast Prefix (10) | MAY | MAY | NOT | NOT |
Session ID (11) | NOT | SHOULD | ECHO | NOT |
Server Timestamp (12) | NOT | NOT | NOT | RQ |
-----------------------+--------+----------+---------+--------+
</artwork></figure>
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
MUST echo the option in the response, with the exact same option
value.
ECHO for a client only applies to the Session ID option. If it is
present in the Server Response, then it MUST be present with the
exact same option value in the following Echo Requests.
RQ means that the server SHOULD include the option in the response,
when requested by the client using the Option Request option.
</t>
</section>
<section title="Rate Limiting" anchor="rate">
<t>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.
</t><t>
Implementers of applications/tools using this protocol SHOULD consider
the <xref target="RFC5405">UDP guidelines</xref>,
in particular if clients are to send, or servers are to accept,
Echo Requests at rates exceeding one per second.
See <xref target="seccons"/>, "Security Considerations", for
additional discussion.
</t>
</section>
</section>
<section title="Client Behaviour" anchor="clbeh">
<t>We will consider how a typical interactive client using the
above protocol would behave.
</t><t>
A client only requires a user to
specify the unicast address of the server. It can then send an Init
message with a prefix option containing the desired address family
and zero prefix length (wildcard entry). The server can then
decide which group, from the specified family, it should return.
A client may also allow the user to specify
group address(es) or prefix(es) (for IPv6, the user may only be
required to specify a scope or an RP address, from which the client
can construct the desired prefix, possibly embedded-RP). From this
the client can specify one or more prefix options in an Init message
to tell the server which address it would prefer. If the user
specifies a group address, that can be encoded as a prefix of
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.
</t><t>
If the client receives a Server Response message containing a group
address it can start sending Echo Request messages, see the next
paragraph. If there is no group address option, the client would
typically exit with an error message. The server may have included some
prefix options in the Server Response. The client may use this to
provide the user some feedback on what prefixes or scopes are
available.
</t><t>
Assuming the client got a group address in a Server Response, it
can start the multicast pings, after letting the user know
which group is being used. Normally, a client should send at most one
Echo Request per second.
</t><t>
When sending the Echo Requests, the client
must always include the group option. If the Server Response
contained a Session ID, then it must also include
that, with the exact same value, in the Echo Requests.
If a client receives a Server
Response message in response to an Echo Request (that is, a
Server Response message containing a sequence number), this means
there is an error and it should stop sending Echo Requests.
This could happen after server restart.
</t><t>
The client may allow the user to request server
information. If the user requests server information, the client
can send an Init message with no prefix options, but with an
Option Request Option, requesting the server to return a Server
Information option. The server will return server information if
supported, and it may also return a list 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 an Init message
with no prefixes and not requesting any specific options.
</t><t>
Although not recommended, a client may pick a multicast group and
send Echo Request
messages without first going through the Init - Server Response
negotiation. If this is supported by the server and the server
is okay with the group used, the server can then send Echo Reply
messages as usual. If the server is not okay, it will send a
Server Response telling the client to stop.
</t>
</section>
<section title="Server Behaviour">
<t>We will consider how a typical server using the above protocol
would behave, first looking at how to respond to Init messages.
</t><t>
If the 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
with, possibly have a default, a set of groups it can offer.
It may have a large pool and pick a group at random, or
possibly choosing a group based on hashing of the client's IP
address or identifier, or simply 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.
</t><t>
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.
</t><t>
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
try to request a group address.
The unicast and multicast Echo Reply messages have
identical UDP payload apart from possibly TTL and timestamp
option values.
<t></t>
Note that the server may receive Echo Request messages with no
prior Init message. This may happen when the server restarts
or if a client sends an Echo Request with no prior Init message.
The server may go ahead and respond if it is okay with the group
used. If the group is not okay,
the server sends back a Server Response.
</t>
</section>
<section title="Recommendations for Implementers" anchor="imprec">
<t>
The protocol as specified is fairly flexible and leaves a lot of
freedom for implementers. In this section we present some
recommendations.
</t>
<t>Server administrators should be able to configure one or
multiple group prefixes in a server implementation. When
deploying servers on the Internet and in other environments,
the server administrator should be able to restrict the server
to respond to only a few multicast groups which should not be
currently used by multicast applications. A server implementation
should also provide flexibility for an administrator to apply
various policies to provide one or multiple group prefixes to
specific clients, e.g., site scoped addresses for clients that
are inside the site.
</t><t>
As specified in <xref target="rate"/>, a server must by default
for a given client, respond to at most one Echo Request message per
second. A leaky bucket 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 administrative
control of which client IP addresses to serve, and may also allow
certain clients to perform more rapid Echo Requests.
</t><t>
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 <xref target="rate"/>.
</t>
</section>
<section title="Acknowledgments">
<t>The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and
Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source
Specific Multicast, and also the Internet Draft draft-sarac-mping-00.txt.
Mickael Hoerdt has contributed with several ideas. Alexander Gall,
Nicholas Humfrey, Nick Lamb and Dave Thaler have contributed in
different ways to the
implementation of the ssmping tools at <xref target="impl"/>.
Many people in
communities like TERENA, Internet2 and the M6Bone have used early
implementations of ssmping and provided feedback that have influenced
the current protocol. Thanks to Kevin Almeroth, Tony Ballardie,
Bill Cerveny, Toerless Eckert, Marshall Eubanks,
Gorry Fairhurst, Alfred Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem,
Hugo Santos, Kamil Sarac, Pekka Savola, Trond Skjesol and Cao Wei
for reviewing and providing feedback on this draft. In particular
Hugo, Gorry and Bharat have provided lots of input on several
revisions of the draft.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>IANA is requested to assign a UDP user-port in the
range 1024-49151 for use by this
protocol, and also to provide registries for message and option
types. The string "[TBD]" in this document should be replaced with
the assigned port.
</t><t>
There should be a message types registry. Message types are in
the range 0-255. Message types 0-191 require specification (an
RFC or other permanent and readily available reference), while
types 192-255 are for experimental use and are not registered.
The registry should include the messages defined in
<xref target="msgs"/>.
A message specification must describe the behaviour with known
option types as well as the default behaviour with unknown ones.
</t><t>
There should also be an option type registry. Option types
0-49151 require specification (an RFC or other permanent and
readily available reference),
while types 49152-65535 are for experimental use and are not
registered.
The registry should include the options defined in
<xref target="opts"/>.
An option specification must describe how the option may
be used with the known message types. This includes which
message types the option may be used with.
</t>
<t>
The initial registry definitions are as follows:
<figure><artwork>
Multicast Ping Protocol Parameters:
Registry Name: Multicast Ping Protocol Message Types
Reference: [this doc]
Registration Procedures: Specification Required
Registry:
Type Name Reference
----------- ------------------------------------ ----------
65 Echo Reply [this doc]
73 Init [this doc]
81 Echo Request [this doc]
83 Server Response [this doc]
192-255 Experimental
Registry Name: Multicast Ping Protocol Option Types
Reference: [this doc]
Registration Procedures: Specification Required
Registry:
Type Name Reference
----------- ------------------------------------ ----------
0 Version [this doc]
1 Client ID [this doc]
2 Sequence Number [this doc]
3 Client Timestamp [this doc]
4 Multicast Group [this doc]
5 Option Request Option [this doc]
6 Server Information [this doc]
7 Reserved [this doc]
8 Reserved [this doc]
9 TTL [this doc]
10 Multicast Prefix [this doc]
11 Session ID [this doc]
12 Server Timestamp [this doc]
49152-65535 Experimental
</artwork></figure></t>
</section>
<section title="Security Considerations" anchor="seccons">
<t>There are some security issues to consider. One is that a host
may send an Echo Request with an IP source address of another host,
and make an arbitrary multicast ping server on the Internet send
packets to this other host. This behaviour is fairly harmless.
The worst case is if the host receiving the unicast Echo
Replies also happens to be joined to the multicast group used. In
this case, there would be an amplification effect where the host
receives twice as many replies as there are requests sent. See
below for how spoofing can be prevented.
</t><t>
For ASM (Any-Source Multicast) a host could also make a multicast
ping server send multicast packets to a group that is used for
something else, possibly disturbing other uses of that group.
However, server implementations should allow administrators to restrict
which groups a server responds to.
The main concern is bandwidth. To limit the bandwidth used, a server
MUST by default perform rate limiting, responding to at most one
Echo Request per second.
</t><t>
In order to help prevent spoofing, a server SHOULD require the
client to send an Init message, and return an unpredictable
Session ID in the response. The ID should be associated with the
IP address and have a limited lifetime. The server SHOULD then
only respond to Echo Request messages that have a valid Session ID
associated with the source IP address of the Echo Request.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0792" ?>
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.2119" ?>
<reference target="http://www.iana.org/assignments/address-family-numbers" anchor="addrfamily">
<front>
<title>IANA, Address Family Numbers</title>
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5405" ?>
<reference target="http://software.uninett.no/ssmping/" anchor="impl">
<front>
<title>ssmping implementation</title>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:12:32 |