idnits 2.17.1 draft-ietf-mboned-ssmping-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 844. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 868. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 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 Response message back with version set to 2. Client ID and Sequence Number options SHOULD be echoed if present. It SHOULD not include any other options. A client receiving a response with a version other than 2, MUST (unless it supports the particular version), stop sending requests to the server. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'TBD' on line 106 -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft UNINETT 4 Intended status: Standards Track November 3, 2008 5 Expires: May 7, 2009 7 Multicast Ping Protocol 8 draft-ietf-mboned-ssmping-06 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 7, 2009. 35 Abstract 37 The Multicast Ping Protocol specified in this document allows for 38 checking whether an endpoint can receive multicast, both Source- 39 Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also 40 be used to obtain additional multicast related information like 41 multicast tree setup time etc. This protocol is based on an 42 implementation of tools called ssmping and asmping. 44 Requirements Language 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [1]. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6 57 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10 58 5. Message types and options . . . . . . . . . . . . . . . . . . 11 59 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 13 60 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 61 8. Recommendations for Implementers . . . . . . . . . . . . . . . 15 62 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 66 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 67 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 Intellectual Property and Copyright Statements . . . . . . . . . . 20 71 1. Introduction 73 The Multicast Ping Protocol specified in this document allows for 74 checking multicast connectivity. In addition to checking reception 75 of multicast (SSM or ASM), the protocol can provide related 76 information like multicast tree setup time, the number of hops the 77 packets have traveled, as well as packet delay and loss. This 78 functionality resembles, in part, the ICMP Echo Request/Reply 79 mechanism, but uses UDP RFC 768 [2] and requires both a client and a 80 server implementing this protocol. Intermediate routers are not 81 required to support this protocol. They forward Protocol Messages 82 and data traffic as usual. 84 The protocol here specified is based on the actual implementation of 85 the ssmping and asmping tools [4] which are widely used by the 86 Internet community to conduct multicast connectivity tests. 88 2. Architecture 90 Before describing the protocol in detail, we provide a brief overview 91 of how the protocol may be used and what information it may provide. 92 The typical protocol usage is as follows: A server runs continuously 93 to serve requests from clients. A client can test the multicast 94 reception from this server, provided it knows a unicast address of 95 the server. It will then send a unicast message to the server asking 96 for a group to use. Optionally the user may have requested a 97 specific group or scope, in which case the client will ask for a 98 group matching the user's request. The server will respond with a 99 group to use, or an error if no group is available. Next, for ASM, 100 the client joins an ASM group G, while for SSM it joins a channel 101 (S,G). Here G is the group specified by the server, and S is the 102 unicast address used to reach the server. 104 After joining the channel, the client unicasts multicast ping 105 requests to the server. The requests are sent using UDP with 106 destination port set to the standardised multicast ping port [TBD]. 107 The requests are sent periodically, e.g., once per second, to the 108 server. The requests contain a sequence number, and typically a 109 timestamp. The requests are echoed by the server, except the server 110 may add a few options. For each request, the server sends two 111 replies. One reply is unicast back to the source IP address and 112 source UDP port of the request, while another is multicast to the 113 requested multicast group G and the source UDP port of the request. 114 Both replies are sent from the same port on which the request was 115 received. The server should specify the TTL used for both the 116 unicast and multicast messages (we recommend at least 64) by 117 including a TTL option; allowing the client to compute the number of 118 hops. The client should leave the channel/group when it has finished 119 its measurements. 121 By use of this protocol, a client can obtain information about 122 several multicast delivery characteristics. First, by receiving 123 unicast replies, it can verify that the server is receiving the 124 unicast requests, is operational and responding. Hence, provided 125 that the client receives unicast replies, a failure to receive 126 multicast indicates either a multicast problem or a multicast 127 administrative restriction. If it does receive multicast, it knows 128 not only that it can receive; it may also estimate the amount of time 129 it took to establish the multicast tree (at least if it is in the 130 range of seconds), whether there are packet drops, and the length and 131 variation of Round Trip Times (RTT). For unicast, the RTT is the 132 time from when the unicast request is sent to when the reply is 133 received. The measured multicast RTT also references the client's 134 unicast request. By use of the TTL option specifying the TTL of the 135 replies when they are originated, the client can also determine the 136 number of router hops it is from the source. Since similar 137 information is obtained in the unicast replies, the host may compare 138 its multicast and unicast results and is able to check for 139 differences in the number of hops, RTT, etc. The number of multicast 140 hops and changes in the number of hops over time, may also reveal 141 details about the multicast tree and multicast tree changes. 142 Provided that the server sends the unicast and multicast replies 143 nearly simultaneously, the client may also be able to measure the 144 difference in one way delay for unicast and multicast on the path 145 from server to client, and also differences in delay. Servers may 146 optionally specify a timestamp. This may be useful since the unicast 147 and multicast replies can not be sent simultaneously (the delay 148 depending on the host's operating system and load). 150 3. Protocol specification 152 There are four different message types. There are Echo Request and 153 Echo Reply messages used for the actual measurements; there is an 154 Init message that SHOULD be used to initialise a ping session and 155 negotiate which group to use; and finally a Server Response message 156 that is mainly used in response to the Init message. The messages 157 MUST always be in network byte order. UDP checksums MUST always be 158 used. 160 The messages share a common format: one octet specifying the message 161 type, followed by a number of options in TLV (Type, Length and Value) 162 format. This makes the protocol easily extendible. The Init message 163 generally contains some prefix options asking the server for a group 164 from one of the specified prefixes. The server responds with a 165 Server Response message that contains the group address to use, or 166 possibly prefix options describing what multicast groups the server 167 may be able to provide. For an Echo Request the client generally 168 includes a number of options, and a server MAY simply echo the 169 contents (only changing the message type) without inspecting the 170 options if it does not support any options. This might be true for a 171 simple Multicast Ping Protocol server. However, the server SHOULD 172 add a TTL option, and there are other options that a server 173 implementation MAY support, e.g., the client may ask for certain 174 information or a specific behaviour from the server. The Echo 175 Replies (one unicast and one multicast) MUST first contain the exact 176 options from the request (in the same order), and then, immediately 177 following, any options appended by the server. A server MUST NOT 178 process unknown options, but they MUST still be included in the Echo 179 Reply. A client MUST ignore any unknown options. 181 The size of the protocol messages is generally smaller than the Path 182 MTU and fragmentation is not a concern. There may however be cases 183 where the Path MTU is really small, or that a client sends large 184 requests in order to verify that it can receive fragmented multicast 185 datagrams. This document does not specify whether Path MTU Discovery 186 should be performed, etc. A possible extension could be an option 187 where a client requests Path MTU Discovery and receives the current 188 Path MTU from the server. 190 This document defines a number of different options. Some options do 191 not require processing by servers and are simply returned unmodified 192 in the reply. There are, however, other client options that the 193 server may care about, and also server options that may be requested 194 by a client. Unless otherwise specified, an option MUST NOT be used 195 multiple times in the same message. 197 3.1. Option format 199 All options are TLVs formatted as specified below. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Type | Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Value | 207 | . | 208 | . | 209 | . | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Type (2 octets) specifies the option. The different options are 213 defined below. 215 Length (2 octets) specifies the length of the value field. Depending 216 on the option type, it can be from 0 to 65535. 218 Value. The value must always be of the specified length. See the 219 respective option definitions for possible values. If the length is 220 0, the value field is not included. 222 3.2. Defined Options 224 This document defines the following options: Version (0), Client ID 225 (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), 226 Option Request Option (5), Server Information (6), TTL (9), Multicast 227 Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and 228 8 are reserved. The options are defined below. 230 Version, type 0 232 Length MUST be 1. This option MUST always be included in all 233 messages, and the value MUST be set to 2 (in decimal). Note 234 that there are implementations of older revisions of this 235 protocol that only partly follow this specification. They can 236 be regarded as version 1 and do not use this option. If a 237 server receives a message with a version other than 2 (or 238 missing), the server SHOULD (unless it supports the particular 239 version) send a Response message back with version set to 2. 240 Client ID and Sequence Number options SHOULD be echoed if 241 present. It SHOULD not include any other options. A client 242 receiving a response with a version other than 2, MUST (unless 243 it supports the particular version), stop sending requests to 244 the server. 246 Client ID, type 1 248 Length MUST be non-zero. A client SHOULD always include this 249 option in all messages (both Init and Request). The client may 250 use any value it likes to be able to detect whether a reply is 251 a reply to its Init/Request or not. A server should treat this 252 as opaque data, and MUST echo this option back in the reply if 253 present (both Server Response and Reply). The value might be a 254 process ID, perhaps process ID combined with an IP address 255 because it may receive multicast responses to queries from 256 other clients. It is left to the client implementer how to 257 make use of this option. 259 Sequence Number, type 2 261 Length MUST be 4. A client MUST always include this in Request 262 messages and MUST NOT include it in Init messages. A server 263 replying to a Request message MUST copy it into the Reply (or 264 Server Response message on error). This contains a 32 bit 265 sequence number. The values would typically start at 1 and 266 increase by one for each request in a sequence. 268 Client Timestamp, type 3 270 Length MUST be 8 bytes. A client SHOULD include this in 271 Request messages and MUST NOT include it in Init messages. A 272 server replying to a Request message MUST copy it into the 273 Reply. The timestamp specifies the time when the Request 274 message is sent. The first 4 bytes specify the number of 275 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 276 bytes specify the number of microseconds since the last second 277 since the Epoch. 279 Multicast Group, type 4 281 Length MUST be greater than 2. It MAY be used in Server 282 Response messages to tell the client what group to use in 283 subsequent Request messages. It MUST be used in Request 284 messages to tell the server what group address to respond to 285 (this group would typically be previously obtained in a Server 286 Response message). It MUST be used in Reply messages (copied 287 from the Request message). It MUST NOT be used in Init 288 messages. The format of the option value is as below. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Address Family | Multicast group address... | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 296 The address family is a value 0-65535 as assigned by IANA for 297 Internet Address Families [3]. This is followed by the group 298 address. Length of the option value will be 6 for IPv4, and 18 299 for IPv6. 301 Option Request Option, type 5 303 Length MUST be greater than 1. This option MAY be used in 304 client messages (Init and Request messages). A server MUST NOT 305 send this option, except that if it is present in a Request 306 message, the server MUST echo it in replies (Reply message) to 307 the Request. This option contains a list of option types for 308 options that the client is requesting from the server. Support 309 for this option is optional for both clients and servers. The 310 length of this option will be a non-zero even number, since it 311 contains one or more option types that are two octets each. 312 The format of the option value is as below. 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Option Type | Option Type | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | ..... | 321 This option might be used by the client to ask the server to 322 include options like Timestamp or Server Information. A client 323 MAY request Server Information in Init messages; it MUST NOT 324 request it in other messages. A client MAY request a Timestamp 325 in Request messages; it MUST NOT request it in other messages. 326 Subject to enforcing the above restrictions, a server 327 supporting this option SHOULD include the requested options in 328 responses (Reply messages) to the Request containing the Option 329 Request Option. The server may according to implementation or 330 local configuration, not necessarily include all the requested 331 options, or possibly none. Any options included are appended 332 to the echoed options, similar to other options included by the 333 server. 335 Server Information, type 6 337 Length MUST be non-zero. It MAY be used in Server Response 338 messages and MUST NOT be used in other messages. Support for 339 this option is optional. A server supporting this option 340 SHOULD add it in Server Response messages if and only if 341 requested by the client. The value is a UTF-8 string that 342 might contain vendor and version information for the server 343 implementation. It may also contain information on which 344 options the server supports. An interactive client MAY support 345 this option, and SHOULD then allow a user to request this 346 string and display it. 348 Reserved, type 7 350 This option code value was used by early implementations for an 351 option that is now deprecated. This option should no longer be 352 used. Clients MUST NOT use this option. Servers MUST treat it 353 as an unknown option (not process it if received, but if 354 received in a Request message, it MUST be echoed in the Reply 355 message). 357 Reserved, type 8 359 This option code value was used by early implementations for an 360 option that is now deprecated. This option should no longer be 361 used. Clients MUST NOT use this option. Servers MUST treat it 362 as an unknown option (not process it if received, but if 363 received in a Request message, it MUST be echoed in the Reply 364 message). 366 TTL, type 9 368 Length MUST be 1. This option contains a single octet 369 specifying the TTL of a Reply message. Every time a server 370 sends a unicast or multicast Reply message, it SHOULD include 371 this option specifying the TTL. This is used by clients to 372 determine the number of hops the messages have traversed. It 373 MUST NOT be used in other messages. A server SHOULD specify 374 this option if it knows what the TTL of the Reply will be. In 375 general the server can specify a specific TTL to the host 376 stack. Note that the TTL is not necessarily the same for 377 unicast and multicast. 379 Multicast Prefix, type 10 381 Length MUST be greater than 2. It MAY be used in Init messages 382 to request a group within the prefix(es), it MAY be used in 383 Server Response messages to tell the client what prefix(es) it 384 may try to obtain a group from. It MUST NOT be used in 385 Request/Reply messages. Note that this option MAY be included 386 multiple times to specify multiple prefixes. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Address Family | Prefix Length |Partial address| 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 394 The address family is a value 0-65535 as assigned by IANA for 395 Internet Address Families [3]. This is followed by a prefix 396 length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special 397 'wildcard' use discussed below), and finally a group address. 398 For any family, prefix length 0 means that any multicast 399 address from that family is acceptable. This is what we call 400 'wildcard'. The group address need only contain enough octets 401 to cover the prefix length bits (i.e., the group address would 402 have to be 3 octets long if the prefix length is 17-24, and 403 there need be no group address for the wildcard with prefix 404 length 0). Any bits past the prefix length MUST be ignored. 405 For IPv4, the option value length will be 4-7, while for IPv6, 406 it will be 4-19, and for the wildcard, it will be 3. 408 Session ID, type 11 410 Length MUST be non-zero. A server SHOULD include this in 411 Server Response and Reply messages. If a client receives this 412 option in a message, the client MUST echo the Session ID option 413 in subsequent Request messages, with the exact same value, 414 until the next message is received from the server. If the 415 next message from the server has no Session ID or a new Session 416 ID value, the client should do the same, either not use the 417 Session ID, or use the new value. The Session ID may help the 418 server in keeping track of clients and possibly manage per 419 client state. The value of a new Session ID should be chosen 420 pseudo randomly so that it is hard to predict. This can be 421 used to prevent spoofing of the source address of Request 422 messages, see the Security Considerations for details. 424 Server Timestamp, type 12 426 Length MUST be 8 bytes. A server supporting this option, 427 SHOULD include it in Reply messages, if requested by the 428 client. The timestamp specifies the time when the Reply 429 message is sent. The first 4 bytes specify the number of 430 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 431 bytes specify the number of microseconds since the last second 432 since the Epoch. 434 4. Packet Format 436 The format of all messages is a one octet message type, directly 437 followed by a variable number of options. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type | Options ... | 443 +-+-+-+-+-+-+-+-+ . | 444 | . | 445 | . | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ..... 448 There are four message types defined. Type 81 (the character Q in 449 ASCII) specifies an Echo Request (Query). Type 65 (the character A 450 in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I 451 in ASCII) is an Init message, and type 83 (the character S in ASCII) 452 is a Server Response message. 454 The options directly follow the type octet and are not aligned in any 455 way (no spacing or padding), i.e., options might start at any octet 456 boundary. The option format is specified above. 458 5. Message types and options 460 There are four message types defined. We will now describe each of 461 the message types and which options they may contain. 463 Init, type 73 465 This message is sent by a client to request information from a 466 server. It is mainly used for requesting a group address, but 467 it may also be used to check which group prefixes the server 468 may provide groups from, or other server information. It MUST 469 include a Version option, and SHOULD include a Client ID. It 470 MAY include Option Request and Multicast Prefix Options. This 471 message is a request for a group address if and only if it 472 contains Multicast Prefix options. If multiple Prefix options 473 are included, they should be in prioritised order. I.e., the 474 server will consider the prefixes in the order they are 475 specified, and if it finds a group for a prefix, it will only 476 return that one group, not considering the remaining prefixes. 478 Server Response, type 83 480 This message is sent by a server. Either as a response to an 481 Init, or in response to a Request. When responding to Init, it 482 may provide the client with a multicast group (if requested by 483 the client), or it may provide other server information. In 484 response to a Request, the message tells the client to stop 485 sending Requests. The Version option MUST always be included. 486 Client ID and Sequence Number options are echoed if present in 487 the client message. When providing a group to the client, it 488 includes a Multicast Group option. It SHOULD include Server 489 Information and Prefix options if requested. 491 Echo Request, type 81 493 This message is sent by a client, asking the server to send 494 unicast and multicast replies. It MUST include Version, 495 Sequence Number and Multicast Group options. If the last 496 message (if any) received from the server contained a Session 497 ID, then this MUST also be included. It SHOULD include Client 498 ID and Client Timestamp options. It MAY include an Option 499 Request option. 501 Echo Reply, type 65 503 This message is sent by a server in response to an Echo Request 504 message. This message is always sent in pairs, one as unicast 505 and one as multicast. The contents of the messages are mostly 506 the same. The server echoes most of the options from the Echo 507 Request (any options in the Request that are unsupported by the 508 server, are always echoed). The only option that may be 509 present in the Request which is not always echoed, is the 510 Session ID option. In most cases the server would echo it, but 511 the server may also change or omit it. The two Reply messages 512 SHOULD both contain a TTL option (not necessarily equal), and 513 both SHOULD also contain Server Timestamps (not necessarily 514 equal) when requested. 516 For the reader's convenience we provide the matrix below, showing 517 what options can go in what messages. 519 Option / Message Type | Init | Server Response | Request | Reply | 520 -----------------------------------------------------------------+ 521 Version (0) | MUST | ECHO | MUST | ECHO | 522 Client ID (1) |SHOULD| ECHO | SHOULD | ECHO | 523 Sequence Number (2) | NOT | ECHO | MUST | ECHO | 524 Client Timestamp (3) | NOT | NOT | SHOULD | ECHO | 525 Multicast Group (4) | NOT | MAY | MUST | ECHO | 526 Option Request (5) | MAY | NOT | MAY | ECHO | 527 Server Information (6)| NOT | RQ | NOT | NOT | 528 Reserved (7) | NOT | NOT | NOT | ECHO | 529 Reserved (8) | NOT | NOT | NOT | ECHO | 530 TTL (9) | NOT | NOT | NOT |SHOULD | 531 Multicast Prefix (10) | MAY | MAY | NOT | NOT | 532 Session ID (11) | NOT | MAY | ECHO | MAY | 533 Server Timestamp (12) | NOT | NOT | NOT | RQ | 535 NOT means that the option MUST NOT be included. ECHO for a server 536 means that if the option is specified by the client, then the server 537 MUST echo the option in the response, with the exact same option 538 value. ECHO for a client means that it MUST echo the option it got 539 in the last message from the server in any subsequent messages it 540 sends. RQ means that the server SHOULD include the option in the 541 response, when requested by the client using the Option Request 542 option. 544 6. Client Behaviour 546 We will consider how a typical interactive client using the above 547 protocol would behave. A client need only require a user to specify 548 the unicast address of the server. It can then send an Init message 549 with a prefix option containing the desired address family and zero 550 prefix length (wildcard entry). The server is then free to decide 551 which group, from the specified family, it should return. A client 552 may also allow a user to specify group address(es) or prefix(es) (for 553 IPv6, the user may only be required to specify a scope or an RP 554 address, from which the client can construct the desired prefix, 555 possibly embedded-RP). From this the client can specify one or more 556 prefix options in an Init message to tell the server which address it 557 would prefer. If the user specifies a group address, that can be 558 encoded as a prefix of maximal length (e.g., 32 for IPv4). The 559 prefix options are in prioritised order, i.e., the client should put 560 the most preferred prefix first. 562 If the client receives a Server Response message containing a group 563 address it can start sending Request messages, see the next 564 paragraph. If there is no group address option, it would typically 565 exit with an error message. The server may have included some prefix 566 options in the Server Response. The client may use this to provide 567 the user some feedback on what prefixes or scopes are available. 569 Assuming the client got a group address in a Server Response, it can 570 start pinging. Before it does that, it should let the user know 571 which group is being used. Normally, a client should send at most 572 one ping request per second. When sending ping Requests, the client 573 must always include the group option. If the last message from the 574 server contained a Session ID, then it must also include that with 575 the same value. Typically it would receive a Session ID in a Server 576 Response together with the group address, and then the ID would stay 577 the same during the entire ping sequence. However, if for instance 578 the server process is restarted, it may still be possible to continue 579 pinging but the Session ID may be changed by the server. Hence a 580 client implementation must always use the last Session ID it 581 received, and not necessarily the one from the Server Response 582 message. If a client receives a Server Response message in response 583 to a Request message (that is, a Server Response message containing a 584 sequence number), this means there is an error and it should stop 585 sending Requests. This may for instance happen after server restart. 587 The client may allow the user to request server information. If the 588 user requests server information, the client can send an Init message 589 with no prefix options, but with an Option Request Option, requesting 590 the server to return a Server Information option. The server will 591 return server information if supported, and it may also return a list 592 of prefixes it supports. It will however not return a group address. 593 The client may also try to obtain only a list of prefixes by sending 594 an Init message with no prefixes and not requesting any specific 595 options. 597 Note that a client may pick a multicast group and send Request 598 messages without first going through the Init - Server Response 599 negotiation. If this is supported by the server and the server is 600 okay with the group used, the server can then send Reply messages as 601 usual. If the server is not okay, it will send a Server Response 602 telling the client to stop. 604 7. Server Behaviour 606 We will consider how a typical server using the above protocol would 607 behave. First we consider how to respond to Init messages. If the 608 Init message contains prefix options, the server should look at them 609 in order and see if it can assign a multicast address from the given 610 prefix. The server would be configured, possibly have a default, 611 specifying which groups it can offer. It may have a large pool just 612 picking a group at random, possibly choose a group based on hashing 613 of the client's IP address or identifier, or just use a fixed group. 614 A server could possibly decide whether to include site scoped group 615 ranges based on the client's IP address. It is left to the server to 616 decide whether it should allow the same address to be used 617 simultaneously by multiple clients. If the server finds a suitable 618 group address, it returns this in a group option in a Server Response 619 message. The server should additionally include a Session ID. This 620 may help the server if it is to keep some state, for instance for 621 making sure the client uses the group it got assigned. A good 622 Session ID would be a pseudo random byte string that is hard to 623 predict. If the server cannot find a suitable group address, or if 624 there were no prefixes in the Init message, it may send a Server 625 Response message containing prefix options listing what prefixes may 626 be available to the client. Finally, if the Init message requests 627 the Server Information option, it should include that. 629 When the server receives a Request message, it may first check that 630 the group address and Session ID (if provided) are valid. If the 631 server is satisfied, it will send a unicast Reply message back to the 632 client, and also a multicast Reply message to the group address. The 633 Reply messages contain the exact options and in the same order, as in 634 the Request, and after that the server adds a TTL option and 635 additional options if needed. E.g., it may add a timestamp if 636 requested by the client. If the server is not happy with the Request 637 (bad group address or Session ID, request is too large etc), it may 638 send a Server Response message asking the client to stop. This 639 Server Response must echo the sequence number from the Request. This 640 Server Response may contain group prefixes from which a client can 641 try to request a group address. The unicast and multicast Reply 642 messages have identical UDP payload apart from possibly TTL and 643 timestamp option values. 645 Note that the server may receive Request messages with no prior Init 646 message. This may happen when the server restarts or if a client 647 sends a Request with no prior Init message. The server may go ahead 648 and respond if it is okay with the group used. In the responses it 649 may add a Session ID which will then be in later requests from the 650 client. If the group is not okay, the server sends back a Server 651 Response. The Response is just as if it got an Init message with no 652 prefixes. If the server adds or modifies the SessionID in replies, 653 it must use the exact same SessionID in the unicast and multicast 654 replies. 656 8. Recommendations for Implementers 658 The protocol as specified is fairly flexible and leaves a lot of 659 freedom for implementers. In this section we present some 660 recommendations. 662 Server administrators should be able to configure one or multiple 663 group prefixes in a server implementation. When deploying servers on 664 the Internet and in other environments, the server administrator 665 should be able to restrict the server to respond to only a few 666 multicast groups which should not be currently used by multicast 667 applications. A server implementation should also provide 668 flexibility for an administrator to apply various policies to provide 669 one or multiple group prefixes to specific clients, e.g., site scoped 670 addresses for clients that are inside the site. Clients could be 671 identified by their IP address provided that clients are required to 672 send Init messages, and they receive an unpredictable Session ID. 673 See also Section 11. 675 Clients should by default send at most one request per second. 676 Servers should perform rate limiting, to guard against this protocol 677 being used for DoS attacks. The server should for a given client, 678 respond to at most one Request message per second. A leaky bucket 679 algorithm is suggested, where the rate can be higher for a few 680 seconds, but the average rate should by default be limited to a 681 message per client per second. Server implementations should provide 682 administrative control of which client IP addresses to serve, and may 683 also allow certain clients to perform more rapid requests. 684 Implementers of applications/tools using this protocol should 685 consider the UDP guidelines [5], in particular if clients are to 686 send, or servers are to accept, requests at rates exceeding one per 687 second. If higher rates are allowed for specific IP addresses, then 688 Init messages and the Session ID option should be used to help 689 prevent spoofing. See Section 11. 691 9. Acknowledgments 693 The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and 694 Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source 695 Specific Multicast, and also the Internet Draft 696 draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with 697 several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave 698 Thaler have contributed in different ways to the implementation of 699 the ssmping tools at [4]. Many people in communities like TERENA, 700 Internet2 and the M6Bone have used early implementations of ssmping 701 and provided feedback that have influenced the current protocol. 702 Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Alfred 703 Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil 704 Sarac, Pekka Savola, Trond Skjesol and Cao Wei for reviewing and 705 providing feedback on this draft. In particular Hugo, Gorry and 706 Bharat have provided lots of input on several revisions of the draft. 708 10. IANA Considerations 710 IANA is requested to provide a well-known UDP port number for use by 711 this protocol, and also to provide registries for message and option 712 types. 714 There should be a message types registry. Message types are in the 715 range 0-255. Message types 0-191 require specification (an RFC or 716 other permanent and readily available reference), while types 192-255 717 are for experimental use and are not registered. The registry should 718 include the messages defined in Section 5. A message specification 719 must describe the behaviour with known option types as well as the 720 default behaviour with unknown ones. 722 There should also be an option type registry. Option types 0-49151 723 require specification (an RFC or other permanent and readily 724 available reference), while types 49152-65535 are for experimental 725 use and are not registered. The registry should include the options 726 defined in Section 3.2. An option specification must describe how 727 the option may be used with the known message types. This includes 728 which message types the option may be used with. 730 The initial registry definitions could be as follows: 732 Multicast Ping Protocol Parameters: 734 Registry Name: Multicast Ping Protocol Message Types 735 Reference: [this doc] 736 Registration Procedures: Specification Required 738 Registry: 739 Type Name Reference 740 ----------- ------------------------------------ ---------- 741 65 Echo Reply [this doc] 742 73 Init [this doc] 743 81 Echo Request [this doc] 744 83 Server Response [this doc] 745 192-255 Experimental 747 Registry Name: Multicast Ping Protocol Option Types 748 Reference: [this doc] 749 Registration Procedures: Specification Required 751 Registry: 752 Type Name Reference 753 ----------- ------------------------------------ ---------- 754 0 Version [this doc] 755 1 Client ID [this doc] 756 2 Sequence Number [this doc] 757 3 Client Timestamp [this doc] 758 4 Multicast Group [this doc] 759 5 Option Request Option [this doc] 760 6 Server Information [this doc] 761 7 Reserved [this doc] 762 8 Reserved [this doc] 763 9 TTL [this doc] 764 10 Multicast Prefix [this doc] 765 11 Session ID [this doc] 766 12 Server Timestamp [this doc] 767 49152-65535 Experimental 769 11. Security Considerations 771 There are some security issues to consider. One is that a host may 772 send a request with an IP source address of another host, and make an 773 arbitrary multicast ping server on the Internet send packets to this 774 other host. This behaviour is fairly harmless. The worst case is if 775 the host receiving the unicast replies also happen to be joined to 776 the multicast group used. In this case, there would be an 777 amplification effect where the host receives twice as many replies as 778 there are requests sent. See below for how spoofing can be 779 prevented. 781 For ASM (Any-Source Multicast) a host could also make a multicast 782 ping server send multicast packets to a group that is used for 783 something else, possibly disturbing other uses of that group. The 784 main concern is bandwidth. Since there is a well-known port, it 785 should not be received by other applications. Due to this, a server 786 on the Internet SHOULD perform rate limiting. 788 In order to help prevent spoofing, a server SHOULD require the client 789 to send an Init message, and return an unpredictable Session ID in 790 the response. The ID should be associated with the IP address and 791 have a limited lifetime. The server SHOULD then only respond to 792 Request messages that have a valid Session ID associated with the 793 source IP address of the Request. 795 Server implementations should allow administrators to restrict which 796 groups a server responds to, and also perform rate limiting. This is 797 discussed in Section 8. 799 12. References 801 12.1. Normative References 803 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 804 Levels", BCP 14, RFC 2119, March 1997. 806 [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 807 August 1980. 809 [3] "IANA, Address Family Numbers", 810 . 812 12.2. Informative References 814 [4] "ssmping implementation", 815 . 817 [5] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for 818 Application Designers", draft-ietf-tsvwg-udp-guidelines-11 (work 819 in progress), October 2008. 821 Author's Address 823 Stig Venaas 824 UNINETT 825 Trondheim NO-7465 826 Norway 828 Email: venaas@uninett.no 830 Full Copyright Statement 832 Copyright (C) The IETF Trust (2008). 834 This document is subject to the rights, licenses and restrictions 835 contained in BCP 78, and except as set forth therein, the authors 836 retain all their rights. 838 This document and the information contained herein are provided on an 839 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 840 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 841 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 842 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 843 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 844 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 846 Intellectual Property 848 The IETF takes no position regarding the validity or scope of any 849 Intellectual Property Rights or other rights that might be claimed to 850 pertain to the implementation or use of the technology described in 851 this document or the extent to which any license under such rights 852 might or might not be available; nor does it represent that it has 853 made any independent effort to identify any such rights. Information 854 on the procedures with respect to rights in RFC documents can be 855 found in BCP 78 and BCP 79. 857 Copies of IPR disclosures made to the IETF Secretariat and any 858 assurances of licenses to be made available, or the result of an 859 attempt made to obtain a general license or permission for the use of 860 such proprietary rights by implementers or users of this 861 specification can be obtained from the IETF on-line IPR repository at 862 http://www.ietf.org/ipr. 864 The IETF invites any interested party to bring to its attention any 865 copyrights, patents or patent applications, or other proprietary 866 rights that may cover technology that may be required to implement 867 this standard. Please address the information to the IETF at 868 ietf-ipr@ietf.org.