idnits 2.17.1 draft-ietf-mboned-ssmping-07.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 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 906. 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 -- 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 (December 2, 2008) is 5622 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 114 -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Obsolete informational reference (is this intentional?): RFC 5405 (ref. '6') (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 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 December 2, 2008 5 Expires: June 5, 2009 7 Multicast Ping Protocol 8 draft-ietf-mboned-ssmping-07 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 June 5, 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 such as 41 multicast tree setup time. 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 . . . . . . . . . . . . . . . . . . . . 5 55 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 56 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6 57 3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 11 58 3.4. Message Types and Options . . . . . . . . . . . . . . . . 11 59 3.5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 13 60 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 61 5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 15 62 6. Recommendations for Implementers . . . . . . . . . . . . . . . 16 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 Intellectual Property and Copyright Statements . . . . . . . . . . 21 72 1. Introduction 74 The Multicast Ping Protocol specified in this document allows for 75 checking multicast connectivity. In addition to checking reception 76 of multicast (SSM or ASM), the protocol can provide related 77 information such as multicast tree setup time, the number of hops the 78 packets have traveled, as well as packet delay and loss. This 79 functionality resembles, in part, the ICMP Echo Request/Reply 80 mechanism [2], but uses UDP [3] and requires both a client and a 81 server implementing this protocol. Intermediate routers are not 82 required to support this protocol. They forward Protocol Messages 83 and data traffic as usual. 85 This protocol is based on the current implementation of the ssmping 86 and asmping tools [5] which are widely used by the Internet community 87 to conduct multicast connectivity tests. 89 2. Architecture 91 Before describing the protocol in detail, we provide a brief overview 92 of how the protocol may be used and what information it may provide. 94 The typical protocol usage is as follows: 96 A server runs continuously to serve requests from clients. A 97 client has somehow learned the unicast address of the server and 98 tests the multicast reception from the server. 100 The client application will then send a unicast message to the 101 server asking for a group to use. Optionally a user may request a 102 specific group or scope, in which case the client will ask for a 103 group matching the user's request. The server will respond with a 104 group to use, or an error if no group is available. 106 Next, for ASM, the client joins an ASM group G, while for SSM it 107 joins a channel (S,G), where G is the multicast group address 108 specified by the server, and S is the unicast address used to 109 reach the server. 111 After joining the group/channel, the client unicasts multicast 112 ping requests to the server. The requests are sent using UDP with 113 the destination port set to the standardised multicast ping port 114 [TBD]. The requests are sent periodically, perhaps once per 115 second, to the server. These requests contain a sequence number, 116 and typically a timestamp. The requests are echoed by the server, 117 which may add a few options. 119 For each request, the server sends two replies. One reply is 120 unicast to the source IP address and source UDP port of the 121 requesting client. The other reply is multicast to the requested 122 multicast group G and the source UDP port of the requesting 123 client. 125 Both replies are sent from the same port on which the request was 126 received. The server should specify the TTL (IPv4 time-to-live or 127 IPv6 hop-count) used for both the unicast and multicast messages 128 (TTL of at least 64 is recommended) by including a TTL option. 129 This allows the client to compute the number of hops. The client 130 should leave the group/channel when it has finished its 131 measurements. 133 By use of this protocol, a client (or a user of the client) can 134 obtain information about several multicast delivery characteristics. 135 First, by receiving unicast replies, the client can verify that the 136 server is receiving the unicast requests, is operational and 137 responding. Hence, provided that the client receives unicast 138 replies, a failure to receive multicast indicates either a multicast 139 problem or a multicast administrative restriction. If it does 140 receive multicast, it knows not only that it can receive multicast 141 traffic, it may also estimate the amount of time it took to establish 142 the multicast tree (at least if it is in the range of seconds), 143 whether there are packet drops, and the length and variation of Round 144 Trip Times (RTT). 146 For unicast, the RTT is the time from when the unicast request is 147 sent to the time when the reply is received. The measured multicast 148 RTT also references the client's unicast request. By specifying the 149 TTL of the replies when they are originated, the client can also 150 determine the number of router hops it is from the source. Since 151 similar information is obtained in the unicast replies, the host may 152 compare its multicast and unicast results and is able to check for 153 differences such as the number of hops, and RTT. 155 The number of multicast hops and changes in the number of hops over 156 time may reveal details about the multicast tree and multicast tree 157 changes. Provided that the server sends the unicast and multicast 158 replies nearly simultaneously, the client may also be able to measure 159 the difference in one way delay for unicast and multicast on the path 160 from server to client, and also differences in delay. 162 Servers may optionally specify a timestamp. This may be useful since 163 the unicast and multicast replies can not be sent simultaneously (the 164 delay is dependent on the host's operating system and load). 166 3. Protocol Specification 168 There are four different message types. Echo Request and Echo Reply 169 messages are used for the actual measurements. An Init message 170 SHOULD be used to initialise a ping session and negotiate which group 171 to use. Finally a Server Response message that is mainly used in 172 response to the Init message. The messages MUST always be in network 173 byte order. UDP checksums MUST always be used. 175 The messages share a common format: one octet specifying the message 176 type, followed by a number of options in TLV (Type, Length and Value) 177 format. This makes the protocol easily extendible. 179 Message types in the range 0-191 are reserved and available for 180 allocation in an IANA Registry. Message types in the range 192-255 181 are not registered and are freely available for experimental use. 182 See Section 8. 184 The Init message generally contains some prefix options asking the 185 server for a group from one of the specified prefixes. The server 186 responds with a Server Response message that contains the group 187 address to use, or possibly prefix options describing what multicast 188 groups the server may be able to provide. 190 For an Echo Request the client generally includes a number of 191 options, and a server MAY simply echo the contents (only changing the 192 message type) without inspecting the options if it does not support 193 any options. This might be true for a simple Multicast Ping Protocol 194 server. However, the server SHOULD add a TTL option, and there are 195 other options that a server implementation MAY support, e.g., the 196 client may ask for certain information or a specific behaviour from 197 the server. The Echo Replies (one unicast and one multicast) MUST 198 first contain the exact options (excluding the Session ID option) 199 from the request (in the same order), and then, immediately 200 following, any options appended by the server. A server MUST NOT 201 process unknown options, but they MUST still be included in the Echo 202 Reply. A client MUST ignore any unknown options. 204 The size of the protocol messages is generally smaller than the Path 205 MTU and fragmentation is not a concern. There may however be cases 206 where the Path MTU is really small, or that a client sends large 207 requests in order to verify that it can receive fragmented multicast 208 datagrams. This document does not specify whether Path MTU Discovery 209 should be performed, etc. A possible extension could be an option 210 where a client requests Path MTU Discovery and receives the current 211 Path MTU from the server. 213 This document defines a number of different options. Some options do 214 not require processing by servers and are simply returned unmodified 215 in the reply. There are, however, other client options that the 216 server may care about, as well as server options that may be 217 requested by a client. Unless otherwise specified, an option MUST 218 NOT be used multiple times in the same message. 220 3.1. Option Format 222 All options are TLVs formatted as below. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type | Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Value | 230 | . | 231 | . | 232 | . | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Type (2 octets) specifies the option. 237 Length (2 octets) specifies the length of the value field. Depending 238 on the option type, it can be from 0 to 65535. 240 Value must always be of the specified length. See the respective 241 option definitions for possible values. If the length is 0, the 242 value field is not included. 244 3.2. Defined Options 246 This document defines the following options: Version (0), Client ID 247 (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), 248 Option Request Option (5), Server Information (6), TTL (9), Multicast 249 Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and 250 8 are reserved. The options are defined below. 252 Option types in the range 0-49151 are reserved and available for 253 allocation in an IANA Registry. Option types in the range 49152- 254 65535 are not registered and are freely available for experimental 255 use. See Section 8. 257 Version, type 0 259 Length MUST be 1. This option MUST always be included in all 260 messages, and for the current specified protocol this value 261 MUST be set to 2 (in decimal). Note that there are 262 implementations of older revisions of this protocol that only 263 partly follow this specification. They can be regarded as 264 version 1 and do not use this option. If a server receives a 265 message with a version other than 2 (or missing), the server 266 SHOULD (unless it supports the particular version) send a 267 Server Response message back with version set to 2. Client ID 268 and Sequence Number options SHOULD be echoed if present. The 269 server SHOULD NOT include any other options. A client 270 receiving a response with a version other than 2 MUST stop 271 sending requests to the server (unless it supports the 272 particular version). 274 Client ID, type 1 276 Length MUST be non-zero. A client SHOULD always include this 277 option in all messages (both Init and Echo Request). The 278 client may use any value it likes to detect whether a reply is 279 a reply to its Init/Echo Request or not. A server should treat 280 this as opaque data, and MUST echo this option back in the 281 reply if present (both Server Response and Echo Reply). The 282 value might be a process ID, perhaps process ID combined with 283 an IP address because it may receive multicast responses to 284 queries from other clients. It is left to the client 285 implementer how to use this option. 287 Sequence Number, type 2 289 Length MUST be 4. A client MUST always include this in Echo 290 Request messages and MUST NOT include it in Init messages. A 291 server replying to an Echo Request message MUST copy it into 292 the Echo Reply (or Server Response message on error). The 293 sequence number is a 32-bit integer. Values typically start at 294 1 and increase by one for each Echo Request in a sequence. 296 Client Timestamp, type 3 298 Length MUST be 8 bytes. A client SHOULD include this in Echo 299 Request messages and MUST NOT include it in Init messages. A 300 server replying to an Echo Request message MUST copy it into 301 the Echo Reply. The timestamp specifies the time when the Echo 302 Request message is sent. The first 4 bytes specify the number 303 of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 304 bytes specify the number of microseconds since the second 305 specified in the first 4 bytes. 307 Multicast Group, type 4 308 Length MUST be greater than 2. It MAY be used in Server 309 Response messages to tell the client what group to use in 310 subsequent Echo Request messages. It MUST be used in Echo 311 Request messages to tell the server what group address to 312 respond to (this group would typically be previously obtained 313 in a Server Response message). It MUST be used in Echo Reply 314 messages (copied from the Echo Request message). It MUST NOT 315 be used in Init messages. The format of the option value is as 316 below. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Address Family | Multicast group address... | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 324 The address family is a value 0-65535 as assigned by IANA for 325 Internet address families [4]. This is followed by the group 326 address. Length of the option value will be 6 for IPv4, and 18 327 for IPv6. 329 Option Request Option, type 5 331 Length MUST be greater than 1. This option MAY be used in 332 client messages (Init and Echo Request messages). A server 333 MUST NOT send this option, except that if it is present in an 334 Echo Request message, the server MUST echo it in replies (Echo 335 Reply message) to the Echo Request. This option contains a 336 list of option types for options that the client is requesting 337 from the server. Support for this option is optional for both 338 clients and servers. The length of this option will be a non- 339 zero even number, since it contains one or more option types 340 that are two octets each. The format of the option value is as 341 below. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Option Type | Option Type | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | ..... | 350 This option might be used by the client to ask the server to 351 include options like Timestamp or Server Information. A client 352 MAY request Server Information in Init messages; it MUST NOT 353 request it in other messages. A client MAY request a timestamp 354 in Echo Request messages; it MUST NOT request it in other 355 messages. Subject to enforcing the above restrictions, a 356 server supporting this option SHOULD include the requested 357 options in responses (Echo Reply messages) to the Echo Request 358 containing the Option Request Option. The server may, 359 according to implementation or local configuration, not 360 necessarily include all the requested options, or possibly 361 none. Any options included are appended to the echoed options, 362 similar to other options included by the server. 364 Server Information, type 6 366 Length MUST be non-zero. It MAY be used in Server Response 367 messages and MUST NOT be used in other messages. Support for 368 this option is optional. A server supporting this option 369 SHOULD add it in Server Response messages if and only if 370 requested by the client. The value is a UTF-8 string that 371 might contain vendor and version information for the server 372 implementation. It may also contain information on which 373 options the server supports. An interactive client MAY support 374 this option, and SHOULD then allow a user to request this 375 string and display it. 377 Reserved, type 7 379 This option code value was used by early implementations for an 380 option that is now deprecated. This option should no longer be 381 used. Clients MUST NOT use this option. Servers MUST treat it 382 as an unknown option (not process it if received, but if 383 received in an Echo Request message, it MUST be echoed in the 384 Echo Reply message). 386 Reserved, type 8 388 This option code value was used by early implementations for an 389 option that is now deprecated. This option should no longer be 390 used. Clients MUST NOT use this option. Servers MUST treat it 391 as an unknown option (not process it if received, but if 392 received in an Echo Request message, it MUST be echoed in the 393 Echo Reply message). 395 TTL, type 9 397 Length MUST be 1. This option contains a single octet 398 specifying the TTL of an Echo Reply message. Every time a 399 server sends a unicast or multicast Echo Reply message, it 400 SHOULD include this option specifying the TTL. This is used by 401 clients to determine the number of hops the messages have 402 traversed. It MUST NOT be used in other messages. A server 403 SHOULD specify this option if it knows what the TTL of the Echo 404 Reply will be. In general the server can specify a specific 405 TTL to the host stack. Note that the TTL is not necessarily 406 the same for unicast and multicast. Also note that this option 407 SHOULD be included even when not requested by the client. 409 Multicast Prefix, type 10 411 Length MUST be greater than 2. It MAY be used in Init messages 412 to request a group within the prefix(es) and it MAY be used in 413 Server Response messages to tell the client what prefix(es) it 414 may try to obtain a group from. It MUST NOT be used in Echo 415 Request/Reply messages. Note that this option MAY be included 416 multiple times to specify multiple prefixes. 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Address Family | Prefix Length |Partial address| 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 424 The address family is a value 0-65535 as assigned by IANA for 425 Internet address families [4]. This is followed by a prefix 426 length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special 427 "wildcard" use discussed below), and finally a group address. 428 For any family, prefix length 0 means that any multicast 429 address from that family is acceptable. This is what we call 430 "wildcard." The group address need only contain enough octets 431 to cover the prefix length bits (i.e., the group address would 432 have to be 3 octets long if the prefix length is 17-24, and 433 there need be no group address for the wildcard with prefix 434 length 0). Any bits past the prefix length MUST be ignored. 435 For IPv4, the option value length will be 4-7, while for IPv6, 436 it will be 4-19, and for the wildcard, it will be 3. 438 Session ID, type 11 440 Length MUST be non-zero. A server SHOULD include this in 441 Server Response messages. If a client receives this option in 442 a message, the client MUST echo the Session ID option in 443 subsequent Echo Request messages, with the exact same value. 444 The Session ID may help the server in keeping track of clients 445 and possibly manage per client state. The value of a new 446 Session ID SHOULD be chosen pseudo randomly so that it is hard 447 to predict. The Session ID can be used to prevent spoofing of 448 the source address of Echo Request messages. See the Security 449 Considerations for details. 451 Server Timestamp, type 12 453 Length MUST be 8 bytes. A server supporting this option, 454 SHOULD include it in Echo Reply messages, if requested by the 455 client. The timestamp specifies the time when the Echo Reply 456 message is sent. The first 4 bytes specify the number of 457 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 458 bytes specify the number of microseconds since the second 459 specified in the first 4 bytes. 461 3.3. Packet Format 463 The format of all messages is a one octet message type, followed by a 464 variable number of options. 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type | Options ... | 470 +-+-+-+-+-+-+-+-+ . | 471 | . | 472 | . | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ..... 475 There are four message types defined. Type 81 (the character Q in 476 ASCII) specifies an Echo Request (Query). Type 65 (the character A 477 in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I 478 in ASCII) is an Init message, and type 83 (the character S in ASCII) 479 is a Server Response message. 481 The options immediately follow the type octet and are not aligned in 482 any way (no spacing or padding), i.e., options might start at any 483 octet boundary. The option format is specified above. 485 3.4. Message Types and Options 487 There are four message types defined. We will now describe each of 488 the message types and which options they may contain. 490 Init, type 73 492 This message is sent by a client to request information from a 493 server. It is mainly used for requesting a group address, but 494 it may also be used to check which group prefixes the server 495 may provide groups from, or other server information. It MUST 496 include a Version option, and SHOULD include a Client ID. It 497 MAY include Option Request and Multicast Prefix Options. This 498 message is a request for a group address if and only if it 499 contains Multicast Prefix options. If multiple Prefix options 500 are included, they should be in prioritised order. I.e., the 501 server will consider the prefixes in the order they are 502 specified, and if it finds a group for a prefix, it will only 503 return that one group, not considering the remaining prefixes. 505 Server Response, type 83 507 This message is sent by a server, either as a response to an 508 Init, or in response to an Echo Request. When responding to 509 Init, it may provide the client with a multicast group (if 510 requested by the client), or it may provide other server 511 information. In response to an Echo Request, the message tells 512 the client to stop sending Echo Requests. The Version option 513 MUST always be included. Client ID and Sequence Number options 514 are echoed if present in the client message. When providing a 515 group to the client, it includes a Multicast Group option. It 516 SHOULD include Server Information and Prefix options if 517 requested. 519 Echo Request, type 81 521 This message is sent by a client, asking the server to send 522 unicast and multicast Echo Replies. It MUST include Version, 523 Sequence Number and Multicast Group options. If a Session ID 524 was received in a Server Response message, then the Session ID 525 MUST be included. It SHOULD include Client ID and Client 526 Timestamp options. It MAY include an Option Request option. 528 Echo Reply, type 65 530 This message is sent by a server in response to an Echo Request 531 message. This message is always sent in pairs, one as unicast 532 and one as multicast. The contents of the messages are mostly 533 the same. The server always echoes all of the options (but 534 never the Session ID) from the Echo Request. Any options in 535 the Echo Request that are unsupported by the server, are also 536 to be echoed. The two Echo Reply messages SHOULD both always 537 contain a TTL option (not necessarily equal). Both Echo Reply 538 messages SHOULD also when requested contain Server Timestamps 539 (not necessarily equal). 541 The below matrix summarises what options can go in what messages. 543 \ Message Type | Init | Server | Echo | Echo | 544 Option \ | | Response | Request | Reply | 545 -----------------------+--------+----------+---------+--------+ 546 Version (0) | MUST | MUST | MUST | ECHO | 547 Client ID (1) | SHOULD | ECHO | SHOULD | ECHO | 548 Sequence Number (2) | NOT | ECHO | MUST | ECHO | 549 Client Timestamp (3) | NOT | NOT | SHOULD | ECHO | 550 Multicast Group (4) | NOT | MAY | MUST | ECHO | 551 Option Request (5) | MAY | NOT | MAY | ECHO | 552 Server Information (6) | NOT | RQ | NOT | NOT | 553 Reserved (7) | NOT | NOT | NOT | ECHO | 554 Reserved (8) | NOT | NOT | NOT | ECHO | 555 TTL (9) | NOT | NOT | NOT | SHOULD | 556 Multicast Prefix (10) | MAY | MAY | NOT | NOT | 557 Session ID (11) | NOT | SHOULD | ECHO | NOT | 558 Server Timestamp (12) | NOT | NOT | NOT | RQ | 559 -----------------------+--------+----------+---------+--------+ 561 NOT means that the option MUST NOT be included. ECHO for a server 562 means that if the option is specified by the client, then the server 563 MUST echo the option in the response, with the exact same option 564 value. ECHO for a client only applies to the Session ID option. If 565 it is present in the Server Response, then it must be present with 566 the exact same option value in the following Echo Requests. RQ means 567 that the server SHOULD include the option in the response, when 568 requested by the client using the Option Request option. 570 3.5. Rate Limiting 572 Clients MUST by default send at most one Echo Request per second. 573 Servers MUST by default perform rate limiting, to guard against this 574 protocol being used for DoS attacks. The server MUST by default for 575 a given client, respond to on average at most one Echo Request 576 message per second. Server implementations should provide 577 configuration options allowing certain clients to perform more rapid 578 Echo Requests. If higher rates are allowed for specific client IP 579 addresses, then Init messages and the Session ID option MUST be used 580 to help prevent spoofing. 582 Implementers of applications/tools using this protocol SHOULD 583 consider the UDP guidelines [6], in particular if clients are to 584 send, or servers are to accept, Echo Requests at rates exceeding one 585 per second. See Section 9, "Security Considerations", for additional 586 discussion. 588 4. Client Behaviour 590 We will consider how a typical interactive client using the above 591 protocol would behave. 593 A client only requires a user to specify the unicast address of the 594 server. It can then send an Init message with a prefix option 595 containing the desired address family and zero prefix length 596 (wildcard entry). The server can then decide which group, from the 597 specified family, it should return. A client may also allow the user 598 to specify group address(es) or prefix(es) (for IPv6, the user may 599 only be required to specify a scope or an RP address, from which the 600 client can construct the desired prefix, possibly embedded-RP). From 601 this the client can specify one or more prefix options in an Init 602 message to tell the server which address it would prefer. If the 603 user specifies a group address, that can be encoded as a prefix of 604 maximal length (e.g., 32 for IPv4). The prefix options are in 605 prioritised order, i.e., the client should put the most preferred 606 prefix first. 608 If the client receives a Server Response message containing a group 609 address it can start sending Echo Request messages, see the next 610 paragraph. If there is no group address option, the client would 611 typically exit with an error message. The server may have included 612 some prefix options in the Server Response. The client may use this 613 to provide the user some feedback on what prefixes or scopes are 614 available. 616 Assuming the client got a group address in a Server Response, it can 617 start the multicast pings, after letting the user know which group is 618 being used. Normally, a client should send at most one Echo Request 619 per second. 621 When sending the Echo Requests, the client must always include the 622 group option. If the Server Response contained a Session ID, then it 623 must also include that, with the exact same value, in the Echo 624 Requests. If a client receives a Server Response message in response 625 to an Echo Request (that is, a Server Response message containing a 626 sequence number), this means there is an error and it should stop 627 sending Echo Requests. This could happen after server restart. 629 The client may allow the user to request server information. If the 630 user requests server information, the client can send an Init message 631 with no prefix options, but with an Option Request Option, requesting 632 the server to return a Server Information option. The server will 633 return server information if supported, and it may also return a list 634 of prefixes it supports. It will however not return a group address. 635 The client may also try to obtain only a list of prefixes by sending 636 an Init message with no prefixes and not requesting any specific 637 options. 639 Although not recommended, a client may pick a multicast group and 640 send Echo Request messages without first going through the Init - 641 Server Response negotiation. If this is supported by the server and 642 the server is okay with the group used, the server can then send Echo 643 Reply messages as usual. If the server is not okay, it will send a 644 Server Response telling the client to stop. 646 5. Server Behaviour 648 We will consider how a typical server using the above protocol would 649 behave, first looking at how to respond to Init messages. 651 If the Init message contains prefix options, the server should look 652 at them in order and see if it can assign a multicast address from 653 the given prefix. The server would be configured with, possibly have 654 a default, a set of groups it can offer. It may have a large pool 655 and pick a group at random, or possibly choosing a group based on 656 hashing of the client's IP address or identifier, or simply use a 657 fixed group. A server could possibly decide whether to include site 658 scoped group ranges based on the client's IP address. It is left to 659 the server to decide whether it should allow the same address to be 660 used simultaneously by multiple clients. 662 If the server finds a suitable group address, it returns this in a 663 group option in a Server Response message. The server should 664 additionally include a Session ID. This may help the server if it is 665 to keep some state, for instance to make sure the client uses the 666 group it got assigned. A good Session ID would be a pseudo random 667 byte string that is hard to predict. If the server cannot find a 668 suitable group address, or if there were no prefixes in the Init 669 message, it may send a Server Response message containing prefix 670 options listing what prefixes may be available to the client. 671 Finally, if the Init message requests the Server Information option, 672 the server should include that. 674 When the server receives an Echo Request message, it may first check 675 that the group address and Session ID (if provided) are valid. If 676 the server is satisfied, it will send a unicast Echo Reply message 677 back to the client, and also a multicast Echo Reply message to the 678 group address. The Echo Reply messages contain the exact options 679 (but no Session ID) and in the same order, as in the Echo Request, 680 and after that the server adds a TTL option and additional options if 681 needed. For example, it may add a timestamp if requested by the 682 client. If the server is not happy with the Echo Request (such as 683 bad group address or Session ID, request is too large), it may send a 684 Server Response message asking the client to stop. This Server 685 Response must echo the sequence number from the Echo Request. This 686 Server Response may contain group prefixes from which a client can 687 try to request a group address. The unicast and multicast Echo Reply 688 messages have identical UDP payload apart from possibly TTL and 689 timestamp option values. 691 Note that the server may receive Echo Request messages with no prior 692 Init message. This may happen when the server restarts or if a 693 client sends an Echo Request with no prior Init message. The server 694 may go ahead and respond if it is okay with the group used. If the 695 group is not okay, the server sends back a Server Response. 697 6. Recommendations for Implementers 699 The protocol as specified is fairly flexible and leaves a lot of 700 freedom for implementers. In this section we present some 701 recommendations. 703 Server administrators should be able to configure one or multiple 704 group prefixes in a server implementation. When deploying servers on 705 the Internet and in other environments, the server administrator 706 should be able to restrict the server to respond to only a few 707 multicast groups which should not be currently used by multicast 708 applications. A server implementation should also provide 709 flexibility for an administrator to apply various policies to provide 710 one or multiple group prefixes to specific clients, e.g., site scoped 711 addresses for clients that are inside the site. 713 As specified in Section 3.5, a server must by default for a given 714 client, respond to at most one Echo Request message per second. A 715 leaky bucket algorithm is suggested, where the rate can be higher for 716 a few seconds, but the average rate should by default be limited to a 717 message per client per second. Server implementations should provide 718 administrative control of which client IP addresses to serve, and may 719 also allow certain clients to perform more rapid Echo Requests. 721 If a server uses different policies for different IP addresses, it 722 should require clients to send Init messages and return an 723 unpredictable Session ID to help prevent spoofing. This is an 724 absolute requirement if exceeding the default rate limit. See 725 specification in Section 3.5. 727 7. Acknowledgments 729 The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and 730 Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source 731 Specific Multicast, and also the Internet Draft 732 draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with 733 several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave 734 Thaler have contributed in different ways to the implementation of 735 the ssmping tools at [5]. Many people in communities like TERENA, 736 Internet2 and the M6Bone have used early implementations of ssmping 737 and provided feedback that have influenced the current protocol. 738 Thanks to Kevin Almeroth, Tony Ballardie, Bill Cerveny, Toerless 739 Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui, 740 Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, 741 Trond Skjesol and Cao Wei for reviewing and providing feedback on 742 this draft. In particular Hugo, Gorry and Bharat have provided lots 743 of input on several revisions of the draft. 745 8. IANA Considerations 747 IANA is requested to assign a UDP user-port in the range 1024-49151 748 for use by this protocol, and also to provide registries for message 749 and option types. The string "[TBD]" in this document should be 750 replaced with the assigned port. 752 There should be a message types registry. Message types are in the 753 range 0-255. Message types 0-191 require specification (an RFC or 754 other permanent and readily available reference), while types 192-255 755 are for experimental use and are not registered. The registry should 756 include the messages defined in Section 3.4. A message specification 757 must describe the behaviour with known option types as well as the 758 default behaviour with unknown ones. 760 There should also be an option type registry. Option types 0-49151 761 require specification (an RFC or other permanent and readily 762 available reference), while types 49152-65535 are for experimental 763 use and are not registered. The registry should include the options 764 defined in Section 3.2. An option specification must describe how 765 the option may be used with the known message types. This includes 766 which message types the option may be used with. 768 The initial registry definitions are as follows: 770 Multicast Ping Protocol Parameters: 772 Registry Name: Multicast Ping Protocol Message Types 773 Reference: [this doc] 774 Registration Procedures: Specification Required 776 Registry: 777 Type Name Reference 778 ----------- ------------------------------------ ---------- 779 65 Echo Reply [this doc] 780 73 Init [this doc] 781 81 Echo Request [this doc] 782 83 Server Response [this doc] 783 192-255 Experimental 785 Registry Name: Multicast Ping Protocol Option Types 786 Reference: [this doc] 787 Registration Procedures: Specification Required 789 Registry: 790 Type Name Reference 791 ----------- ------------------------------------ ---------- 792 0 Version [this doc] 793 1 Client ID [this doc] 794 2 Sequence Number [this doc] 795 3 Client Timestamp [this doc] 796 4 Multicast Group [this doc] 797 5 Option Request Option [this doc] 798 6 Server Information [this doc] 799 7 Reserved [this doc] 800 8 Reserved [this doc] 801 9 TTL [this doc] 802 10 Multicast Prefix [this doc] 803 11 Session ID [this doc] 804 12 Server Timestamp [this doc] 805 49152-65535 Experimental 807 9. Security Considerations 809 There are some security issues to consider. One is that a host may 810 send an Echo Request with an IP source address of another host, and 811 make an arbitrary multicast ping server on the Internet send packets 812 to this other host. This behaviour is fairly harmless. The worst 813 case is if the host receiving the unicast Echo Replies also happens 814 to be joined to the multicast group used. In this case, there would 815 be an amplification effect where the host receives twice as many 816 replies as there are requests sent. See below for how spoofing can 817 be prevented. 819 For ASM (Any-Source Multicast) a host could also make a multicast 820 ping server send multicast packets to a group that is used for 821 something else, possibly disturbing other uses of that group. 822 However, server implementations should allow administrators to 823 restrict which groups a server responds to. The main concern is 824 bandwidth. To limit the bandwidth used, a server MUST by default 825 perform rate limiting, responding to at most one Echo Request per 826 second. 828 In order to help prevent spoofing, a server SHOULD require the client 829 to send an Init message, and return an unpredictable Session ID in 830 the response. The ID should be associated with the IP address and 831 have a limited lifetime. The server SHOULD then only respond to Echo 832 Request messages that have a valid Session ID associated with the 833 source IP address of the Echo Request. 835 10. References 837 10.1. Normative References 839 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 840 Levels", BCP 14, RFC 2119, March 1997. 842 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 843 September 1981. 845 [3] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 846 August 1980. 848 [4] "IANA, Address Family Numbers", 849 . 851 10.2. Informative References 853 [5] "ssmping implementation", 854 . 856 [6] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for 857 Application Designers", BCP 145, RFC 5405, November 2008. 859 Author's Address 861 Stig Venaas 862 UNINETT 863 Trondheim NO-7465 864 Norway 866 Email: venaas@uninett.no 868 Full Copyright Statement 870 Copyright (C) The IETF Trust (2008). 872 This document is subject to the rights, licenses and restrictions 873 contained in BCP 78, and except as set forth therein, the authors 874 retain all their rights. 876 This document and the information contained herein are provided on an 877 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 878 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 879 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 880 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 881 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 882 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 884 Intellectual Property 886 The IETF takes no position regarding the validity or scope of any 887 Intellectual Property Rights or other rights that might be claimed to 888 pertain to the implementation or use of the technology described in 889 this document or the extent to which any license under such rights 890 might or might not be available; nor does it represent that it has 891 made any independent effort to identify any such rights. Information 892 on the procedures with respect to rights in RFC documents can be 893 found in BCP 78 and BCP 79. 895 Copies of IPR disclosures made to the IETF Secretariat and any 896 assurances of licenses to be made available, or the result of an 897 attempt made to obtain a general license or permission for the use of 898 such proprietary rights by implementers or users of this 899 specification can be obtained from the IETF on-line IPR repository at 900 http://www.ietf.org/ipr. 902 The IETF invites any interested party to bring to its attention any 903 copyrights, patents or patent applications, or other proprietary 904 rights that may cover technology that may be required to implement 905 this standard. Please address the information to the IETF at 906 ietf-ipr@ietf.org.