Network Working Group S. Venaas
Internet-Draft UNINETT
Intended status: Standards Track March 4, 2010
Expires: September 5, 2010
Multicast Ping Protocol
draft-ietf-mboned-ssmping-08.txt
Abstract
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.
Requirements Language
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 RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2010.
Copyright Notice
Venaas Expires September 5, 2010 [Page 1]
Internet-Draft Multicast Ping Protocol March 2010
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 7
3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Message Types and Options . . . . . . . . . . . . . . . . 13
3.5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 14
4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 15
5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 16
6. Recommendations for Implementers . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Venaas Expires September 5, 2010 [Page 2]
Internet-Draft Multicast Ping Protocol March 2010
1. Introduction
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 [RFC0792], but uses UDP [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.
This protocol is based on the current implementation of the ssmping
and asmping tools [impl] which are widely used by the Internet
community to conduct multicast connectivity tests.
2. Architecture
Before describing the protocol in detail, we provide a brief overview
of how the protocol may be used and what information it may provide.
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.
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
Venaas Expires September 5, 2010 [Page 3]
Internet-Draft Multicast Ping Protocol March 2010
giving the client a non-predictable session ID. This would then also
be part of the server soft-state for that client.
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.
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.
The typical protocol usage is as follows:
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.
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.
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.
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.
Venaas Expires September 5, 2010 [Page 4]
Internet-Draft Multicast Ping Protocol March 2010
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.
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.
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).
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.
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.
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).
Venaas Expires September 5, 2010 [Page 5]
Internet-Draft Multicast Ping Protocol March 2010
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
type, followed by a number of options in TLV (Type, Length and Value)
format. This makes the protocol easily extendible.
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 Section 8.
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.
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.
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.
Venaas Expires September 5, 2010 [Page 6]
Internet-Draft Multicast Ping Protocol March 2010
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.
3.1. Option Format
All options are TLVs formatted as below.
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 |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 octets) specifies the option.
Length (2 octets) specifies the length of the value field. Depending
on the option type, it can be from 0 to 65535.
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.
3.2. Defined Options
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.
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
Length MUST be 1. This option MUST always be included in all
messages, and for the current specified protocol this value
Venaas Expires September 5, 2010 [Page 7]
Internet-Draft Multicast Ping Protocol March 2010
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).
Client ID, type 1
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.
Sequence Number, type 2
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.
Client Timestamp, type 3
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
Venaas Expires September 5, 2010 [Page 8]
Internet-Draft Multicast Ping Protocol March 2010
specified in the first 4 bytes. This option would typically be
used by a client to compute round trip times.
Multicast Group, type 4
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.
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for
Internet address families [addrfamily]. This is followed by
the group address. Length of the option value will be 6 for
IPv4, and 18 for IPv6.
Option Request Option, type 5
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
This option might be used by the client to ask the server to
Venaas Expires September 5, 2010 [Page 9]
Internet-Draft Multicast Ping Protocol March 2010
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.
Server Information, type 6
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.
Reserved, type 7
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).
Reserved, type 8
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).
Venaas Expires September 5, 2010 [Page 10]
Internet-Draft Multicast Ping Protocol March 2010
TTL, type 9
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.
Multicast Prefix, type 10
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.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for
Internet address families [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.
Session ID, type 11
Venaas Expires September 5, 2010 [Page 11]
Internet-Draft Multicast Ping Protocol March 2010
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.
Server Timestamp, type 12
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.
3.3. Packet Format
The format of all messages is a one octet message type, followed by a
variable number of options.
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 ... |
+-+-+-+-+-+-+-+-+ . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .....
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.
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.
Venaas Expires September 5, 2010 [Page 12]
Internet-Draft Multicast Ping Protocol March 2010
3.4. Message Types and Options
There are four message types defined. We will now describe each of
the message types and which options they may contain.
Init, type 73
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.
Server Response, type 83
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.
Echo Request, type 81
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.
Echo Reply, type 65
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
Venaas Expires September 5, 2010 [Page 13]
Internet-Draft Multicast Ping Protocol March 2010
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).
The below matrix summarises what options can go in what messages.
\ 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 |
-----------------------+--------+----------+---------+--------+
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.
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.
Venaas Expires September 5, 2010 [Page 14]
Internet-Draft Multicast Ping Protocol March 2010
Implementers of applications/tools using this protocol SHOULD
consider the UDP guidelines [RFC5405], 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
protocol would behave.
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.
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.
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.
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.
Venaas Expires September 5, 2010 [Page 15]
Internet-Draft Multicast Ping Protocol March 2010
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.
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.
5. Server Behaviour
We will consider how a typical server using the above protocol would
behave, first looking at how to respond to Init messages.
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.
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
Venaas Expires September 5, 2010 [Page 16]
Internet-Draft Multicast Ping Protocol March 2010
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.
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.
6. Recommendations for Implementers
The protocol as specified is fairly flexible and leaves a lot of
freedom for implementers. In this section we present some
recommendations.
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.
As specified in Section 3.5, 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.
If a server uses different policies for different IP addresses, it
should require clients to send Init messages and return an
Venaas Expires September 5, 2010 [Page 17]
Internet-Draft Multicast Ping Protocol March 2010
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
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 [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.
8. IANA Considerations
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.
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 Section 3.4. A message specification
must describe the behaviour with known option types as well as the
default behaviour with unknown ones.
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 Section 3.2. 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.
The initial registry definitions are as follows:
Venaas Expires September 5, 2010 [Page 18]
Internet-Draft Multicast Ping Protocol March 2010
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
9. Security Considerations
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
Venaas Expires September 5, 2010 [Page 19]
Internet-Draft Multicast Ping Protocol March 2010
be prevented.
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.
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.
10. References
10.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[addrfamily]
"IANA, Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>.
10.2. Informative References
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
[impl] "ssmping implementation",
<http://software.uninett.no/ssmping/>.
Venaas Expires September 5, 2010 [Page 20]
Internet-Draft Multicast Ping Protocol March 2010
Author's Address
Stig Venaas
UNINETT
Trondheim NO-7465
Norway
Email: venaas@uninett.no
Venaas Expires September 5, 2010 [Page 21]
