draft-ietf-mboned-ssmping-07.txt   draft-ietf-mboned-ssmping-08.txt 
Network Working Group S. Venaas Network Working Group S. Venaas
Internet-Draft UNINETT Internet-Draft UNINETT
Intended status: Standards Track December 2, 2008 Intended status: Standards Track March 4, 2010
Expires: June 5, 2009 Expires: September 5, 2010
Multicast Ping Protocol Multicast Ping Protocol
draft-ietf-mboned-ssmping-07 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 5, 2009. This Internet-Draft will expire on September 5, 2010.
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 Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is subject to BCP 78 and the IETF Trust's Legal
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Provisions Relating to IETF Documents
document are to be interpreted as described in RFC 2119 [1]. (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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 7
3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Message Types and Options . . . . . . . . . . . . . . . . 11 3.4. Message Types and Options . . . . . . . . . . . . . . . . 13
3.5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 13 3.5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 14
4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 15
5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 15 5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 16
6. Recommendations for Implementers . . . . . . . . . . . . . . . 16 6. Recommendations for Implementers . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
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 such as 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 [2], but uses UDP [3] and requires both a client and a mechanism [RFC0792], but uses UDP [RFC0768] and requires both a
server implementing this protocol. Intermediate routers are not client and a server implementing this protocol. Intermediate routers
required to support this protocol. They forward Protocol Messages are not required to support this protocol. They forward Protocol
and data traffic as usual. Messages and data traffic as usual.
This protocol is based on the current implementation of the ssmping This protocol is based on the current implementation of the ssmping
and asmping tools [5] which are widely used by the Internet community and asmping tools [impl] which are widely used by the Internet
to conduct multicast connectivity tests. community 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 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
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: The typical protocol usage is as follows:
A server runs continuously to serve requests from clients. A A server runs continuously to serve requests from clients. A
client has somehow learned the unicast address of the server and client has somehow learned the unicast address of the server and
tests the multicast reception from the server. tests the multicast reception from the server.
The client application will then send a unicast message to the The client application will then send a unicast message to the
server asking for a group to use. Optionally a user may request a 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
skipping to change at page 5, line 33 skipping to change at page 6, line 33
The Init message generally contains some prefix options asking the The Init message generally contains some prefix options asking the
server for a group from one of the specified prefixes. The server server for a group from one of the specified prefixes. The server
responds with a Server Response message that contains the group responds with a Server Response message that contains the group
address to use, or possibly prefix options describing what multicast address to use, or possibly prefix options describing what multicast
groups the server may be able to provide. groups the server may be able to provide.
For an Echo Request the client generally includes a number of For an Echo Request the client generally includes a number of
options, and a server MAY simply echo the contents (only changing the options, and a server MAY simply echo the contents (only changing the
message type) without inspecting the options if it does not support message type) without inspecting the options if it does not support
any options. This might be true for a simple Multicast Ping Protocol any options. This might be true for a simple Multicast Ping Protocol
server. However, the server SHOULD add a TTL option, and there are server, but it severly limits what information a client can obtain,
other options that a server implementation MAY support, e.g., the and hence makes the protocol less useful. However, the server SHOULD
client may ask for certain information or a specific behaviour from add a TTL option (allowing the client to determine the number of
the server. The Echo Replies (one unicast and one multicast) MUST router hops a reply has traversed), and there are other options that
first contain the exact options (excluding the Session ID option) a server implementation MAY support, e.g., the client may ask for
from the request (in the same order), and then, immediately certain information or a specific behaviour from the server. The
following, any options appended by the server. A server MUST NOT Echo Replies (one unicast and one multicast) MUST first contain the
process unknown options, but they MUST still be included in the Echo exact options from the request (in the same order), and then,
Reply. A client MUST ignore any unknown options. 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 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.
skipping to change at page 7, line 9 skipping to change at page 8, line 10
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 for the current specified protocol this value messages, and for the current specified protocol this value
MUST be set to 2 (in decimal). Note that there are MUST be set to 2 (in decimal). Note that there are
implementations of older revisions of this protocol that only implementations of older revisions of this protocol that only
partly follow this specification. They can be regarded as partly follow this specification. They can be regarded as
version 1 and do not use this option. If a server receives a version 1 and do not use this option. If a server receives a
message with a version other than 2 (or missing), the server message with a version other than 2 (or missing), the server
SHOULD (unless it supports the particular version) send a SHOULD (unless it supports the particular version) send a
Server Response message back with version set to 2. Client ID Server Response message back with version set to 2. This tells
and Sequence Number options SHOULD be echoed if present. The the client that the server expects version 2 messages. Client
server SHOULD NOT include any other options. A client ID and Sequence Number options SHOULD be echoed if present, so
receiving a response with a version other than 2 MUST stop that a client can be certain it is a response to one of its
sending requests to the server (unless it supports the messages, and exactly which message. The server SHOULD NOT
particular version). 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 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 Echo Request). The option in all messages (both Init and Echo Request). The
client may use any value it likes to detect whether a reply is 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 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 this as opaque data, and MUST echo this option back in the
reply if present (both Server Response and Echo Reply). The reply if present (both Server Response and Echo Reply). The
value might be a process ID, perhaps process ID combined with value might be a randomised string that is likely to be unique,
an IP address because it may receive multicast responses to possibly combined with the client IP address. This is used by
queries from other clients. It is left to the client the client to ensure that server messages are in response to
implementer how to use this option. 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 Sequence Number, type 2
Length MUST be 4. A client MUST always include this in Echo Length MUST be 4. A client MUST always 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 an Echo Request message MUST copy it into server replying to an Echo Request message MUST copy it into
the Echo Reply (or Server Response message on error). The the Echo Reply (or Server Response message on error). The
sequence number is a 32-bit integer. Values typically start at sequence number is a 32-bit integer. Values typically start at
1 and increase by one for each Echo 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 Echo 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 an Echo Request message MUST copy it into server replying to an Echo Request message MUST copy it into
the Echo Reply. The timestamp specifies the time when the Echo the Echo Reply. The timestamp specifies the time when the Echo
Request message is sent. The first 4 bytes specify the number Request message is sent. The first 4 bytes specify the number
of 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 second bytes specify the number of microseconds since the second
specified in the first 4 bytes. specified in the first 4 bytes. This option would typically be
used by a client to compute round trip times.
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 Echo Request messages. It MUST be used in Echo subsequent Echo Request messages. It MUST be used in Echo
Request messages to tell the server what group address to Request messages to tell the server what group address to
respond to (this group would typically be previously obtained respond to (this group would typically be previously obtained
in a Server Response message). It MUST be used in Echo Reply in a Server Response message). It MUST be used in Echo Reply
messages (copied from the Echo Request message). It MUST NOT messages (copied from the Echo Request message). It MUST NOT
be used in Init messages. The format of the option value is as be used in Init messages. The format of the option value is as
below. below.
skipping to change at page 8, line 21 skipping to change at page 9, line 26
be used in Init messages. The format of the option value is as be used in Init messages. The format of the option value is as
below. 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 [4]. This is followed by the group Internet address families [addrfamily]. This is followed by
address. Length of the option value will be 6 for IPv4, and 18 the group address. Length of the option value will be 6 for
for IPv6. IPv4, and 18 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 Echo Request messages). A server client messages (Init and Echo Request messages). A server
MUST NOT send this option, except that if it is present in an MUST NOT send this option, except that if it is present in an
Echo Request message, the server MUST echo it in replies (Echo Echo Request message, the server MUST echo it in replies (Echo
Reply message) to the Echo Request. This option contains a Reply message) to the Echo Request. This option contains a
list of option types for options that the client is requesting list of option types for options that the client is requesting
from the server. Support for this option is optional for both from the server. Support for this option is optional for both
skipping to change at page 9, line 23 skipping to change at page 10, line 28
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. 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 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 an Echo Request message, it MUST be echoed in the received in an Echo Request message, it MUST be echoed in the
Echo Reply message). Echo Reply message).
skipping to change at page 10, line 7 skipping to change at page 11, line 17
Length MUST be 1. This option contains a single octet Length MUST be 1. This option contains a single octet
specifying the TTL of an Echo Reply message. Every time a specifying the TTL of an Echo Reply message. Every time a
server sends a unicast or multicast Echo Reply message, it server sends a unicast or multicast Echo Reply message, it
SHOULD include this option specifying the TTL. This is used by SHOULD include this option specifying the TTL. This is used by
clients to determine the number of hops the messages have clients to determine the number of hops the messages have
traversed. It MUST NOT be used in other messages. A server traversed. It MUST NOT be used in other messages. A server
SHOULD specify this option if it knows what the TTL of the Echo SHOULD specify this option if it knows what the TTL of the Echo
Reply will be. In general the server can specify a specific Reply will be. In general the server can specify a specific
TTL to the host stack. Note that the TTL is not necessarily TTL to the host stack. Note that the TTL is not necessarily
the same for unicast and multicast. Also note that this option the same for unicast and multicast. Also note that this option
SHOULD be included even when not requested by the client. 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 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) and 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 Echo 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 [4]. This is followed by a prefix Internet address families [addrfamily]. This is followed by a
length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special prefix length (4-32 for IPv4, 8-128 for IPv6, or 0 for the
"wildcard" use discussed below), and finally a group address. special "wildcard" use discussed below), and finally a group
For any family, prefix length 0 means that any multicast address. For any family, prefix length 0 means that any
address from that family is acceptable. This is what we call multicast address from that family is acceptable. This is what
"wildcard." The group address need only contain enough octets we call "wildcard." The group address need only contain enough
to cover the prefix length bits (i.e., the group address would octets to cover the prefix length bits (i.e., the group address
have to be 3 octets long if the prefix length is 17-24, and would have to be 3 octets long if the prefix length is 17-24,
there need be no group address for the wildcard with prefix and 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 messages. If a client receives this option in Server Response messages. If a client receives this option in
a message, the client MUST echo the Session ID option in a message, the client MUST echo the Session ID option in
subsequent Echo Request messages, with the exact same value. subsequent Echo Request messages, with the exact same value.
The Session ID may help the server in keeping track of clients The Session ID may help the server in keeping track of clients
and possibly manage per client state. The value of a new and possibly manage per client state. The value of a new
Session ID SHOULD be chosen pseudo randomly so that it is hard Session ID SHOULD be chosen pseudo randomly so that it is hard
to predict. The Session ID can be used to prevent spoofing of to predict. The Session ID can be used to prevent spoofing of
the source address of Echo Request messages. See the Security the source address of Echo Request messages. We say that this
Considerations for details. 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 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 Echo 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 Echo 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 second bytes specify the number of microseconds since the second
specified in the first 4 bytes. 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 3.3. Packet Format
The format of all messages is a one octet message type, followed by a The format of all messages is a one octet message type, 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 ... |
skipping to change at page 13, line 27 skipping to change at page 14, line 36
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 | SHOULD | ECHO | NOT | 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 only applies to the Session ID option. If 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 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 the exact same option value in the following Echo Requests. RQ means
that the server SHOULD include the option in the response, when that the server SHOULD include the option in the response, when
requested by the client using the Option Request option. requested by the client using the Option Request option.
3.5. Rate Limiting 3.5. Rate Limiting
Clients MUST by default send at most one Echo Request per second. Clients MUST by default send at most one Echo Request per second.
Servers MUST by default perform rate limiting, to guard against this Servers MUST by default perform rate limiting, to guard against this
protocol being used for DoS attacks. The server MUST by default for protocol being used for DoS attacks. The server MUST by default for
a given client, respond to on average at most one Echo Request a given client, respond to on average at most one Echo Request
message per second. Server implementations should provide message per second. Server implementations should provide
configuration options allowing certain clients to perform more rapid configuration options allowing certain clients to perform more rapid
Echo Requests. If higher rates are allowed for specific client IP Echo Requests. If higher rates are allowed for specific client IP
addresses, then Init messages and the Session ID option MUST be used addresses, then Init messages and the Session ID option MUST be used
to help prevent spoofing. to help prevent spoofing.
Implementers of applications/tools using this protocol SHOULD Implementers of applications/tools using this protocol SHOULD
consider the UDP guidelines [6], in particular if clients are to consider the UDP guidelines [RFC5405], in particular if clients are
send, or servers are to accept, Echo Requests at rates exceeding one to send, or servers are to accept, Echo Requests at rates exceeding
per second. See Section 9, "Security Considerations", for additional one per second. See Section 9, "Security Considerations", for
discussion. additional discussion.
4. Client Behaviour 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. protocol would behave.
A client only requires a user to specify the unicast address of the 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 server. It can then send an Init message with a prefix option
containing the desired address family and zero prefix length containing the desired address family and zero prefix length
(wildcard entry). The server can then decide which group, from the (wildcard entry). The server can then decide which group, from the
skipping to change at page 17, line 13 skipping to change at page 18, line 16
specification in Section 3.5. specification in Section 3.5.
7. Acknowledgments 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 [5]. Many people in communities like TERENA, the ssmping tools at [impl]. 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, Tony Ballardie, Bill Cerveny, Toerless Thanks to Kevin Almeroth, Tony Ballardie, Bill Cerveny, Toerless
Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui, Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui,
Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola,
Trond Skjesol and Cao Wei for reviewing and providing feedback on Trond Skjesol and Cao Wei for reviewing and providing feedback on
this draft. In particular Hugo, Gorry and Bharat have provided lots this draft. In particular Hugo, Gorry and Bharat have provided lots
of input on several revisions of the draft. of input on several revisions of the draft.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 19, line 26 skipping to change at page 20, line 26
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 Echo 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 Echo Request. source IP address of the Echo Request.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
Levels", BCP 14, RFC 2119, March 1997. August 1980.
[2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
September 1981. RFC 792, September 1981.
[3] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
August 1980. Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] "IANA, Address Family Numbers", [addrfamily]
<http://www.iana.org/assignments/address-family-numbers>. "IANA, Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>.
10.2. Informative References 10.2. Informative References
[5] "ssmping implementation", [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
<http://www.venaas.no/multicast/ssmping/>. for Application Designers", BCP 145, RFC 5405,
November 2008.
[6] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for [impl] "ssmping implementation",
Application Designers", BCP 145, RFC 5405, November 2008. <http://software.uninett.no/ssmping/>.
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
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 32 change blocks. 
100 lines changed or deleted 179 lines changed or added

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