draft-ietf-mboned-ssmping-05.txt   draft-ietf-mboned-ssmping-06.txt 
Network Working Group S. Venaas Network Working Group S. Venaas
Internet-Draft UNINETT Internet-Draft UNINETT
Intended status: Informational September 18, 2008 Intended status: Standards Track November 3, 2008
Expires: March 22, 2009 Expires: May 7, 2009
Multicast Ping Protocol Multicast Ping Protocol
draft-ietf-mboned-ssmping-05 draft-ietf-mboned-ssmping-06
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 March 22, 2009. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
The Multicast Ping Protocol specified in this document allows for The Multicast Ping Protocol specified in this document allows for
checking whether an endpoint can receive multicast, both Source- checking whether an endpoint can receive multicast, both Source-
Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also
be used to obtain additional multicast related information like be used to obtain additional multicast related information like
multicast tree setup time etc. This protocol is based on an multicast tree setup time etc. This protocol is based on an
implementation of tools called ssmping and asmping. implementation of tools called ssmping and asmping.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Message types and options . . . . . . . . . . . . . . . . . . 11 5. Message types and options . . . . . . . . . . . . . . . . . . 11
6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 13
7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14
8. Recommendations for Implementers . . . . . . . . . . . . . . . 15 8. Recommendations for Implementers . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20
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 requires both a client and a
both a client and a server implementing this protocol. Intermediate server implementing this protocol. Intermediate routers are not
routers are not required to support this protocol. They forward required to support this protocol. They forward Protocol Messages
Protocol Messages and data traffic as usual. 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 [4] 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
to serve requests from clients. A client can test the multicast to serve requests from clients. A client can test the multicast
reception from this server, provided it knows a unicast address of reception from this server, provided it knows a unicast address of
the server. It will then send a unicast message to the server asking the server. It will then send a unicast message to the server asking
skipping to change at page 4, line 27 skipping to change at page 4, line 27
variation of Round Trip Times (RTT). For unicast, the RTT is the variation of Round Trip Times (RTT). For unicast, the RTT is the
time from when the unicast request is sent to when the reply is time from when the unicast request is sent to when the reply is
received. The measured multicast RTT also references the client's received. The measured multicast RTT also references the client's
unicast request. By use of the TTL option specifying the TTL of the unicast request. By use of the TTL option specifying the TTL of the
replies when they are originated, the client can also determine the replies when they are originated, the client can also determine the
number of router hops it is from the source. Since similar number of router hops it is from the source. Since similar
information is obtained in the unicast replies, the host may compare information is obtained in the unicast replies, the host may compare
its multicast and unicast results and is able to check for its multicast and unicast results and is able to check for
differences in the number of hops, RTT, etc. The number of multicast differences in the number of hops, RTT, etc. The number of multicast
hops and changes in the number of hops over time, may also reveal hops and changes in the number of hops over time, may also reveal
details about the multicast tree and multicast tree changes. E.g., details about the multicast tree and multicast tree changes.
with PIM-SM one may be able to tell whether the forwarding is on a
shared or source-specific tree and when an eventual switch occurs.
Provided that the server sends the unicast and multicast replies Provided that the server sends the unicast and multicast replies
nearly simultaneously, the client may also be able to measure the nearly simultaneously, the client may also be able to measure the
difference in one way delay for unicast and multicast on the path difference in one way delay for unicast and multicast on the path
from server to client, and also differences in delay. Servers may from server to client, and also differences in delay. Servers may
optionally specify a timestamp. This may be useful since the unicast optionally specify a timestamp. This may be useful since the unicast
and multicast replies can not be sent simultaneously (the delay and multicast replies can not be sent simultaneously (the delay
depending on the host's operating system and load). depending on the host's operating system and load).
3. Protocol specification 3. Protocol specification
skipping to change at page 5, line 22 skipping to change at page 5, line 20
simple Multicast Ping Protocol server. However, the server SHOULD simple Multicast Ping Protocol server. However, the server SHOULD
add a TTL option, and there are other options that a server add a TTL option, and there are other options that a server
implementation MAY support, e.g., the client may ask for certain implementation MAY support, e.g., the client may ask for certain
information or a specific behaviour from the server. The Echo information or a specific behaviour from the server. The Echo
Replies (one unicast and one multicast) MUST first contain the exact Replies (one unicast and one multicast) MUST first contain the exact
options from the request (in the same order), and then, immediately options from the request (in the same order), and then, immediately
following, any options appended by the server. A server MUST NOT following, any options appended by the server. A server MUST NOT
process unknown options, but they MUST still be included in the Echo process unknown options, but they MUST still be included in the Echo
Reply. A client MUST ignore any unknown options. Reply. A client MUST ignore any unknown options.
The size of the protocol messages is generally smaller than the Path
MTU and fragmentation is not a concern. There may however be cases
where the Path MTU is really small, or that a client sends large
requests in order to verify that it can receive fragmented multicast
datagrams. This document does not specify whether Path MTU Discovery
should be performed, etc. A possible extension could be an option
where a client requests Path MTU Discovery and receives the current
Path MTU from the server.
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
All options are TLVs formatted as specified below. All options are TLVs formatted as specified below.
skipping to change at page 6, line 18 skipping to change at page 6, line 25
This document defines the following options: Version (0), Client ID This document defines the following options: Version (0), Client ID
(1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4),
Option Request Option (5), Server Information (6), TTL (9), Multicast Option Request Option (5), Server Information (6), TTL (9), Multicast
Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and
8 are reserved. The options are defined below. 8 are reserved. The options are defined below.
Version, type 0 Version, type 0
Length MUST be 1. This option MUST always be included in all Length MUST be 1. This option MUST always be included in all
messages, and the value MUST be set to 2 (in decimal). Note messages, and the value MUST be set to 2 (in decimal). Note
that there are older implementations of ssmping that only that there are implementations of older revisions of this
partly follow this specification. They can be regarded as protocol that only partly follow this specification. They can
version 1 and do not use this option. If a server receives a be regarded as version 1 and do not use this option. If a
message with a version other than 2 (or missing), the server server receives a message with a version other than 2 (or
SHOULD (unless it supports the particular version) send a missing), the server SHOULD (unless it supports the particular
Response message back with version set to 2. Client ID and version) send a Response message back with version set to 2.
Sequence Number options SHOULD be echoed if present. It SHOULD Client ID and Sequence Number options SHOULD be echoed if
not include any other options. A client receiving a response present. It SHOULD not include any other options. A client
with a version other than 2, MUST (unless it supports the receiving a response with a version other than 2, MUST (unless
particular version), stop sending requests to the server. it supports the particular version), stop sending requests to
the server.
Client ID, type 1 Client ID, type 1
Length MUST be non-zero. A client SHOULD always include this Length MUST be non-zero. A client SHOULD always include this
option in all messages (both Init and Request). The client may option in all messages (both Init and Request). The client may
use any value it likes to be able to detect whether a reply is 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 a reply to its Init/Request or not. A server should treat this
as opaque data, and MUST echo this option back in the reply if as opaque data, and MUST echo this option back in the reply if
present (both Server Response and Reply). The value might be a present (both Server Response and Reply). The value might be a
process ID, perhaps process ID combined with an IP address process ID, perhaps process ID combined with an IP address
skipping to change at page 7, line 34 skipping to change at page 7, line 43
from the Request message). It MUST NOT be used in Init from the Request message). It MUST NOT be used in Init
messages. The format of the option value is as below. 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 [3]. This is followed by the group
address. Length of the option value will be 6 for IPv4, and 18 address. Length of the option value will be 6 for IPv4, and 18
for IPv6. for IPv6.
Option Request Option, type 5 Option Request Option, type 5
Length MUST be greater than 1. This option MAY be used in Length MUST be greater than 1. This option MAY be used in
client messages (Init and Request messages). A server MUST NOT client messages (Init and Request messages). A server MUST NOT
send this option, except that if it is present in a Request send this option, except that if it is present in a Request
message, the server MUST echo it in replies (Reply message) to message, the server MUST echo it in replies (Reply message) to
the Request. This option contains a list of option types for the Request. This option contains a list of option types for
skipping to change at page 9, line 37 skipping to change at page 9, line 44
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 [3]. This is followed by a prefix
length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special
'wildcard' use discussed below), and finally a group address. 'wildcard' use discussed below), and finally a group address.
For any family, prefix length 0 means that any multicast For any family, prefix length 0 means that any multicast
address from that family is acceptable. This is what we call address from that family is acceptable. This is what we call
'wildcard'. The group address need only contain enough octets 'wildcard'. The group address need only contain enough octets
to cover the prefix length bits (i.e., the group address would to cover the prefix length bits (i.e., the group address would
have to be 3 octets long if the prefix length is 17-24, and have to be 3 octets long if the prefix length is 17-24, and
there need be no group address for the wildcard with prefix there need be no group address for the wildcard with prefix
length 0). Any bits past the prefix length MUST be ignored. length 0). Any bits past the prefix length MUST be ignored.
For IPv4, the option value length will be 4-7, while for IPv6, For IPv4, the option value length will be 4-7, while for IPv6,
skipping to change at page 15, line 16 skipping to change at page 15, line 21
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
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
seconds, but the average rate should by default be limited to a
message per client per second.
8. Recommendations for Implementers 8. Recommendations for Implementers
The protocol as specified is fairly flexible and leaves a lot of The protocol as specified is fairly flexible and leaves a lot of
freedom for implementers. In this section we present some freedom for implementers. In this section we present some
recommendations. recommendations.
Server administrators should be able to configure one or multiple Server administrators should be able to configure one or multiple
group prefixes in a server implementation. When deploying servers on group prefixes in a server implementation. When deploying servers on
the Internet and in other environments, the server administrator the Internet and in other environments, the server administrator
should be able to restrict the server to respond to only a few should be able to restrict the server to respond to only a few
multicast groups which should not be currently used by multicast multicast groups which should not be currently used by multicast
applications. A server implementation should also provide applications. A server implementation should also provide
flexibility for an administrator to apply various policies to provide flexibility for an administrator to apply various policies to provide
one or multiple group prefixes to specific clients, e.g., site scoped one or multiple group prefixes to specific clients, e.g., site scoped
addresses for clients that are inside the site. Clients could be addresses for clients that are inside the site. Clients could be
identified by their IP address provided that clients are required to identified by their IP address provided that clients are required to
send Init messages, and they receive an unpredictable Session ID. send Init messages, and they receive an unpredictable Session ID.
See also Section 11.
Servers must perform rate limiting, to guard against this protocol Clients should by default send at most one request per second.
being used for DoS attacks. By default, clients should send at most Servers should perform rate limiting, to guard against this protocol
one request per second, and servers should perform rate limiting if a being used for DoS attacks. The server should for a given client,
client sends more frequent requests. Server implementations should respond to at most one Request message per second. A leaky bucket
provide administrative control of which client IP addresses to serve, algorithm is suggested, where the rate can be higher for a few
and may also allow certain clients to perform more rapid requests. seconds, but the average rate should by default be limited to a
message per client per second. Server implementations should provide
administrative control of which client IP addresses to serve, and may
also allow certain clients to perform more rapid requests.
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 [5], in particular if clients are to
send, or servers are to accept, requests at rates exceeding one per send, or servers are to accept, requests at rates exceeding one per
second. second. If higher rates are allowed for specific IP addresses, then
Init messages and the Session ID option should be used to help
prevent spoofing. See Section 11.
9. Acknowledgements 9. 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 [4]. Many people in communities like TERENA,
Internet2 and the M6Bone have used early implementations of ssmping Internet2 and the M6Bone have used early implementations of ssmping
and provided feedback that have influenced the current protocol. and provided feedback that have influenced the current protocol.
Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Alfred Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Alfred
Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil
Sarac, Pekka Savola, Trond Skjesol and Cao Wei for reviewing and Sarac, Pekka Savola, Trond Skjesol and Cao Wei for reviewing and
providing feedback on this draft. In particular Hugo, Gorry and providing feedback on this draft. In particular Hugo, Gorry and
Bharat have provided lots of input on several revisions of the draft Bharat have provided lots of input on several revisions of the draft.
10. IANA Considerations 10. IANA Considerations
IANA is requested to provide a UDP port number for use by this IANA is requested to provide a well-known UDP port number for use by
protocol, and also to provide registries for message and option this 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 require specification (an RFC or
(it may be Informational), while types 192-255 are freely available other permanent and readily available reference), while types 192-255
for experimental, private or vendor specifc use. The registry should are for experimental use and are not registered. The registry should
include the messages defined in Section 5 include the messages defined in Section 5. A message specification
must describe the behaviour with known option types as well as the
default behaviour with unknown ones.
There should also be an option type registry. Option types 0-49151 There should also be an option type registry. Option types 0-49151
can be assigned referencing an RFC (it may be Informational), while require specification (an RFC or other permanent and readily
types 49152-65535 are freely available for experimental, private or available reference), while types 49152-65535 are for experimental
vendor specifc use. The registry should include the options defined use and are not registered. The registry should include the options
in Section 3.2. defined in Section 3.2. An option specification must describe how
the option may be used with the known message types. This includes
which message types the option may be used with.
The initial registry definitions could be as follows:
Multicast Ping Protocol Parameters:
Registry Name: Multicast Ping Protocol Message Types
Reference: [this doc]
Registration Procedures: Specification Required
Registry:
Type Name Reference
----------- ------------------------------------ ----------
65 Echo Reply [this doc]
73 Init [this doc]
81 Echo Request [this doc]
83 Server Response [this doc]
192-255 Experimental
Registry Name: Multicast Ping Protocol Option Types
Reference: [this doc]
Registration Procedures: Specification Required
Registry:
Type Name Reference
----------- ------------------------------------ ----------
0 Version [this doc]
1 Client ID [this doc]
2 Sequence Number [this doc]
3 Client Timestamp [this doc]
4 Multicast Group [this doc]
5 Option Request Option [this doc]
6 Server Information [this doc]
7 Reserved [this doc]
8 Reserved [this doc]
9 TTL [this doc]
10 Multicast Prefix [this doc]
11 Session ID [this doc]
12 Server Timestamp [this doc]
49152-65535 Experimental
11. 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. See below for how spoofing can be
prevented.
For ASM (Any-Source Multicast) a host could also make a multicast
ping server send multicast packets to a group that is used for
something else, possibly disturbing other uses of that group. The
main concern is bandwidth. Since there is a well-known port, it
should not be received by other applications. Due to this, a server
on the Internet SHOULD perform rate limiting.
In order to help prevent spoofing, a server SHOULD require the client In order to help prevent spoofing, a server SHOULD require the client
to send an Init message, and return an unpredictable Session ID in to send an Init message, and return an unpredictable Session ID in
the response. The ID should be associated with the IP address and the response. The ID should be associated with the IP address and
have a limited lifetime. The server SHOULD then only respond to have a limited lifetime. The server SHOULD then only respond to
Request messages that have a valid Session ID associated with the Request messages that have a valid Session ID associated with the
source IP address of the Request. source IP address of the Request.
Server implementations should allow administrators to restrict which Server implementations should allow administrators to restrict which
groups a server responds to, and also perform rate limiting. This is groups a server responds to, and also perform rate limiting. This is
discussed in Section 8). discussed in Section 8.
12. References 12. References
12.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] "IANA, Address Family Numbers",
Specification", RFC 2460, December 1998.
[4] "IANA, Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
12.2. Informative References 12.2. Informative References
[5] "ssmping implementation", [4] "ssmping implementation",
<http://www.venaas.no/multicast/ssmping/>. <http://www.venaas.no/multicast/ssmping/>.
[6] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for [5] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
Application Designers", draft-ietf-tsvwg-udp-guidelines-10 (work Application Designers", draft-ietf-tsvwg-udp-guidelines-11 (work
in progress), August 2008. in progress), October 2008.
Author's Address Author's Address
Stig Venaas Stig Venaas
UNINETT UNINETT
Trondheim NO-7465 Trondheim NO-7465
Norway Norway
Email: venaas@uninett.no Email: venaas@uninett.no
 End of changes. 29 change blocks. 
69 lines changed or deleted 125 lines changed or added

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