--- 1/draft-ietf-mboned-ssmping-02.txt 2008-02-12 13:12:17.000000000 +0100 +++ 2/draft-ietf-mboned-ssmping-03.txt 2008-02-12 13:12:17.000000000 +0100 @@ -1,19 +1,18 @@ Network Working Group S. Venaas Internet-Draft UNINETT -Intended status: Informational H. Santos -Expires: May 22, 2008 NEC Europe Ltd. - November 19, 2007 +Intended status: Informational February 12, 2008 +Expires: August 15, 2008 - ssmping Protocol - draft-ietf-mboned-ssmping-02 + Multicast Ping Protocol + draft-ietf-mboned-ssmping-03 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,167 +23,176 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 22, 2008. + This Internet-Draft will expire on August 15, 2008. Copyright Notice - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). Abstract - The ssmping protocol specified in this document allows for checking - whether one can receive multicast, both Source-Specific Multicast - (SSM) and Any-Source Multicast (ASM), as well as to obtain additional - multicast related information. This protocol is based on an + The Multicast Ping Protocol specified in this document allows for + checking whether an endpoint can receive multicast, both Source- + Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also + be used to obtain additional multicast related information like + multicast tree setup time etc. This protocol is based on an implementation of tools called ssmping and asmping. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 5 - 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Message types and options . . . . . . . . . . . . . . . . . . 9 + 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6 + 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5. Message types and options . . . . . . . . . . . . . . . . . . 10 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 10 - 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 11 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Intellectual Property and Copyright Statements . . . . . . . . . . 16 1. Introduction - The ssmping protocol specified in this document allows for checking - multicast connectivity. Not only reception of multicast (SSM or - ASM), but can also provide other information like multicast tree - setup time, the number of hops the packets have traveled, as well as - the packet delay and loss. This functionality resembles, in part, - the ICMP Echo Request/Reply infrastructure, but uses UDP and requires + The Multicast Ping Protocol specified in this document allows for + checking multicast connectivity. In addition to checking reception + of multicast (SSM or ASM), the protocol can provide related + information like multicast tree setup time, the number of hops the + packets have traveled, as well as packet delay and loss. This + functionality resembles, in part, the ICMP Echo Request/Reply + mechanism, but uses UDP (RFC 768 [2] and RFC 2460 [3]) and requires both a client and a server implementing this protocol. The protocol here specified is based on the actual implementation of - the ssmping and asmping tools [3] 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. 2. Architecture Before describing the protocol in detail, we provide a brief overview of how the protocol may be used and what information it may provide. - The typical usage of an ssmping/asmping session is as follows. A - server runs continuously to serve requests from clients. When a user - decides to verify the multicast reception from a specific server - (knowing one of the server's unicast addresses is required), the - client will send a unicast message to the server asking for a group - to use. Optionally the user may have requested a specific group or - scope, in which case the client will ask for a group matching the - user's request. The server will respond with a group to use, or an - error if no group is available. Next, the client joins an SSM - channel (S,G) where S is a unicast address of the target server, or - an ASM group G, where G is the group specified by the server. + The typical protocol usage is as follows: A server runs continuously + to serve requests from clients. A client can test the multicast + reception from this server, provided it knows a unicast address of + the server. It will then send a unicast message to the server asking + for a group to use. Optionally the user may have requested a + specific group or scope, in which case the client will ask for a + group matching the user's request. The server will respond with a + group to use, or an error if no group is available. Next, for ASM, + the client joins an ASM group G, while for SSM it joins a channel + (S,G). Here G is the group specified by the server, and S is the + unicast address used to reach the server. - After joining the channel, the client unicasts ssmping requests to - the server. The requests are sent using UDP with destination port - set to the standardised ssmping port [TBD]. The requests are sent - periodically, e.g., once per second, to the server. The requests - contain a sequence number, and typically a timestamp. The requests - are echoed back by the server, except the server may add a few - options. To each request, the server sends two replies. One as - unicast back to the port and address the request was sent from, and - also one as multicast back to the port from which the request - originated with the requested group G as destination address. The - server should specify the TTL used for both the unicast and multicast - messages (we recommend at least 64) and includes a TTL option for the - client to compute the number of hops. The client should leave the - channel/group when it has finished its measurements. + After joining the channel, the client unicasts multicast ping + requests to the server. The requests are sent using UDP with + destination port set to the standardised multicast ping port [TBD]. + The requests are sent periodically, e.g., once per second, to the + server. The requests contain a sequence number, and typically a + timestamp. The requests are echoed back by the server, except the + server may add a few options. For each request, the server sends two + replies. One reply is unicast to the source IP address and source + UDP port of the request, while another is multicast back to requested + multicast group G and the source UDP port of the request. Both the + replies are sent from the same port from which the request was + received. The server should specify the TTL used for both the + unicast and multicast messages (we recommend at least 64) and + includes a TTL option for the client to compute the number of hops. + The client should leave the channel/group when it has finished its + measurements. By use of this protocol, a client can obtain information about several multicast delivery characteristics. First, by receiving unicast replies, it can verify that the server is receiving the unicast requests, is operational and responding. Hence, provided that the client receives unicast replies, a failure to receive multicast indicates either a multicast problem or a multicast administrative restriction. If it does receive multicast, it knows not only that it can receive; it may also estimate the amount of time it took to establish the multicast tree (at least if it is in the range of seconds), whether there are packet drops, and the length and variation of Round Trip Times (RTT). For unicast, the RTT is the time from when the unicast request is sent to when the reply is received. The measured multicast RTT also references the client's unicast request. By use of the TTL option specifying the TTL of the replies when they are originated, the client can also determine the number of router hops it is from the source. Since similar information is obtained in the unicast replies, the host may compare its multicast and unicast results and is able to check for - differences in the number of hops, RTT, etc. Provided that the - server sends the unicast and multicast replies nearly simultaneously, - it may also be able to measure the difference in one way delay for - unicast and multicast on the path from server to client, and also - differences in delay. Servers may optionally specify a timestamp. - This may be useful since the unicast and multicast replies can not be - sent simultaneously (the delay depending on the host's operating - system and load), or whether the client and server have synchronised - clocks. + 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 + details about the multicast tree and multicast tree changes. E.g., + 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 + nearly simultaneously, the client may also be able to measure the + difference in one way delay for unicast and multicast on the path + from server to client, and also differences in delay. Servers may + optionally specify a timestamp. This may be useful since the unicast + and multicast replies can not be sent simultaneously (the delay + depending on the host's operating system and load). 3. Protocol specification - There are four different ssmping message types. There are Echo - Request and Echo Reply messages used for the actual measurements; - there is an Init message that SHOULD be used to initialise a ping - session and negotiate which group to use; and finally a Server - Response message that is mainly used in response to the Init message. + There are four different message types. There are Echo Request and + Echo Reply messages used for the actual measurements; there is an + Init message that SHOULD be used to initialise a ping session and + negotiate which group to use; and finally a Server Response message + that is mainly used in response to the Init message. The messages + MUST always be in network byte order. UDP checksums MUST always be + used. - The ssmping messages share a common format: one octet specifying the - message type, followed by a number of options in TLV (Type, Length - and Value) format. This makes the protocol easily extendible. The - Init message generally contains some prefix options asking the server - for a group from one of the specified prefixes. The server responds - with a Server Response message that contains the group address to - use, or possibly prefix options describing what multicast groups the - server may be able to provide. For an Echo Request the client - generally includes a number of options, and a server may simply echo - the content back (only changing the message type), without inspecting - the options. However, the server SHOULD add a TTL option, and there - are some other options that a server implementation MAY support, - e.g., the client may ask for certain information or a specific - behaviour from the server. The Echo Replies (one unicast and one - multicast) MUST first contain the exact options from the request (in - the same order), and then, immediately following, options appended by - the server. + The messages share a common format: one octet specifying the message + type, followed by a number of options in TLV (Type, Length and Value) + format. This makes the protocol easily extendible. The Init message + generally contains some prefix options asking the server for a group + from one of the specified prefixes. The server responds with a + Server Response message that contains the group address to use, or + possibly prefix options describing what multicast groups the server + may be able to provide. For an Echo Request the client generally + includes a number of options, and a server may simply echo the + content back (only changing the message type), without inspecting the + options. However, the server SHOULD add a TTL option, and there are + other options that a server implementation MAY support, e.g., the + client may ask for certain information or a specific behaviour from + the server. The Echo Replies (one unicast and one multicast) MUST + first contain the exact options from the request (in the same order), + and then, immediately following, any options appended by the server. + A server MUST NOT process unknown options, but they MUST still be + included in the Echo Reply. A client MUST ignore any unknown + options. This document defines a number of different options. Some options do not require processing by servers and are simply returned unmodified in the reply. There are, however, other client options that the server may care about, and also server options that may be requested - by a client. - - Unless otherwise specified, an option MUST NOT be used multiple times - in the same message. + by a client. Unless otherwise specified, an option MUST NOT be used + multiple times in the same message. 3.1. Option format All options are TLVs formatted as specified below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -208,46 +216,41 @@ Version, type 0. Length MUST be 1. This option MUST always be included in all messages, and the value MUST be set to 2 (in decimal). Note that there are older implementations of ssmping that only partly follow this specification. They can be regarded as version 1 and do not use this option. 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 this Init/Request or not. A server should treat + 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 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. - Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD include - this in Request messages and MUST NOT include it in Init messages. A - server replying to a request MUST copy it into the Reply. In - addition, a server supporting this option, SHOULD include it in Reply - messages, if requested by the client. Note that this means that the - option may be present in the Reply message twice; both a client - timestamp as part of the echoed Request, and another timestamp added - by the server. The timestamp specifies the time when the message - (query or reply) 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. + Client Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD + 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 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. @@ -249,34 +252,35 @@ 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 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Multicast group address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | - The address family is a value 0-65535 as assigned by IANA for - Internet Address Families [2]. This is followed by the group - address. For IPv4 the option value length will be 6, for IPv6 18. + Internet Address Families [4]. This is followed by the group + address. Length of the option value will be 6 for IPv4, and 18 for + IPv6. Option Request Option, type 5. Length MUST be greater than 1. This - option MAY be used in Init and Request messages. It MUST NOT be used - in any other messages, except that a server will, in a Reply, echo - back this option if present in the Request. This option contains a - list of option types for options that the client is requesting from - the server. Support for this option is optional for both clients and - servers. The length of this option will be a non-zero even number, - since it contains one or more option types that are two octets each. - The format of the option value is as below. + 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 + Request message, the server MUST include it in a reply (Reply + message) to the Request. This option contains a list of option types + for options that the client is requesting from the server. Support + for this option is optional for both clients and servers. The length + of this option will be a non-zero even number, since it contains one + or more option types that are two octets each. The format of the + option value is as below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... | This option might be used by the client to ask the server to include options like Timestamp or Server Information. A client MAY request @@ -289,71 +293,83 @@ 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 implementations for an option that is now deprecated. This option - should no longer be used. Clients MUST not use this option, and - Servers MUST ignore it. + 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 back in the Reply + message). - Pad, type 8. Length can be anything, including 0. This option is - used by clients to increase the request size in order to have the - server deliver responses of a particular size. If the server adds - any options when responding, it should, if possible make the response - the same size as the request by shrinking the pad option (i.e., not - simply including it, as is, like all other client options). If the - options added by the server consume as much space as the pad option - does, or more, the server should remove the entire pad option. + Type 8, Reserved. 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 back in the Reply + message). TTL, type 9. Length MUST be 1. This option contains a single octet 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. Although this option is not absolutely required, the - server is expected to use it if it knows what the TTL of the Reply - will be. In general the server can specify a specific TTL to the - host stack. + 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. + Request/Reply messages. Note that this option MAY be included + multiple times to specify multiple prefixes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Prefix Length |Partial address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | The address family is a value 0-65535 as assigned by IANA for - Internet Address Families [2]. This is followed by a prefix length + Internet Address Families [4]. This is followed by a prefix length (0-32 for IPv4, 0-128 for IPv6), and finally a group address. The group address need only contain enough octets to cover the prefix length bits (e.g., there need be no group address if the prefix length is 0, the group address would have to be 3 octets long if the prefix length is 17-24). Any bits past the prefix length MUST be ignored. For IPv4 the option value length will be 3-7, while for IPv6 3-19. Session ID, type 11. Length MUST be non-zero. A server MAY include 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 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. + 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 + 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 (beginning of the year 1970). The next 4 + bytes specify the number of microseconds since the last second since + the Epoch. 4. Packet Format The format of all messages is a one octet message type, directly followed by a variable number of options. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Option | @@ -386,39 +402,39 @@ way (no spacing or padding), i.e., options might start at any octet boundary. The option format is specified above. 5. Message types and options For the readers convenience we provide the matrix below, showing what options can go in what messages. Option / Message Type | Init | Server Response | Request | Reply | -----------------------------------------------------------------+ - Version (0) | MUST | MUST | MUST | ECHO | + Version (0) | MUST | ECHO | MUST | ECHO | Client ID (1) |SHOULD| ECHO | SHOULD | ECHO | Sequence number (2) | NOT | ECHO | MUST | ECHO | - Timestamp (3) | NOT | NOT | SHOULD |ECHO/RQ| + Client Timestamp (3) | NOT | NOT | SHOULD | ECHO | Multicast group (4) | NOT | MAY | MUST | ECHO | Option Request (5) | MAY | NOT | MAY | ECHO | Server Information (6)| NOT | RQ | NOT | NOT | - Reserved (7) | NOT | NOT | NOT | NOT | - Pad (8) | NOT | NOT | MAY | ECHO* | + Reserved (7) | NOT | NOT | NOT | ECHO | + Reserved (8) | NOT | NOT | NOT | ECHO | TTL (9) | NOT | NOT | NOT |SHOULD | Multicast prefix (10) | MAY | MAY | NOT | NOT | Session ID (11) | NOT | MAY | ECHO | MAY | + Server Timestamp (12) | NOT | NOT | NOT | RQ | NOT means that the option MUST NOT be included. ECHO for a server means that if the option is specified by the client, then the server MUST echo the option back in the response, with the exact same option - value. The exception is ECHO* where the option value may be - modified. ECHO for a client means that it MUST echo the option it - got in the last message from the server in the following messages it + 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 sends. RQ means that the server SHOULD include the option in the response, when requested by the client using the Option Request option. 6. Client Behaviour We will consider how a typical interactive client using the above 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 with a prefix option containing the desired address family and zero @@ -435,29 +451,30 @@ If the client receives a Server Response message containing a group address it can start sending Request messages, see the next paragraph. If there is no group address option, it would typically exit with an error message. The server may have included some prefix options in the Server Response. The client may use this to provide the user some feedback on what prefixes or scopes are available. Assuming the client got a group address in a Server Response it can start pinging. Before it does that it should let the user know which - group is being used. When sending ping Requests the client must + group is being used. Normally, a client should send at most one ping + request per second. When sending ping Requests the client must always specifiy 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 Response together with the group address, and then the ID would stay the same during the entire ping sequence. However, if for instance 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 - client implementation MUST always use the last Session ID it + pinging but the Session ID may be changed by the server. Hence a + client implementation must always use the last Session ID it received, and not necessarily the one from the Server Response message. If a client receives a Server Response message in response to a Request message (that is, a Server Response message containing a sequence number), this means there is an error and it should stop sending Requests. This may for instance happen after server restart. The client may have an option for the user to obtain server information. If the user asks for server information, the client can send an Init message with no prefix options, but with an Option Request Option, requesting the server to return a Server Information @@ -496,111 +513,143 @@ Server Response message containing prefix options listing what prefixes may be available to the client. Finally, if the Init message requests the Server Information option, it should include 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 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 Reply messages contain the exact options and in the same order, as in - the Request (only exception is the pad option), and after that the - server adds a TTL option and additional options if needed. E.g., it - may add a timestamp if requested by the client. If the server is not - happy with the group address and Session ID, it may send a Server - Response message asking the client to stop. This Server Response - must echo the sequence number from the Request. This Server Response - may contain which prefixes the client can try to request addresses - from. The unicast and multicast Reply messages have identical UDP - payload apart from possibly TTL and timestamp option values. + the Request, and after that the server adds a TTL option and + 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 + (bad group address or Session ID, request is too large etc), it may + send a Server Response message asking the client to stop. This + Server Response must echo the sequence number from the Request. This + Server Response may contain which prefixes the client can try to + request addresses from. The unicast and multicast Reply messages + have identical UDP payload apart from possibly TTL and timestamp + option values. Note that the server may receive Request messages with no prior Init 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 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 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 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. + 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. Acknowledgements The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source Specific Multicast, and also the Internet Draft draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave Thaler have contributed in different ways to the implementation of - the ssmping tools at [3]. 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 and provided feedback that have influenced the current protocol. Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui, - Bharat Joshi, Olav Kvittem, Kamil Sarac, Pekka Savola, Trond Skjesol - and Cao Wei for reviewing and providing feedback on this draft. + Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, + Trond Skjesol and Cao Wei for reviewing and providing feedback on + this draft. In particular Hugo, Gorry and Bharat have provided lots + of input on several revisions of the draft 9. IANA Considerations IANA is requested to provide a UDP port number for use by this - protocol, and also provide a registry for ssmping option types. + protocol, and also to provide registries for message and option + types. + + 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 + (it may be Informational), while types 192-255 are freely available + for experimental, private or vendor specifc use. + + There should also be an option type registry. Option types 0-49151 + can be assigned referencing an RFC (it may be Informational), while + types 49152-65535 are freely available for experimental, private or + vendor specifc use. 10. Security Considerations 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 - arbitrary ssmping server on the Internet send packets to this other - host. This hehaviour is fairly harmless. The worst case is if the - host receiving the unicast replies also happen to be performing an - ssmping test towards that particular server. In this unlikely event, - there would be an amplification effect where the host receives twice - as many replies as there are requests sent. An ssmping server should - perform rate limiting, to guard against this function being used as a - DoS attack. A client should also use the client ID option to - distinguish replies to its own requests from replies that might be to - other requests. + arbitrary multicast ping server on the Internet send packets to this + other host. This behaviour is fairly harmless. The worst case is if + the host receiving the unicast replies also happen to be joined to + the multicast group used. In this case, there would be an + amplification effect where the host receives twice as many replies as + there are requests sent. + + Servers should perform rate limiting, to guard against this function + being used as a DoS attack. 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. + 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 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [2] "IANA, Address Family Numbers", + [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [4] "IANA, Address Family Numbers", . 11.2. Informative References - [3] "ssmping implementation", + [5] "ssmping implementation", . -Authors' Addresses + [6] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for + Application Designers", draft-ietf-tsvwg-udp-guidelines-05 (work + in progress), February 2008. + +Author's Address Stig Venaas UNINETT Trondheim NO-7465 Norway Email: venaas@uninett.no - Hugo Santos - NEC Europe Ltd. - Kurfuersten-Anlage 36 - Heidelberg 69115 - Germany - - Email: hugo.santos@nw.neclab.eu - Full Copyright Statement - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF