draft-ietf-mboned-ssmping-03.txt   draft-ietf-mboned-ssmping-04.txt 
Network Working Group S. Venaas Network Working Group S. Venaas
Internet-Draft UNINETT Internet-Draft UNINETT
Intended status: Informational February 12, 2008 Intended status: Informational February 21, 2008
Expires: August 15, 2008 Expires: August 24, 2008
Multicast Ping Protocol Multicast Ping Protocol
draft-ietf-mboned-ssmping-03 draft-ietf-mboned-ssmping-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2008. This Internet-Draft will expire on August 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Multicast Ping Protocol specified in this document allows for The Multicast Ping Protocol specified in this document allows for
checking whether an endpoint can receive multicast, both Source- checking whether an endpoint can receive multicast, both Source-
Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also
skipping to change at page 2, line 18 skipping to change at page 2, line 18
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4
3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6
4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Message types and options . . . . . . . . . . . . . . . . . . 10 5. Message types and options . . . . . . . . . . . . . . . . . . 11
6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 10 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12
7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Recommendations for Implementers . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The Multicast Ping Protocol specified in this document allows for The Multicast Ping Protocol specified in this document allows for
checking multicast connectivity. In addition to checking reception checking multicast connectivity. In addition to checking reception
of multicast (SSM or ASM), the protocol can provide related of multicast (SSM or ASM), the protocol can provide related
information like multicast tree setup time, the number of hops the information like multicast tree setup time, the number of hops the
packets have traveled, as well as packet delay and loss. This packets have traveled, as well as packet delay and loss. This
functionality resembles, in part, the ICMP Echo Request/Reply functionality resembles, in part, the ICMP Echo Request/Reply
mechanism, but uses UDP (RFC 768 [2] and RFC 2460 [3]) and requires mechanism, but uses UDP (RFC 768 [2] and RFC 2460 [3]) and requires
both a client and a server implementing this protocol. 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.
The protocol here specified is based on the actual implementation of The protocol here specified is based on the actual implementation of
the ssmping and asmping tools [5] which are widely used by the the ssmping and asmping tools [5] which are widely used by the
Internet community to conduct multicast connectivity tests. Internet 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 typical protocol usage is as follows: A server runs continuously The typical protocol usage is as follows: A server runs continuously
skipping to change at page 3, line 41 skipping to change at page 3, line 43
group to use, or an error if no group is available. Next, for ASM, group to use, or an error if no group is available. Next, for ASM,
the client joins an ASM group G, while for SSM it joins a channel the client joins an ASM group G, while for SSM it joins a channel
(S,G). Here G is the group specified by the server, and S is the (S,G). Here G is the group specified by the server, and S is the
unicast address used to reach the server. unicast address used to reach the server.
After joining the channel, the client unicasts multicast ping After joining the channel, the client unicasts multicast ping
requests to the server. The requests are sent using UDP with requests to the server. The requests are sent using UDP with
destination port set to the standardised multicast ping port [TBD]. destination port set to the standardised multicast ping port [TBD].
The requests are sent periodically, e.g., once per second, to the The requests are sent periodically, e.g., once per second, to the
server. The requests contain a sequence number, and typically a server. The requests contain a sequence number, and typically a
timestamp. The requests are echoed back by the server, except the timestamp. The requests are echoed by the server, except the server
server may add a few options. For each request, the server sends two may add a few options. For each request, the server sends two
replies. One reply is unicast to the source IP address and source replies. One reply is unicast back to the source IP address and
UDP port of the request, while another is multicast back to requested source UDP port of the request, while another is multicast to the
multicast group G and the source UDP port of the request. Both the requested multicast group G and the source UDP port of the request.
replies are sent from the same port from which the request was Both replies are sent from the same port on which the request was
received. The server should specify the TTL used for both the received. The server should specify the TTL used for both the
unicast and multicast messages (we recommend at least 64) and unicast and multicast messages (we recommend at least 64) by
includes a TTL option for the client to compute the number of hops. including a TTL option; allowing the client to compute the number of
The client should leave the channel/group when it has finished its hops. The client should leave the channel/group when it has finished
measurements. its measurements.
By use of this protocol, a client can obtain information about By use of this protocol, a client can obtain information about
several multicast delivery characteristics. First, by receiving several multicast delivery characteristics. First, by receiving
unicast replies, it can verify that the server is receiving the unicast replies, it can verify that the server is receiving the
unicast requests, is operational and responding. Hence, provided unicast requests, is operational and responding. Hence, provided
that the client receives unicast replies, a failure to receive that the client receives unicast replies, a failure to receive
multicast indicates either a multicast problem or a multicast multicast indicates either a multicast problem or a multicast
administrative restriction. If it does receive multicast, it knows administrative restriction. If it does receive multicast, it knows
not only that it can receive; it may also estimate the amount of time not only that it can receive; it may also estimate the amount of time
it took to establish the multicast tree (at least if it is in the it took to establish the multicast tree (at least if it is in the
skipping to change at page 5, line 6 skipping to change at page 5, line 9
used. used.
The messages share a common format: one octet specifying the message The messages share a common format: one octet specifying the message
type, followed by a number of options in TLV (Type, Length and Value) type, followed by a number of options in TLV (Type, Length and Value)
format. This makes the protocol easily extendible. The Init message format. This makes the protocol easily extendible. The Init message
generally contains some prefix options asking the server for a group generally contains some prefix options asking the server for a group
from one of the specified prefixes. The server responds with a from one of the specified prefixes. The server responds with a
Server Response message that contains the group address to use, or Server Response message that contains the group address to use, or
possibly prefix options describing what multicast groups the server possibly prefix options describing what multicast groups the server
may be able to provide. For an Echo Request the client generally may be able to provide. For an Echo Request the client generally
includes a number of options, and a server may simply echo the includes a number of options, and a server MAY simply echo the
content back (only changing the message type), without inspecting the contents (only changing the message type) without inspecting the
options. However, the server SHOULD add a TTL option, and there are options if it does not support any options. This might be true for a
other options that a server implementation MAY support, e.g., the simple Multicast Ping Protocol server. However, the server SHOULD
client may ask for certain information or a specific behaviour from add a TTL option, and there are other options that a server
the server. The Echo Replies (one unicast and one multicast) MUST implementation MAY support, e.g., the client may ask for certain
first contain the exact options from the request (in the same order), information or a specific behaviour from the server. The Echo
and then, immediately following, any options appended by the server. Replies (one unicast and one multicast) MUST first contain the exact
A server MUST NOT process unknown options, but they MUST still be options from the request (in the same order), and then, immediately
included in the Echo Reply. A client MUST ignore any unknown following, any options appended by the server. A server MUST NOT
options. process unknown options, but they MUST still be included in the Echo
Reply. A client MUST ignore any unknown options.
This document defines a number of different options. Some options do This document defines a number of different options. Some options do
not require processing by servers and are simply returned unmodified not require processing by servers and are simply returned unmodified
in the reply. There are, however, other client options that the in the reply. There are, however, other client options that the
server may care about, and also server options that may be requested server may care about, and also server options that may be requested
by a client. Unless otherwise specified, an option MUST NOT be used by a client. Unless otherwise specified, an option MUST NOT be used
multiple times in the same message. multiple times in the same message.
3.1. Option format 3.1. Option format
skipping to change at page 6, line 7 skipping to change at page 6, line 8
Length (2 octets) specifies the length of the value field. Depending Length (2 octets) specifies the length of the value field. Depending
on the option type, it can be from 0 to 65535. on the option type, it can be from 0 to 65535.
Value. The value must always be of the specified length. See the Value. The value must always be of the specified length. See the
respective option definitions for possible values. If the length is respective option definitions for possible values. If the length is
0, the value field is not included. 0, the value field is not included.
3.2. Defined Options 3.2. Defined Options
Version, type 0. Length MUST be 1. This option MUST always be This document defines the following options: Version (0), Client ID
included in all messages, and the value MUST be set to 2 (in (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4),
decimal). Note that there are older implementations of ssmping that Option Request Option (5), Server Information (6), TTL (9), Multicast
only partly follow this specification. They can be regarded as Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and
version 1 and do not use this option. 8 are reserved. The options are defined below.
Client ID, type 1. Length MUST be non-zero. A client SHOULD always Version, type 0
include this option in all messages (both Init and Request). The
client may use any value it likes to be able to detect whether a
reply is a reply to its Init/Request or not. A server should treat
this as opaque data, and simply leave it unchanged in the reply (both
Server Response and Reply). The value might be a process ID, perhaps
process ID combined with an IP address because it may receive
multicast responses to queries from other clients. It is left to the
client implementor how to make use of this option.
Sequence number, type 2. Length MUST be 4. A client MUST always Length MUST be 1. This option MUST always be included in all
include this in Request messages and MUST NOT include it in Init messages, and the value MUST be set to 2 (in decimal). Note
messages. A server replying to a Request message MUST copy it into that there are older implementations of ssmping that only
the Reply (or Server Response message on error). This contains a 32 partly follow this specification. They can be regarded as
bit sequence number. The values would typically start at 1 and 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
Response message back with version set to 2. Client ID and
Sequence Number options should be echoed if present. It SHOULD
not include any other options. A client receiving a response
with a version other than 2, MUST (unless it supports the
particular version), stop sending requests to the server.
Client ID, type 1
Length MUST be non-zero. A client SHOULD always include this
option in all messages (both Init and Request). The client may
use any value it likes to be able to detect whether a reply is
a reply to its Init/Request or not. A server should treat this
as opaque data, and simply leave it unchanged in the reply
(both Server Response and Reply). The value might be a process
ID, perhaps process ID combined with an IP address because it
may receive multicast responses to queries from other clients.
It is left to the client implementer how to make use of this
option.
Sequence Number, type 2
Length MUST be 4. A client MUST always include this in Request
messages and MUST NOT include it in Init messages. A server
replying to a Request message MUST copy it into the Reply (or
Server Response message on error). This contains a 32 bit
sequence number. The values would typically start at 1 and
increase by one for each request in a sequence. increase by one for each request in a sequence.
Client Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD Client Timestamp, type 3
include this in Request messages and MUST NOT include it in Init
messages. A server replying to a Request message MUST copy it into
the Reply. The timestamp specifies the time when the Request message
is sent. The first 4 bytes specify the number of seconds since the
Epoch (beginning of the year 1970). The next 4 bytes specify the
number of microseconds since the last second since the Epoch.
Multicast group, type 4. Length MUST be greater than 1. It MAY be Length MUST be 8 bytes. A client SHOULD include this in
used in Server Response messages to tell the client what group to use Request messages and MUST NOT include it in Init messages. A
in subsequent Request messages. It MUST be used in Request messages server replying to a Request message MUST copy it into the
to tell the server what group address to respond to (this group would Reply. The timestamp specifies the time when the Request
typically be previously obtained in a Server Response message). It message is sent. The first 4 bytes specify the number of
MUST be used in Reply messages (copied from the Request message). It seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4
MUST NOT be used in Init messages. The format of the option value is bytes specify the number of microseconds since the last second
as below. since the Epoch.
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 Request messages. It MUST be used in 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 Reply messages (copied
from the 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
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 [4]. This is followed by the group
address. Length of the option value will be 6 for IPv4, and 18 for address. Length of the option value will be 6 for IPv4, and 18
IPv6. for IPv6.
Option Request Option, type 5. Length MUST be greater than 1. This Option Request Option, type 5
option MAY be used in client messages (Init and Request messages). A
server MUST NOT send this option, except that if it is present in a Length MUST be greater than 1. This option MAY be used in
Request message, the server MUST include it in a reply (Reply client messages (Init and Request messages). A server MUST NOT
message) to the Request. This option contains a list of option types send this option, except that if it is present in a Request
for options that the client is requesting from the server. Support message, the server MUST echo it in replies (Reply message) to
for this option is optional for both clients and servers. The length the Request. This option contains a list of option types for
of this option will be a non-zero even number, since it contains one options that the client is requesting from the server. Support
or more option types that are two octets each. The format of the for this option is optional for both clients and servers. The
option value is as below. 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Type | | Option Type | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... | | ..... |
This option might be used by the client to ask the server to include This option might be used by the client to ask the server to
options like Timestamp or Server Information. A client MAY request include options like Timestamp or Server Information. A client
Server Information in Init messages; it MUST NOT request it in other MAY request Server Information in Init messages; it MUST NOT
messages. A client MAY request a Timestamp in Request messages; it request it in other messages. A client MAY request a Timestamp
MUST NOT request it in other messages. in 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 (Reply messages) to the 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 Server Information, type 6
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.
Type 7, Reserved. This option code value was used by early Length MUST be non-zero. It MAY be used in Server Response
implementations for an option that is now deprecated. This option messages and MUST NOT be used in other messages. Support for
should no longer be used. Clients MUST not use this option. Servers this option is optional. A server supporting this option
MUST treat it as an unknown option (not process it if received, but SHOULD add it in Server Response messages if and only if
if received in a Request message, it MUST be echoed back in the Reply 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.
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 a Request message, it MUST be echoed in the Reply
message). message).
Type 8, Reserved. This option code value was used by early Reserved, type 8
implementations for an option that is now deprecated. This option
should no longer be used. Clients MUST not use this option. Servers This option code value was used by early implementations for an
MUST treat it as an unknown option (not process it if received, but option that is now deprecated. This option should no longer be
if received in a Request message, it MUST be echoed back in the Reply used. Clients MUST NOT use this option. Servers MUST treat it
as an unknown option (not process it if received, but if
received in a Request message, it MUST be echoed in the Reply
message). message).
TTL, type 9. Length MUST be 1. This option contains a single octet TTL, type 9
specifying the TTL of a Reply message. Every time a server sends a
unicast or multicast 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 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.
Multicast prefix, type 10. Length MUST be greater than 2. It MAY be Length MUST be 1. This option contains a single octet
used in Init messages to request a group within the prefix(es), it specifying the TTL of a Reply message. Every time a server
MAY be used in Server Response messages to tell the client what sends a unicast or multicast Reply message, it SHOULD include
prefix(es) it may try to obtain a group from. It MUST NOT be used in 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 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.
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), 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
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 length Internet Address Families [4]. This is followed by a prefix
(0-32 for IPv4, 0-128 for IPv6), and finally a group address. The length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special
group address need only contain enough octets to cover the prefix 'wildcard' use discussed below), and finally a group address.
length bits (e.g., there need be no group address if the prefix For any family, prefix length 0 means that any multicast
length is 0, the group address would have to be 3 octets long if the address from that family is acceptable. This is what we call
prefix length is 17-24). Any bits past the prefix length MUST be 'wildcard'. The group address need only contain enough octets
ignored. For IPv4 the option value length will be 3-7, while for to cover the prefix length bits (i.e., the group address would
IPv6 3-19. 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. Length MUST be non-zero. A server MAY include Session ID, type 11
this in Server Response and Reply messages. If a client receives
this option in a message, the client MUST echo the Session ID option
in subsequent Reply messages, with the exact same value, until the
next message is received from the server. If the next message from
the server has no Session ID or a new Session ID value, the client
should do the same, either not use the Session ID, or use the new
value. The Session ID may help the server in keeping track of
clients and possibly manage client state. It is left to the server
implementer to decide whether it is useful and how to make use of it.
Server Timestamp, type 12. Length MUST be 8 bytes. A server Length MUST be non-zero. A server MAY include this in Server
supporting this option, SHOULD include it in Reply messages, if Response and Reply messages. If a client receives this option
requested by the client. The timestamp specifies the time when the in a message, the client MUST echo the Session ID option in
Reply message is sent. The first 4 bytes specify the number of subsequent Request messages, with the exact same value, until
seconds since the Epoch (beginning of the year 1970). The next 4 the next message is received from the server. If the next
bytes specify the number of microseconds since the last second since message from the server has no Session ID or a new Session ID
the Epoch. value, the client should do the same, either not use the
Session ID, or use the new value. The Session ID may help the
server in keeping track of clients and possibly manage per
client state. It is left to the server implementer to decide
whether it is useful and how to make use of it.
Server Timestamp, type 12
Length MUST be 8 bytes. A server supporting this option,
SHOULD include it in Reply messages, if requested by the
client. The timestamp specifies the time when the 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 last second
since the Epoch.
4. Packet Format 4. Packet Format
The format of all messages is a one octet message type, directly The format of all messages is a one octet message type, directly
followed by a variable number of options. followed by a 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 | Option | | Type | Options ... |
+-+-+-+-+-+-+-+-+ . | +-+-+-+-+-+-+-+-+ . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .....
| Option |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are four message types defined. Type 81 (the character Q in There are four message types defined. Type 81 (the character Q in
ASCII) specifies an Echo Request (Query). Type 65 (the character A ASCII) specifies an Echo Request (Query). Type 65 (the character A
in ASCII) specifies an Echo Response (Answer). Type 73 (the in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I
character I in ASCII) is an Init message, and type 83 (the character in ASCII) is an Init message, and type 83 (the character S in ASCII)
S in ACII) is a Server Response message. is a Server Response message.
The options directly follow the type octet and are not aligned in any The options directly follow the type octet and are not aligned in any
way (no spacing or padding), i.e., options might start at any octet way (no spacing or padding), i.e., options might start at any octet
boundary. The option format is specified above. boundary. The option format is specified above.
5. Message types and options 5. Message types and options
For the readers convenience we provide the matrix below, showing what There are four message types defined. We will now describe each of
options can go in what messages. 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 a 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 a Request, the message tells the client to stop
sending 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 replies. It MUST include Version,
Sequence Number and Multicast Group options. If the last
message (if any) received from the server contained a Session
ID, then this MUST also 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
the same. The server echoes most of the options from the Echo
Request (any options in the Request that are unsupported by the
server, are always echoed). The only option that may be
present in the Request which is not always echoed, is the
Session ID option. In most cases the server would echo it, but
the server may also change or omit it. The two Reply messages
SHOULD both contain a TTL option (not necessarily equal), and
both SHOULD also contain Server Timestamps (not necessarily
equal) when requested.
For the reader's convenience we provide the matrix below, showing
what options can go in what messages.
Option / Message Type | Init | Server Response | Request | Reply | Option / Message Type | Init | Server Response | Request | Reply |
-----------------------------------------------------------------+ -----------------------------------------------------------------+
Version (0) | MUST | ECHO | MUST | ECHO | Version (0) | MUST | ECHO | MUST | ECHO |
Client ID (1) |SHOULD| ECHO | SHOULD | ECHO | Client ID (1) |SHOULD| ECHO | SHOULD | ECHO |
Sequence number (2) | NOT | ECHO | MUST | ECHO | Sequence Number (2) | NOT | ECHO | MUST | ECHO |
Client Timestamp (3) | NOT | NOT | SHOULD | ECHO | Client Timestamp (3) | NOT | NOT | SHOULD | ECHO |
Multicast group (4) | NOT | MAY | MUST | ECHO | Multicast Group (4) | NOT | MAY | MUST | ECHO |
Option Request (5) | MAY | NOT | MAY | ECHO | Option Request (5) | MAY | NOT | MAY | ECHO |
Server Information (6)| NOT | RQ | NOT | NOT | Server Information (6)| NOT | RQ | NOT | NOT |
Reserved (7) | NOT | NOT | NOT | ECHO | Reserved (7) | NOT | NOT | NOT | ECHO |
Reserved (8) | NOT | NOT | NOT | ECHO | Reserved (8) | NOT | NOT | NOT | ECHO |
TTL (9) | NOT | NOT | NOT |SHOULD | TTL (9) | NOT | NOT | NOT |SHOULD |
Multicast prefix (10) | MAY | MAY | NOT | NOT | Multicast Prefix (10) | MAY | MAY | NOT | NOT |
Session ID (11) | NOT | MAY | ECHO | MAY | Session ID (11) | NOT | MAY | ECHO | MAY |
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 back in the response, with the exact same option MUST echo the option in the response, with the exact same option
value. ECHO for a client means that it MUST echo the option it got value. ECHO for a client means that it MUST echo the option it got
in the last message from the server in any subsequent messages it in the last message from the server in any subsequent messages it
sends. RQ means that the server SHOULD include the option in the sends. RQ means that the server SHOULD include the option in the
response, when requested by the client using the Option Request response, when requested by the client using the Option Request
option. option.
6. Client Behaviour 6. Client Behaviour
We will consider how a typical interactive client using the above We will consider how a typical interactive client using the above
protocol would behave. A client need only require a user to specify protocol would behave. A client need only require a user to specify
the unicast address of the server. It can then send an Init message the unicast address of the server. It can then send an Init message
with a prefix option containing the desired address family and zero with a prefix option containing the desired address family and zero
prefix length. The server is then free to decide which group it prefix length (wildcard entry). The server is then free to decide
should return. A client may also allow a user to specify a group which group, from the specified family, it should return. A client
address(es) or prefix(es) (for IPv6, the user may only be required to may also allow a user to specify group address(es) or prefix(es) (for
specify a scope or an RP address, from which the client can construct IPv6, the user may only be required to specify a scope or an RP
the desired prefix, possibly embedded-RP). From this the client can address, from which the client can construct the desired prefix,
specify one or more prefix options in an Init message to tell the possibly embedded-RP). From this the client can specify one or more
server which address it would prefer. If the user specifies a group prefix options in an Init message to tell the server which address it
address, that can be encoded as a prefix of maximal length (e.g. 32 would prefer. If the user specifies a group address, that can be
for IPv4). The prefix options are in prioritised order, i.e., the encoded as a prefix of maximal length (e.g. 32 for IPv4). The prefix
client should put the most preferred prefix first. options are in prioritised order, i.e., the client should put the
most preferred prefix first.
If the client receives a Server Response message containing a group If the client receives a Server Response message containing a group
address it can start sending Request messages, see the next address it can start sending Request messages, see the next
paragraph. If there is no group address option, it would typically paragraph. If there is no group address option, it would typically
exit with an error message. The server may have included some prefix exit with an error message. The server may have included some prefix
options in the Server Response. The client may use this to provide options in the Server Response. The client may use this to provide
the user some feedback on what prefixes or scopes are available. the user some feedback on what prefixes or scopes are available.
Assuming the client got a group address in a Server Response it can Assuming the client got a group address in a Server Response, it can
start pinging. Before it does that it should let the user know which start pinging. Before it does that, it should let the user know
group is being used. Normally, a client should send at most one ping which group is being used. Normally, a client should send at most
request per second. When sending ping Requests the client must one ping request per second. When sending ping Requests, the client
always specifiy the group option. If the last message from the must always include the group option. If the last message from the
server contained a Session ID, then it must also include that with server contained a Session ID, then it must also include that with
the same value. Typically it would receive a Session ID in a Server the same value. Typically it would receive a Session ID in a Server
Response together with the group address, and then the ID would stay Response together with the group address, and then the ID would stay
the same during the entire ping sequence. However, if for instance the same during the entire ping sequence. However, if for instance
the server process is restarted, it may still be possible to continue the server process is restarted, it may still be possible to continue
pinging but the Session ID may be changed by the server. Hence a pinging but the Session ID may be changed by the server. Hence a
client implementation must always use the last Session ID it client implementation must always use the last Session ID it
received, and not necessarily the one from the Server Response received, and not necessarily the one from the Server Response
message. If a client receives a Server Response message in response message. If a client receives a Server Response message in response
to a Request message (that is, a Server Response message containing a to a Request message (that is, a Server Response message containing a
sequence number), this means there is an error and it should stop sequence number), this means there is an error and it should stop
sending Requests. This may for instance happen after server restart. sending Requests. This may for instance happen after server restart.
The client may have an option for the user to obtain server The client may allow the user to request server information. If the
information. If the user asks for server information, the client can user requests server information, the client can send an Init message
send an Init message with no prefix options, but with an Option with no prefix options, but with an Option Request Option, requesting
Request Option, requesting the server to return a Server Information the server to return a Server Information option. The server will
option. The server will return server information if supported, and return server information if supported, and it may also return a list
it may also return a list of prefixes it supports. It will however of prefixes it supports. It will however not return a group address.
not return a group address. The client may also try to obtain only a The client may also try to obtain only a list of prefixes by sending
list of prefixes by sending an Init message with no prefixes and not an Init message with no prefixes and not requesting any specific
requesting any specific options. options.
Note that a client may pick a multicast group and send Request Note that a client may pick a multicast group and send Request
messages without first going through the Init - Server Response messages without first going through the Init - Server Response
negotiation. If this is supported by the server and the server is negotiation. If this is supported by the server and the server is
okay with the group used, the server can then send Reply messages as okay with the group used, the server can then send Reply messages as
usual. If the server is not okay, it will send a Server Response usual. If the server is not okay, it will send a Server Response
telling the client to stop and possibly pick a new group. telling the client to stop.
7. Server Behaviour 7. Server Behaviour
We will consider how a typical server using the above protocol would We will consider how a typical server using the above protocol would
behave. First we consider how to respond to Init messages. If the behave. First we consider how to respond to Init messages. If the
Init message contains prefix options, the server should look at them Init message contains prefix options, the server should look at them
in order and see if it can assign a multicast address in the given in order and see if it can assign a multicast address from the given
range. The server would be configured, possibly have a default, prefix. The server would be configured, possibly have a default,
specifying which groups it can offer. It may have a large pool just specifying which groups it can offer. It may have a large pool just
picking a group at random, possibly choose a group based on hashing picking a group at random, possibly choose a group based on hashing
of the clients IP address or identifier, or just use a fixed group. of the clients IP address or identifier, or just use a fixed group.
It is left to the server to decide whether it should allow the same 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 address to be used simultaneously by multiple clients. If the server
finds a suitable group address, it returns this in a group option in finds a suitable group address, it returns this in a group option in
a Server Response message. The server may additionally include a a Server Response message. The server may additionally include a
Session ID. This may help the server if it is to keep some state, Session ID. This may help the server if it is to keep some state,
for instance for making sure the client uses the group it got for instance for making sure the client uses the group it got
assigned. A good Session ID would be a random byte string that is assigned. A good Session ID would be a random byte string that is
hard to predict. If the server cannot find a suitable group address, 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 or if there were no prefixes in the Init message, it may send a
Server Response message containing prefix options listing what Server Response message containing prefix options listing what
prefixes may be available to the client. Finally, if the Init prefixes may be available to the client. Finally, if the Init
message requests the Server Information option, it should include message requests the Server Information option, it should include
that. that.
When the server receives a Request message, it may first check that When the server receives a Request message, it may first check that
the group address and Session ID (if provided) are valid. If the the group address and Session ID (if provided) are valid. If the
server is satisfied it will send a unicast Reply message back to the server is satisfied, it will send a unicast Reply message back to the
client, and also a multicast Reply message to the group address. The client, and also a multicast Reply message to the group address. The
Reply messages contain the exact options and in the same order, as in Reply messages contain the exact options and in the same order, as in
the Request, and after that the server adds a TTL option and the Request, and after that the server adds a TTL option and
additional options if needed. E.g., it may add a timestamp if additional options if needed. E.g., it may add a timestamp if
requested by the client. If the server is not happy with the Request requested by the client. If the server is not happy with the Request
(bad group address or Session ID, request is too large etc), it may (bad group address or Session ID, request is too large etc), it may
send a Server Response message asking the client to stop. This send a Server Response message asking the client to stop. This
Server Response must echo the sequence number from the Request. This Server Response must echo the sequence number from the Request. This
Server Response may contain which prefixes the client can try to Server Response may contain group prefixes from which a client can
request addresses from. The unicast and multicast Reply messages try to request a group address. The unicast and multicast Reply
have identical UDP payload apart from possibly TTL and timestamp messages have identical UDP payload apart from possibly TTL and
option values. timestamp option values.
Note that the server may receive Request messages with no prior Init Note that the server may receive Request messages with no prior Init
message. This may happen when the server restarts or if a client message. This may happen when the server restarts or if a client
sends a Request with no prior Init message. The server may go ahead sends a Request with no prior Init message. The server may go ahead
and respond if it is okay with the group used. In the responses it and respond if it is okay with the group used. In the responses it
may add a Session ID which will then be in later requests from the may add a Session ID which will then be in later requests from the
client. If the group is not okay, the server sends back a Server client. If the group is not okay, the server sends back a Server
Response. The Response is just as if it got an Init message with no Response. The Response is just as if it got an Init message with no
prefixes. If the server adds or modifies the SessionID in replies, prefixes. If the server adds or modifies the SessionID in replies,
it must use the exact same SessionID in the unicast and multicast it must use the exact same SessionID in the unicast and multicast
replies. replies.
By default a server should perform rate limiting and for a given By default, a server should perform rate limiting and for a given
client, respond to at most one Request message per second. A leaky client, respond to at most one Request message per second. A leaky
bucket algorithm is suggested, where the rate can be higher for a few 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 seconds, but the average rate should by default be limited to a
message per client per second. message per client per second.
8. Acknowledgements 8. 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. One such policy
could be to use the client IP address if it can be trusted.
Servers must perform rate limiting, to guard against this protocol
being used for DoS attacks. By default, clients should send at most
one request per second, and servers should perform rate limiting if a
client sends more frequent requests. Server implementations should
provide administrative control of which client IP addresses to serve,
and may also allow certain clients to perform more rapid requests.
Implementers of applications/tools using this protocol should
consider the UDP guidelines [6], in particular if clients are to
send, or servers are to accept, requests at rates exceeding one per
second.
9. Acknowledgements
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 [5]. Many people in communities like TERENA,
Internet2 and the M6Bone have used early implementations of ssmping Internet2 and the M6Bone have used early implementations of ssmping
and provided feedback that have influenced the current protocol. and provided feedback that have influenced the current protocol.
Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui, Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Alfred
Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil
Trond Skjesol and Cao Wei for reviewing and providing feedback on Sarac, Pekka Savola, Trond Skjesol and Cao Wei for reviewing and
this draft. In particular Hugo, Gorry and Bharat have provided lots providing feedback on this draft. In particular Hugo, Gorry and
of input on several revisions of the draft Bharat have provided lots of input on several revisions of the draft
9. IANA Considerations 10. IANA Considerations
IANA is requested to provide a UDP port number for use by this IANA is requested to provide a UDP port number for use by this
protocol, and also to provide registries for message and option protocol, and also to provide registries for message and option
types. types.
There should be a message types registry. Message types are in the There should be a message types registry. Message types are in the
range 0-255. Message types 0-191 can be assigned referencing an RFC range 0-255. Message types 0-191 can be assigned referencing an RFC
(it may be Informational), while types 192-255 are freely available (it may be Informational), while types 192-255 are freely available
for experimental, private or vendor specifc use. for experimental, private or vendor specifc use. The registry should
include the messages defined in Section 5
There should also be an option type registry. Option types 0-49151 There should also be an option type registry. Option types 0-49151
can be assigned referencing an RFC (it may be Informational), while can be assigned referencing an RFC (it may be Informational), while
types 49152-65535 are freely available for experimental, private or types 49152-65535 are freely available for experimental, private or
vendor specifc use. vendor specifc use. The registry should include the options defined
in Section 3.2.
10. Security Considerations 11. Security Considerations
There are some security issues to consider. One is that a host may There are some security issues to consider. One is that a host may
send a request with an IP source address of another host, and make an send a request with an IP source address of another host, and make an
arbitrary multicast ping server on the Internet send packets to this arbitrary multicast ping server on the Internet send packets to this
other host. This behaviour is fairly harmless. The worst case is if other host. This behaviour is fairly harmless. The worst case is if
the host receiving the unicast replies also happen to be joined to the host receiving the unicast replies also happen to be joined to
the multicast group used. In this case, there would be an the multicast group used. In this case, there would be an
amplification effect where the host receives twice as many replies as amplification effect where the host receives twice as many replies as
there are requests sent. there are requests sent.
Servers should perform rate limiting, to guard against this function Server implementations should allow administrators to restrict which
being used as a DoS attack. By default, clients should send at most groups a server responds to, and also perform rate limiting. This is
one request per second, and servers should perform rate limiting if a discussed in Section 8).
client sends more frequent requests. Server implementations should
provide administrative control of which client IP addresses to serve,
and may also allow certain clients to perform more rapid requests.
Implementors of applications/tools using this protocol should
consider the UDP guidelines [6], in particular if clients are to
send, or servers are to accept, requests at rates exceeding one per
second.
A client should use the client ID option to distinguish replies to
its own requests from replies that might be to other requests.
11. References 12. References
11.1. Normative References 12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[4] "IANA, Address Family Numbers", [4] "IANA, Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
11.2. Informative References 12.2. Informative References
[5] "ssmping implementation", [5] "ssmping implementation",
<http://www.venaas.no/multicast/ssmping/>. <http://www.venaas.no/multicast/ssmping/>.
[6] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for [6] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for
Application Designers", draft-ietf-tsvwg-udp-guidelines-05 (work Application Designers", draft-ietf-tsvwg-udp-guidelines-05 (work
in progress), February 2008. in progress), February 2008.
Author's Address Author's Address
 End of changes. 51 change blocks. 
230 lines changed or deleted 353 lines changed or added

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