Network Working Group                                          S. Venaas
Internet-Draft                                                   UNINETT
Intended status: Standards Track                        November 3,                        December 2, 2008
Expires: May 7, June 5, 2009

                        Multicast Ping Protocol
                      draft-ietf-mboned-ssmping-06
                      draft-ietf-mboned-ssmping-07

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
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 7, June 5, 2009.

Abstract

   The Multicast Ping Protocol specified in this document allows for
   checking whether an endpoint can receive multicast, both Source-
   Specific Multicast (SSM) and Any-Source Multicast (ASM).  It can also
   be used to obtain additional multicast related multicast-related information like such as
   multicast tree setup time etc. time.  This protocol is based on an
   implementation of tools called ssmping and asmping.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol specification Specification . . . . . . . . . . . . . . . . . . . .  4  5
     3.1.  Option format Format  . . . . . . . . . . . . . . . . . . . . . .  5  6
     3.2.  Defined Options  . . . . . . . . . . . . . . . . . . . . .  6
   4.
     3.3.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . . 10
   5. 11
     3.4.  Message types Types and options Options  . . . . . . . . . . . . . . . . 11
     3.5.  Rate Limiting  . . 11
   6. . . . . . . . . . . . . . . . . . . . . 13
   4.  Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 13
   7. 14
   5.  Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14
   8. 15
   6.  Recommendations for Implementers . . . . . . . . . . . . . . . 15
   9. 16
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   10. 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   11. 17
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   12. 18
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     12.1. 19
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     12.2. 19
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18 19
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20 21

1.  Introduction

   The Multicast Ping Protocol specified in this document allows for
   checking multicast connectivity.  In addition to checking reception
   of multicast (SSM or ASM), the protocol can provide related
   information like such as multicast tree setup time, the number of hops the
   packets have traveled, as well as packet delay and loss.  This
   functionality resembles, in part, the ICMP Echo Request/Reply
   mechanism,
   mechanism [2], but uses UDP RFC 768 [2] [3] and requires both a client and a
   server implementing this protocol.  Intermediate routers are not
   required to support this protocol.  They forward Protocol Messages
   and data traffic as usual.

   The

   This protocol here specified is based on the actual current implementation of the ssmping
   and asmping tools [4] [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 protocol usage is as follows:

      A server runs continuously to serve requests from clients.  A
      client can test has somehow learned the multicast
   reception from this server, provided it knows a unicast address of the server and
      tests the multicast reception from the server.  It

      The client application will then send a unicast message to the
      server asking for a group to use.  Optionally the a user may have requested request a
      specific group or scope, in which case the client will ask for a
      group matching the user's request.  The server will respond with a
      group to use, or an error if no group is available.

      Next, for ASM, the client joins an ASM group G, while for SSM it
      joins a channel
   (S,G).  Here (S,G), where G is the multicast group address
      specified by the server, and S is the unicast address used to
      reach the server.

      After joining the channel, group/channel, the client unicasts multicast
      ping requests to the server.  The requests are sent using UDP with
      the destination port set to the standardised multicast ping port
      [TBD].  The requests are sent periodically, e.g., perhaps once per
      second, to the server.  The  These requests contain a sequence number,
      and typically a timestamp.  The requests are echoed by the server, except the server
      which may add a few options.

      For each request, the server sends two replies.  One reply is
      unicast back to the source IP address and source UDP port of the request, while another
      requesting client.  The other reply is multicast to the requested
      multicast group G and the source UDP port of the request. requesting
      client.

      Both replies are sent from the same port on which the request was
      received.  The server should specify the TTL (IPv4 time-to-live or
      IPv6 hop-count) used for both the unicast and multicast messages (we recommend
      (TTL of at least 64) 64 is recommended) by including a TTL option; allowing option.
      This allows the client to compute the number of hops.  The client
      should leave the channel/group group/channel when it has finished its
      measurements.

   By use of this protocol, a client (or a user of the client) can
   obtain information about several multicast delivery characteristics.
   First, by receiving unicast replies, it the client can verify that the
   server is receiving the unicast requests, is operational and
   responding.  Hence, provided that the client receives unicast
   replies, a failure to receive multicast indicates either a multicast
   problem or a multicast administrative restriction.  If it does
   receive multicast, it knows not only that it can receive; receive multicast
   traffic, it may also estimate the amount of time it took to establish
   the multicast tree (at least if it is in the range of seconds),
   whether there are packet drops, and the length and variation of Round
   Trip Times (RTT).

   For unicast, the RTT is the time from when the unicast request is
   sent to the time when the reply is received.  The measured multicast
   RTT also references the client's unicast request.  By 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 such as the number of hops, RTT, etc. and RTT.

   The number of multicast hops and changes in the number of hops over time,
   time may also reveal details about the multicast tree and multicast tree
   changes.  Provided that the server sends the unicast and multicast
   replies nearly simultaneously, the client may also be able to measure
   the difference in one way delay for unicast and multicast on the path
   from server to client, and also differences in delay.

   Servers may optionally specify a timestamp.  This may be useful since
   the unicast and multicast replies can not be sent simultaneously (the
   delay
   depending is dependent on the host's operating system and load).

3.  Protocol specification Specification

   There are four different message types.  There are  Echo Request and Echo Reply
   messages are used for the actual measurements; there is an measurements.  An Init message that
   SHOULD be used to initialise a ping session and negotiate which group
   to use; and finally use.  Finally a Server Response message that is mainly used in
   response to the Init message.  The messages MUST always be in network
   byte order.  UDP checksums MUST always be used.

   The messages share a common format: one octet specifying the message
   type, followed by a number of options in TLV (Type, Length and Value)
   format.  This makes the protocol easily extendible.

   Message types in the range 0-191 are reserved and available for
   allocation in an IANA Registry.  Message types in the range 192-255
   are not registered and are freely available for experimental use.
   See Section 8.

   The Init message generally contains some prefix options asking the
   server for a group from one of the specified prefixes.  The server
   responds with a Server Response message that contains the group
   address to use, or possibly prefix options describing what multicast
   groups the server may be able to provide.

   For an Echo Request the client generally includes a number of
   options, and a server MAY simply echo the contents (only changing the
   message type) without inspecting the options if it does not support
   any options.  This might be true for a simple Multicast Ping Protocol
   server.  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 (excluding the Session ID option)
   from the request (in the same order), and then, immediately
   following, any options appended by the server.  A server MUST NOT
   process unknown options, but they MUST still be included in the Echo
   Reply.  A client MUST ignore any unknown options.

   The size of the protocol messages is generally smaller than the Path
   MTU and fragmentation is not a concern.  There may however be cases
   where the Path MTU is really small, or that a client sends large
   requests in order to verify that it can receive fragmented multicast
   datagrams.  This document does not specify whether Path MTU Discovery
   should be performed, etc.  A possible extension could be an option
   where a client requests Path MTU Discovery and receives the current
   Path MTU from the server.

   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 as well as server options that may be
   requested by a client.  Unless otherwise specified, an option MUST
   NOT be used multiple times in the same message.

3.1.  Option format 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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Value                             |
      |                               .                               |
      |                               .                               |
      |                               .                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (2 octets) specifies the option.  The different options are
   defined below.

   Length (2 octets) specifies the length of the value field.  Depending
   on the option type, it can be from 0 to 65535.

   Value.  The value

   Value must always be of the specified length.  See the respective
   option definitions for possible values.  If the length is 0, the
   value field is not included.

3.2.  Defined Options

   This document defines the following options: Version (0), Client ID
   (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4),
   Option Request Option (5), Server Information (6), TTL (9), Multicast
   Prefix (10), Session ID (11) and Server Timestamp (12).  Values 7 and
   8 are reserved.  The options are defined below.

      Version, type 0

         Length MUST be 1.  This option MUST always be included

   Option types in all
         messages, and the range 0-49151 are reserved and available for
   allocation in an IANA Registry.  Option types in the range 49152-
   65535 are not registered and are freely available for experimental
   use.  See Section 8.

      Version, type 0

         Length MUST be 1.  This option MUST always be included in all
         messages, and for the current specified protocol this value
         MUST be set to 2 (in decimal).  Note that there are
         implementations of older revisions of this protocol that only
         partly follow this specification.  They can be regarded as
         version 1 and do not use this option.  If a server receives a
         message with a version other than 2 (or missing), the server
         SHOULD (unless it supports the particular version) send a
         Server Response message back with version set to 2.  Client ID
         and Sequence Number options SHOULD be echoed if present.  It  The
         server SHOULD not NOT include any other options.  A client
         receiving a response with a version other than 2, 2 MUST (unless
         it supports the particular version), stop
         sending requests to the server. server (unless it supports the
         particular version).

      Client ID, type 1

         Length MUST be non-zero.  A client SHOULD always include this
         option in all messages (both Init and Echo Request).  The
         client may use any value it likes to be able to detect whether a reply is
         a reply to its Init/Request Init/Echo Request or not.  A server should treat
         this as opaque data, and MUST echo this option back in the
         reply if present (both Server Response and Echo Reply).  The
         value might be a 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 Echo
         Request messages and MUST NOT include it in Init messages.  A
         server replying to a an Echo Request message MUST copy it into
         the Echo Reply (or Server Response message on error).  This contains a 32 bit
         sequence number.  The values would
         sequence number is a 32-bit integer.  Values typically start at
         1 and increase by one for each request Echo Request in a sequence.

      Client Timestamp, type 3

         Length MUST be 8 bytes.  A client SHOULD include this in Echo
         Request messages and MUST NOT include it in Init messages.  A
         server replying to a an Echo Request message MUST copy it into
         the Echo Reply.  The timestamp specifies the time when the Echo
         Request message is sent.  The first 4 bytes specify the number
         of seconds since the Epoch (0000 UTC Jan 1, 1970).  The next 4
         bytes specify the number of microseconds since the last second
         since
         specified in the Epoch. first 4 bytes.

      Multicast Group, type 4
         Length MUST be greater than 2.  It MAY be used in Server
         Response messages to tell the client what group to use in
         subsequent Echo Request messages.  It MUST be used in Echo
         Request messages to tell the server what group address to
         respond to (this group would typically be previously obtained
         in a Server Response message).  It MUST be used in Echo Reply
         messages (copied from the Echo Request message).  It MUST NOT
         be used in Init messages.  The format of the option value is as
         below.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Address Family         |  Multicast group address...   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ....                         |

         The address family is a value 0-65535 as assigned by IANA for
         Internet Address Families [3]. 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
         client messages (Init and Echo Request messages).  A server
         MUST NOT send this option, except that if it is present in a an
         Echo Request message, the server MUST echo it in replies (Reply (Echo
         Reply message) to the Echo Request.  This option contains a
         list of option types for options that the client is requesting
         from the server.  Support for this option is optional for both
         clients and servers.  The length of this option will be a non-zero 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 Server Information in Init messages; it MUST NOT
         request it in other messages.  A client MAY request a Timestamp timestamp
         in Echo Request messages; it MUST NOT request it in other
         messages.  Subject to enforcing the above restrictions, a
         server supporting this option SHOULD include the requested
         options in responses (Reply (Echo Reply messages) to the Echo Request
         containing the Option Request Option.  The server may may,
         according to implementation or local configuration, not
         necessarily include all the requested options, or possibly
         none.  Any options included are appended to the echoed options,
         similar to other options included by the server.

      Server Information, type 6

         Length MUST be non-zero.  It MAY be used in Server Response
         messages and MUST NOT be used in other messages.  Support for
         this option is optional.  A server supporting this option
         SHOULD add it in Server Response messages if and only if
         requested by the client.  The value is a UTF-8 string that
         might contain vendor and version information for the server
         implementation.  It may also contain information on which
         options the server supports.  An interactive client MAY support
         this option, and SHOULD then allow a user to request this
         string and display it.

      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 an Echo Request message, it MUST be echoed in the
         Echo Reply message).

      Reserved, type 8

         This option code value was used by early implementations for an
         option that is now deprecated.  This option should no longer be
         used.  Clients MUST NOT use this option.  Servers MUST treat it
         as an unknown option (not process it if received, but if
         received in a an Echo Request message, it MUST be echoed in the
         Echo Reply message).

      TTL, type 9

         Length MUST be 1.  This option contains a single octet
         specifying the TTL of a an Echo Reply message.  Every time a
         server sends a unicast or multicast Echo Reply message, it
         SHOULD include this option specifying the TTL.  This is used by
         clients to determine the number of hops the messages have
         traversed.  It MUST NOT be used in other messages.  A server
         SHOULD specify this option if it knows what the TTL of the Echo
         Reply will be.  In general the server can specify a specific
         TTL to the host stack.  Note that the TTL is not necessarily
         the same for unicast and multicast.  Also note that this option
         SHOULD be included even when not requested by the client.

      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), prefix(es) and it MAY be used in
         Server Response messages to tell the client what prefix(es) it
         may try to obtain a group from.  It MUST NOT be used in Echo
         Request/Reply messages.  Note that this option MAY be included
         multiple times to specify multiple prefixes.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Address Family         | Prefix Length |Partial address|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ....      |

         The address family is a value 0-65535 as assigned by IANA for
         Internet Address Families [3]. address families [4].  This is followed by a prefix
         length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special
         'wildcard'
         "wildcard" use discussed below), and finally a group address.
         For any family, prefix length 0 means that any multicast
         address from that family is acceptable.  This is what we call
         'wildcard'.
         "wildcard."  The group address need only contain enough octets
         to cover the prefix length bits (i.e., the group address would
         have to be 3 octets long if the prefix length is 17-24, and
         there need be no group address for the wildcard with prefix
         length 0).  Any bits past the prefix length MUST be ignored.
         For IPv4, the option value length will be 4-7, while for IPv6,
         it will be 4-19, and for the wildcard, it will be 3.

      Session ID, type 11

         Length MUST be non-zero.  A server SHOULD 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
         subsequent Echo Request 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 per client state.  The value of a new
         Session ID should SHOULD be chosen pseudo randomly so that it is hard
         to predict.  This  The Session ID can be used to prevent spoofing of
         the source address of Echo Request
         messages, see messages.  See the Security
         Considerations for details.

      Server Timestamp, type 12

         Length MUST be 8 bytes.  A server supporting this option,
         SHOULD include it in Echo Reply messages, if requested by the
         client.  The timestamp specifies the time when the Echo Reply
         message is sent.  The first 4 bytes specify the number of
         seconds since the Epoch (0000 UTC Jan 1, 1970).  The next 4
         bytes specify the number of microseconds since the last second
         since
         specified in the Epoch.

4. first 4 bytes.

3.3.  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       |          Options ...                          |
      +-+-+-+-+-+-+-+-+            .                                  |
      |                            .                                  |
      |                            .                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-      .....

   There are four message types defined.  Type 81 (the character Q in
   ASCII) specifies an Echo Request (Query).  Type 65 (the character A
   in ASCII) specifies an Echo Reply (Answer).  Type 73 (the character I
   in ASCII) is an Init message, and type 83 (the character S in ASCII)
   is a Server Response message.

   The options directly immediately follow the type octet and are not aligned in
   any way (no spacing or padding), i.e., options might start at any
   octet boundary.  The option format is specified above.

5.

3.4.  Message types Types and options Options

   There are four message types defined.  We will now describe each of
   the message types and which options they may contain.

      Init, type 73

         This message is sent by a client to request information from a
         server.  It is mainly used for requesting a group address, but
         it may also be used to check which group prefixes the server
         may provide groups from, or other server information.  It MUST
         include a Version option, and SHOULD include a Client ID.  It
         MAY include Option Request and Multicast Prefix Options.  This
         message is a request for a group address if and only if it
         contains Multicast Prefix options.  If multiple Prefix options
         are included, they should be in prioritised order.  I.e., the
         server will consider the prefixes in the order they are
         specified, and if it finds a group for a prefix, it will only
         return that one group, not considering the remaining prefixes.

      Server Response, type 83

         This message is sent by a server.  Either server, either as a response to an
         Init, or in response to a an Echo Request.  When responding to
         Init, it may provide the client with a multicast group (if
         requested by the client), or it may provide other server
         information.  In response to a an Echo Request, the message tells
         the client to stop sending Echo Requests.  The Version option
         MUST always be included.  Client ID and Sequence Number options
         are echoed if present in the client message.  When providing a
         group to the client, it includes a Multicast Group option.  It
         SHOULD include Server Information and Prefix options if
         requested.

      Echo Request, type 81

         This message is sent by a client, asking the server to send
         unicast and multicast replies. Echo 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. ID
         was received in a Server Response message, then the Session ID
         MUST be included.  It SHOULD include Client ID and Client
         Timestamp options.  It MAY include an Option Request option.

      Echo Reply, type 65

         This message is sent by a server in response to an Echo Request
         message.  This message is always sent in pairs, one as unicast
         and one as multicast.  The contents of the messages are mostly
         the same.  The server always echoes most all of the options (but
         never the Session ID) from the Echo
         Request (any Request.  Any options in
         the Echo 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.
         to be echoed.  The two Echo Reply messages SHOULD both always
         contain a TTL option (not necessarily equal), and
         both equal).  Both Echo Reply
         messages SHOULD also when requested contain Server Timestamps
         (not necessarily
         equal) when requested.

   For the reader's convenience we provide the equal).

   The below matrix below, showing summarises what options can go in what messages.

      Option /

             \  Message Type |  Init  |  Server  |  Echo   |  Echo  |
      Option  \              |        | Response | Request | Reply  |
      -----------------------------------------------------------------+
      -----------------------+--------+----------+---------+--------+
      Version (0)            |  MUST  |      ECHO   MUST   |  MUST   |  ECHO  |
      Client ID (1)         |SHOULD|          | SHOULD |   ECHO   | SHOULD  |  ECHO  |
      Sequence Number (2)    |  NOT   |   ECHO   |  MUST   |  ECHO  |
      Client Timestamp (3)   |  NOT   |   NOT    | SHOULD  |  ECHO  |
      Multicast Group (4)    |  NOT   |   MAY    |  MUST   |  ECHO  |
      Option Request (5)     |  MAY   |   NOT    |  MAY    |  ECHO  |
      Server Information (6)| (6) |  NOT   |    RQ    |  NOT    |  NOT   |
      Reserved (7)           |  NOT   |   NOT    |  NOT    |  ECHO  |
      Reserved (8)           |  NOT   |   NOT    |  NOT    |  ECHO  |
      TTL (9)                |  NOT   |   NOT    |  NOT    |SHOULD    | SHOULD |
      Multicast Prefix (10)  |  MAY   |   MAY    |  NOT    |  NOT   |
      Session ID (11)        |  NOT   |      MAY  SHOULD  |  ECHO   |  MAY  NOT   |
      Server Timestamp (12)  |  NOT   |   NOT    |  NOT    |   RQ   |
      -----------------------+--------+----------+---------+--------+

   NOT means that the option MUST NOT be included.  ECHO for a server
   means that if the option is specified by the client, then the server
   MUST echo the option in the response, with the exact same option
   value.  ECHO for a client means that it MUST echo only applies to the option Session ID option.  If
   it got is present in the last message from Server Response, then it must be present with
   the server exact same option value in any subsequent messages it
   sends. the following Echo Requests.  RQ means
   that the server SHOULD include the option in the response, when
   requested by the client using the Option Request option.

6.

3.5.  Rate Limiting

   Clients MUST by default send at most one Echo Request per second.
   Servers MUST by default perform rate limiting, to guard against this
   protocol being used for DoS attacks.  The server MUST by default for
   a given client, respond to on average at most one Echo Request
   message per second.  Server implementations should provide
   configuration options allowing certain clients to perform more rapid
   Echo Requests.  If higher rates are allowed for specific client IP
   addresses, then Init messages and the Session ID option MUST be used
   to help prevent spoofing.

   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, Echo Requests at rates exceeding one
   per second.  See Section 9, "Security Considerations", for additional
   discussion.

4.  Client Behaviour

   We will consider how a typical interactive client using the above
   protocol would behave.

   A client need only require requires a user to specify the unicast address of the
   server.  It can then send an Init message with a prefix option
   containing the desired address family and zero prefix length
   (wildcard entry).  The server is can then free to decide which group, from the
   specified family, it should return.  A client may also allow a the user
   to specify group address(es) or prefix(es) (for IPv6, the user may
   only be required to specify a scope or an RP address, from which the
   client can construct the desired prefix, possibly embedded-RP).  From
   this the client can specify one or more prefix options in an Init
   message to tell the server which address it would prefer.  If the
   user specifies a group address, that can be encoded as a prefix of
   maximal length (e.g., 32 for IPv4).  The prefix options are in
   prioritised order, i.e., the client should put the most preferred
   prefix first.

   If the client receives a Server Response message containing a group
   address it can start sending Echo Request messages, see the next
   paragraph.  If there is no group address option, it the client would
   typically exit with an error message.  The server may have included
   some prefix options in the Server Response.  The client may use this
   to provide the user some feedback on what prefixes or scopes are
   available.

   Assuming the client got a group address in a Server Response, it can
   start pinging.  Before it does that, it should let the multicast pings, after letting the user know which group is
   being used.  Normally, a client should send at most one ping request Echo Request
   per second.

   When sending ping the Echo Requests, the client must always include the
   group option.  If the last message from the
   server Server Response contained a Session ID, then it
   must also include that that, with the exact same value.  Typically it would receive a Session ID value, 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
   received, and not necessarily the one from the Server Response
   message. Echo
   Requests.  If a client receives a Server Response message in response
   to a an Echo Request message (that is, a Server Response message containing a
   sequence number), this means there is an error and it should stop
   sending Echo Requests.  This may for instance could happen after server restart.

   The client may allow the user to request server information.  If the
   user requests server information, the client can send an Init message
   with no prefix options, but with an Option Request Option, requesting
   the server to return a Server Information option.  The server will
   return server information if supported, and it may also return a list
   of prefixes it supports.  It will however not return a group address.
   The client may also try to obtain only a list of prefixes by sending
   an Init message with no prefixes and not requesting any specific
   options.

   Note that

   Although not recommended, a client may pick a multicast group and
   send Echo Request messages without first going through the Init -
   Server Response negotiation.  If this is supported by the server and
   the server is okay with the group used, the server can then send Echo
   Reply messages as usual.  If the server is not okay, it will send a
   Server Response telling the client to stop.

7.

5.  Server Behaviour

   We will consider how a typical server using the above protocol would
   behave.  First we consider
   behave, first looking at how to respond to Init messages.

   If the Init message contains prefix options, the server should look
   at them in order and see if it can assign a multicast address from
   the given prefix.  The server would be configured, configured with, possibly have
   a default,
   specifying which a set of groups it can offer.  It may have a large pool just
   picking
   and pick a group at random, or possibly choose choosing a group based on
   hashing of the client's IP address or identifier, or just simply use a
   fixed group.  A server could possibly decide whether to include site
   scoped group ranges based on the client's IP address.  It is left to
   the server to decide whether it should allow the same address to be
   used simultaneously by multiple clients.

   If the server finds a suitable group address, it returns this in a
   group option in a Server Response message.  The server should
   additionally include a Session ID.  This may help the server if it is
   to keep some state, for instance for
   making to make sure the client uses the
   group it got assigned.  A good Session ID would be a pseudo random
   byte string that is hard to predict.  If the server cannot find a
   suitable group address, or if there were no prefixes in the Init
   message, it may send a Server Response message containing prefix
   options listing what prefixes may be available to the client.
   Finally, if the Init message requests the Server Information option, it
   the server should include that.

   When the server receives a an Echo 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 Echo Reply message
   back to the client, and also a multicast Echo Reply message to the
   group address.  The Echo Reply messages contain the exact options
   (but no Session ID) and in the same order, as in the Echo Request,
   and after that the server adds a TTL option and additional options if
   needed.  E.g.,  For example, it may add a timestamp if requested by the
   client.  If the server is not happy with the Echo Request
   (bad (such as
   bad group address or Session ID, request is too large etc), large), it may send a
   Server Response message asking the client to stop.  This Server
   Response must echo the sequence number from the Echo Request.  This
   Server Response may contain group prefixes from which a client can
   try to request a group address.  The unicast and multicast Echo Reply
   messages have identical UDP payload apart from possibly TTL and
   timestamp option values.

   Note that the server may receive Echo Request messages with no prior
   Init message.  This may happen when the server restarts or if a
   client sends a an Echo 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
   replies.

8. the server sends back a Server Response.

6.  Recommendations for Implementers

   The protocol as specified is fairly flexible and leaves a lot of
   freedom for implementers.  In this section we present some
   recommendations.

   Server administrators should be able to configure one or multiple
   group prefixes in a server implementation.  When deploying servers on
   the Internet and in other environments, the server administrator
   should be able to restrict the server to respond to only a few
   multicast groups which should not be currently used by multicast
   applications.  A server implementation should also provide
   flexibility for an administrator to apply various policies to provide
   one or multiple group prefixes to specific clients, e.g., site scoped
   addresses for clients that are inside the site.  Clients could be
   identified by their IP address provided that clients are required to
   send Init messages, and they receive an unpredictable Session ID.
   See also

   As specified in Section 11.

   Clients should 3.5, a server must by default send at most one request per second.
   Servers should perform rate limiting, to guard against this protocol
   being used for DoS attacks.  The server should for a given
   client, respond to at most one Echo Request message per second.  A
   leaky bucket algorithm is suggested, where the rate can be higher for
   a few seconds, but the average rate should by default be limited to a
   message per client per second.  Server implementations should provide
   administrative control of which client IP addresses to serve, and may
   also allow certain clients to perform more rapid requests.
   Implementers of applications/tools using this protocol should
   consider the UDP guidelines [5], in particular if clients are to
   send, or servers are to accept, requests at rates exceeding one per
   second. Echo Requests.

   If higher rates are allowed a server uses different policies for specific different IP addresses, then it
   should require clients to send Init messages and the return an
   unpredictable Session ID option should be used to help prevent spoofing.  This is an
   absolute requirement if exceeding the default rate limit.  See
   specification in Section 11.

9. 3.5.

7.  Acknowledgments

   The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and
   Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source
   Specific Multicast, and also the Internet Draft
   draft-sarac-mping-00.txt.  Mickael Hoerdt has contributed with
   several ideas.  Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave
   Thaler have contributed in different ways to the implementation of
   the ssmping tools at [4]. [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, Tony Ballardie, Bill Cerveny, Toerless
   Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui,
   Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola,
   Trond Skjesol and Cao Wei for reviewing and providing feedback on
   this draft.  In particular Hugo, Gorry and Bharat have provided lots
   of input on several revisions of the draft.

10.

8.  IANA Considerations

   IANA is requested to provide assign a well-known UDP port number user-port in the range 1024-49151
   for use by this protocol, and also to provide registries for message
   and option types.  The string "[TBD]" in this document should be
   replaced with the assigned port.

   There should be a message types registry.  Message types are in the
   range 0-255.  Message types 0-191 require specification (an RFC or
   other permanent and readily available reference), while types 192-255
   are for experimental use and are not registered.  The registry should
   include the messages defined in Section 5. 3.4.  A message specification
   must describe the behaviour with known option types as well as the
   default behaviour with unknown ones.

   There should also be an option type registry.  Option types 0-49151
   require specification (an RFC or other permanent and readily
   available reference), while types 49152-65535 are for experimental
   use and are not registered.  The registry should include the options
   defined in Section 3.2.  An option specification must describe how
   the option may be used with the known message types.  This includes
   which message types the option may be used with.

   The initial registry definitions could be are 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.

9.  Security Considerations

   There are some security issues to consider.  One is that a host may
   send a request an Echo Request with an IP source address of another host, and
   make an arbitrary multicast ping server on the Internet send packets
   to this other host.  This behaviour is fairly harmless.  The worst
   case is if the host receiving the unicast replies Echo Replies also happen happens
   to be joined to the multicast group used.  In this case, there would
   be an amplification effect where the host receives twice as many
   replies as there are requests sent.  See below for how spoofing can
   be prevented.

   For ASM (Any-Source Multicast) a host could also make a multicast
   ping server send multicast packets to a group that is used for
   something else, possibly disturbing other uses of that group.
   However, server implementations should allow administrators to
   restrict which groups a server responds to.  The main concern is
   bandwidth.  Since there is a well-known port, it
   should not be received by other applications.  Due to this,  To limit the bandwidth used, a server
   on the Internet SHOULD MUST by default
   perform rate limiting. limiting, responding to at most one Echo Request per
   second.

   In order to help prevent spoofing, a server SHOULD require the client
   to send an Init message, and return an unpredictable Session ID in
   the response.  The ID should be associated with the IP address and
   have a limited lifetime.  The server SHOULD then only respond to Echo
   Request messages that have a valid Session ID associated with the
   source IP address of the Echo Request.

   Server implementations should allow administrators to restrict which
   groups a server responds to, and also perform rate limiting.  This is
   discussed in Section 8.

12.

10.  References

12.1.

10.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
        September 1981.

   [3]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
        August 1980.

   [3]

   [4]  "IANA, Address Family Numbers",
        <http://www.iana.org/assignments/address-family-numbers>.

12.2.

10.2.  Informative References

   [4]

   [5]  "ssmping implementation",
        <http://www.venaas.no/multicast/ssmping/>.

   [5]

   [6]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
        Application Designers", draft-ietf-tsvwg-udp-guidelines-11 (work
        in progress), October BCP 145, RFC 5405, November 2008.

Author's Address

   Stig Venaas
   UNINETT
   Trondheim  NO-7465
   Norway

   Email: venaas@uninett.no

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.