idnits 2.17.1 draft-ietf-mboned-ssmping-05.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 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 812. 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 older implementations of ssmping 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 (September 18, 2008) is 5698 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'TBD' on line 106 ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-10 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 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: Informational September 18, 2008 5 Expires: March 22, 2009 7 Multicast Ping Protocol 8 draft-ietf-mboned-ssmping-05 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 March 22, 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 . . . . . . . . . . . . . . . . . . . . . . . 12 60 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 61 8. Recommendations for Implementers . . . . . . . . . . . . . . . 15 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 66 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 67 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 Intellectual Property and Copyright Statements . . . . . . . . . . 18 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 RFC 2460 [3]) and requires 80 both a client and a server implementing this protocol. Intermediate 81 routers are not required to support this protocol. They forward 82 Protocol Messages and data traffic as usual. 84 The protocol here specified is based on the actual implementation of 85 the ssmping and asmping tools [5] 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. E.g., 142 with PIM-SM one may be able to tell whether the forwarding is on a 143 shared or source-specific tree and when an eventual switch occurs. 144 Provided that the server sends the unicast and multicast replies 145 nearly simultaneously, the client may also be able to measure the 146 difference in one way delay for unicast and multicast on the path 147 from server to client, and also differences in delay. Servers may 148 optionally specify a timestamp. This may be useful since the unicast 149 and multicast replies can not be sent simultaneously (the delay 150 depending on the host's operating system and load). 152 3. Protocol specification 154 There are four different message types. There are Echo Request and 155 Echo Reply messages used for the actual measurements; there is an 156 Init message that SHOULD be used to initialise a ping session and 157 negotiate which group to use; and finally a Server Response message 158 that is mainly used in response to the Init message. The messages 159 MUST always be in network byte order. UDP checksums MUST always be 160 used. 162 The messages share a common format: one octet specifying the message 163 type, followed by a number of options in TLV (Type, Length and Value) 164 format. This makes the protocol easily extendible. The Init message 165 generally contains some prefix options asking the server for a group 166 from one of the specified prefixes. The server responds with a 167 Server Response message that contains the group address to use, or 168 possibly prefix options describing what multicast groups the server 169 may be able to provide. For an Echo Request the client generally 170 includes a number of options, and a server MAY simply echo the 171 contents (only changing the message type) without inspecting the 172 options if it does not support any options. This might be true for a 173 simple Multicast Ping Protocol server. However, the server SHOULD 174 add a TTL option, and there are other options that a server 175 implementation MAY support, e.g., the client may ask for certain 176 information or a specific behaviour from the server. The Echo 177 Replies (one unicast and one multicast) MUST first contain the exact 178 options from the request (in the same order), and then, immediately 179 following, any options appended by the server. A server MUST NOT 180 process unknown options, but they MUST still be included in the Echo 181 Reply. A client MUST ignore any unknown options. 183 This document defines a number of different options. Some options do 184 not require processing by servers and are simply returned unmodified 185 in the reply. There are, however, other client options that the 186 server may care about, and also server options that may be requested 187 by a client. Unless otherwise specified, an option MUST NOT be used 188 multiple times in the same message. 190 3.1. Option format 192 All options are TLVs formatted as specified below. 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type | Length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Value | 200 | . | 201 | . | 202 | . | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Type (2 octets) specifies the option. The different options are 206 defined below. 208 Length (2 octets) specifies the length of the value field. Depending 209 on the option type, it can be from 0 to 65535. 211 Value. The value must always be of the specified length. See the 212 respective option definitions for possible values. If the length is 213 0, the value field is not included. 215 3.2. Defined Options 217 This document defines the following options: Version (0), Client ID 218 (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), 219 Option Request Option (5), Server Information (6), TTL (9), Multicast 220 Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and 221 8 are reserved. The options are defined below. 223 Version, type 0 225 Length MUST be 1. This option MUST always be included in all 226 messages, and the value MUST be set to 2 (in decimal). Note 227 that there are older implementations of ssmping that only 228 partly follow this specification. They can be regarded as 229 version 1 and do not use this option. If a server receives a 230 message with a version other than 2 (or missing), the server 231 SHOULD (unless it supports the particular version) send a 232 Response message back with version set to 2. Client ID and 233 Sequence Number options SHOULD be echoed if present. It SHOULD 234 not include any other options. A client receiving a response 235 with a version other than 2, MUST (unless it supports the 236 particular version), stop sending requests to the server. 238 Client ID, type 1 240 Length MUST be non-zero. A client SHOULD always include this 241 option in all messages (both Init and Request). The client may 242 use any value it likes to be able to detect whether a reply is 243 a reply to its Init/Request or not. A server should treat this 244 as opaque data, and MUST echo this option back in the reply if 245 present (both Server Response and Reply). The value might be a 246 process ID, perhaps process ID combined with an IP address 247 because it may receive multicast responses to queries from 248 other clients. It is left to the client implementer how to 249 make use of this option. 251 Sequence Number, type 2 253 Length MUST be 4. A client MUST always include this in Request 254 messages and MUST NOT include it in Init messages. A server 255 replying to a Request message MUST copy it into the Reply (or 256 Server Response message on error). This contains a 32 bit 257 sequence number. The values would typically start at 1 and 258 increase by one for each request in a sequence. 260 Client Timestamp, type 3 262 Length MUST be 8 bytes. A client SHOULD include this in 263 Request messages and MUST NOT include it in Init messages. A 264 server replying to a Request message MUST copy it into the 265 Reply. The timestamp specifies the time when the Request 266 message is sent. The first 4 bytes specify the number of 267 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 268 bytes specify the number of microseconds since the last second 269 since the Epoch. 271 Multicast Group, type 4 273 Length MUST be greater than 2. It MAY be used in Server 274 Response messages to tell the client what group to use in 275 subsequent Request messages. It MUST be used in Request 276 messages to tell the server what group address to respond to 277 (this group would typically be previously obtained in a Server 278 Response message). It MUST be used in Reply messages (copied 279 from the Request message). It MUST NOT be used in Init 280 messages. The format of the option value is as below. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Address Family | Multicast group address... | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 288 The address family is a value 0-65535 as assigned by IANA for 289 Internet Address Families [4]. This is followed by the group 290 address. Length of the option value will be 6 for IPv4, and 18 291 for IPv6. 293 Option Request Option, type 5 295 Length MUST be greater than 1. This option MAY be used in 296 client messages (Init and Request messages). A server MUST NOT 297 send this option, except that if it is present in a Request 298 message, the server MUST echo it in replies (Reply message) to 299 the Request. This option contains a list of option types for 300 options that the client is requesting from the server. Support 301 for this option is optional for both clients and servers. The 302 length of this option will be a non-zero even number, since it 303 contains one or more option types that are two octets each. 304 The format of the option value is as below. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Option Type | Option Type | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | ..... | 313 This option might be used by the client to ask the server to 314 include options like Timestamp or Server Information. A client 315 MAY request Server Information in Init messages; it MUST NOT 316 request it in other messages. A client MAY request a Timestamp 317 in Request messages; it MUST NOT request it in other messages. 318 Subject to enforcing the above restrictions, a server 319 supporting this option SHOULD include the requested options in 320 responses (Reply messages) to the Request containing the Option 321 Request Option. The server may according to implementation or 322 local configuration, not necessarily include all the requested 323 options, or possibly none. Any options included are appended 324 to the echoed options, similar to other options included by the 325 server. 327 Server Information, type 6 329 Length MUST be non-zero. It MAY be used in Server Response 330 messages and MUST NOT be used in other messages. Support for 331 this option is optional. A server supporting this option 332 SHOULD add it in Server Response messages if and only if 333 requested by the client. The value is a UTF-8 string that 334 might contain vendor and version information for the server 335 implementation. It may also contain information on which 336 options the server supports. An interactive client MAY support 337 this option, and SHOULD then allow a user to request this 338 string and display it. 340 Reserved, type 7 342 This option code value was used by early implementations for an 343 option that is now deprecated. This option should no longer be 344 used. Clients MUST NOT use this option. Servers MUST treat it 345 as an unknown option (not process it if received, but if 346 received in a Request message, it MUST be echoed in the Reply 347 message). 349 Reserved, type 8 351 This option code value was used by early implementations for an 352 option that is now deprecated. This option should no longer be 353 used. Clients MUST NOT use this option. Servers MUST treat it 354 as an unknown option (not process it if received, but if 355 received in a Request message, it MUST be echoed in the Reply 356 message). 358 TTL, type 9 360 Length MUST be 1. This option contains a single octet 361 specifying the TTL of a Reply message. Every time a server 362 sends a unicast or multicast Reply message, it SHOULD include 363 this option specifying the TTL. This is used by clients to 364 determine the number of hops the messages have traversed. It 365 MUST NOT be used in other messages. A server SHOULD specify 366 this option if it knows what the TTL of the Reply will be. In 367 general the server can specify a specific TTL to the host 368 stack. Note that the TTL is not necessarily the same for 369 unicast and multicast. 371 Multicast Prefix, type 10 373 Length MUST be greater than 2. It MAY be used in Init messages 374 to request a group within the prefix(es), it MAY be used in 375 Server Response messages to tell the client what prefix(es) it 376 may try to obtain a group from. It MUST NOT be used in 377 Request/Reply messages. Note that this option MAY be included 378 multiple times to specify multiple prefixes. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Address Family | Prefix Length |Partial address| 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 386 The address family is a value 0-65535 as assigned by IANA for 387 Internet Address Families [4]. This is followed by a prefix 388 length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special 389 'wildcard' use discussed below), and finally a group address. 390 For any family, prefix length 0 means that any multicast 391 address from that family is acceptable. This is what we call 392 'wildcard'. The group address need only contain enough octets 393 to cover the prefix length bits (i.e., the group address would 394 have to be 3 octets long if the prefix length is 17-24, and 395 there need be no group address for the wildcard with prefix 396 length 0). Any bits past the prefix length MUST be ignored. 397 For IPv4, the option value length will be 4-7, while for IPv6, 398 it will be 4-19, and for the wildcard, it will be 3. 400 Session ID, type 11 402 Length MUST be non-zero. A server SHOULD include this in 403 Server Response and Reply messages. If a client receives this 404 option in a message, the client MUST echo the Session ID option 405 in subsequent Request messages, with the exact same value, 406 until the next message is received from the server. If the 407 next message from the server has no Session ID or a new Session 408 ID value, the client should do the same, either not use the 409 Session ID, or use the new value. The Session ID may help the 410 server in keeping track of clients and possibly manage per 411 client state. The value of a new Session ID should be chosen 412 pseudo randomly so that it is hard to predict. This can be 413 used to prevent spoofing of the source address of Request 414 messages, see the Security Considerations for details. 416 Server Timestamp, type 12 418 Length MUST be 8 bytes. A server supporting this option, 419 SHOULD include it in Reply messages, if requested by the 420 client. The timestamp specifies the time when the Reply 421 message is sent. The first 4 bytes specify the number of 422 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 423 bytes specify the number of microseconds since the last second 424 since the Epoch. 426 4. Packet Format 428 The format of all messages is a one octet message type, directly 429 followed by a variable number of options. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type | Options ... | 435 +-+-+-+-+-+-+-+-+ . | 436 | . | 437 | . | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ..... 440 There are four message types defined. Type 81 (the character Q in 441 ASCII) specifies an Echo Request (Query). Type 65 (the character A 442 in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I 443 in ASCII) is an Init message, and type 83 (the character S in ASCII) 444 is a Server Response message. 446 The options directly follow the type octet and are not aligned in any 447 way (no spacing or padding), i.e., options might start at any octet 448 boundary. The option format is specified above. 450 5. Message types and options 452 There are four message types defined. We will now describe each of 453 the message types and which options they may contain. 455 Init, type 73 457 This message is sent by a client to request information from a 458 server. It is mainly used for requesting a group address, but 459 it may also be used to check which group prefixes the server 460 may provide groups from, or other server information. It MUST 461 include a Version option, and SHOULD include a Client ID. It 462 MAY include Option Request and Multicast Prefix Options. This 463 message is a request for a group address if and only if it 464 contains Multicast Prefix options. If multiple Prefix options 465 are included, they should be in prioritised order. I.e., the 466 server will consider the prefixes in the order they are 467 specified, and if it finds a group for a prefix, it will only 468 return that one group, not considering the remaining prefixes. 470 Server Response, type 83 472 This message is sent by a server. Either as a response to an 473 Init, or in response to a Request. When responding to Init, it 474 may provide the client with a multicast group (if requested by 475 the client), or it may provide other server information. In 476 response to a Request, the message tells the client to stop 477 sending Requests. The Version option MUST always be included. 478 Client ID and Sequence Number options are echoed if present in 479 the client message. When providing a group to the client, it 480 includes a Multicast Group option. It SHOULD include Server 481 Information and Prefix options if requested. 483 Echo Request, type 81 485 This message is sent by a client, asking the server to send 486 unicast and multicast replies. It MUST include Version, 487 Sequence Number and Multicast Group options. If the last 488 message (if any) received from the server contained a Session 489 ID, then this MUST also be included. It SHOULD include Client 490 ID and Client Timestamp options. It MAY include an Option 491 Request option. 493 Echo Reply, type 65 495 This message is sent by a server in response to an Echo Request 496 message. This message is always sent in pairs, one as unicast 497 and one as multicast. The contents of the messages are mostly 498 the same. The server echoes most of the options from the Echo 499 Request (any options in the Request that are unsupported by the 500 server, are always echoed). The only option that may be 501 present in the Request which is not always echoed, is the 502 Session ID option. In most cases the server would echo it, but 503 the server may also change or omit it. The two Reply messages 504 SHOULD both contain a TTL option (not necessarily equal), and 505 both SHOULD also contain Server Timestamps (not necessarily 506 equal) when requested. 508 For the reader's convenience we provide the matrix below, showing 509 what options can go in what messages. 511 Option / Message Type | Init | Server Response | Request | Reply | 512 -----------------------------------------------------------------+ 513 Version (0) | MUST | ECHO | MUST | ECHO | 514 Client ID (1) |SHOULD| ECHO | SHOULD | ECHO | 515 Sequence Number (2) | NOT | ECHO | MUST | ECHO | 516 Client Timestamp (3) | NOT | NOT | SHOULD | ECHO | 517 Multicast Group (4) | NOT | MAY | MUST | ECHO | 518 Option Request (5) | MAY | NOT | MAY | ECHO | 519 Server Information (6)| NOT | RQ | NOT | NOT | 520 Reserved (7) | NOT | NOT | NOT | ECHO | 521 Reserved (8) | NOT | NOT | NOT | ECHO | 522 TTL (9) | NOT | NOT | NOT |SHOULD | 523 Multicast Prefix (10) | MAY | MAY | NOT | NOT | 524 Session ID (11) | NOT | MAY | ECHO | MAY | 525 Server Timestamp (12) | NOT | NOT | NOT | RQ | 527 NOT means that the option MUST NOT be included. ECHO for a server 528 means that if the option is specified by the client, then the server 529 MUST echo the option in the response, with the exact same option 530 value. ECHO for a client means that it MUST echo the option it got 531 in the last message from the server in any subsequent messages it 532 sends. RQ means that the server SHOULD include the option in the 533 response, when requested by the client using the Option Request 534 option. 536 6. Client Behaviour 538 We will consider how a typical interactive client using the above 539 protocol would behave. A client need only require a user to specify 540 the unicast address of the server. It can then send an Init message 541 with a prefix option containing the desired address family and zero 542 prefix length (wildcard entry). The server is then free to decide 543 which group, from the specified family, it should return. A client 544 may also allow a user to specify group address(es) or prefix(es) (for 545 IPv6, the user may only be required to specify a scope or an RP 546 address, from which the client can construct the desired prefix, 547 possibly embedded-RP). From this the client can specify one or more 548 prefix options in an Init message to tell the server which address it 549 would prefer. If the user specifies a group address, that can be 550 encoded as a prefix of maximal length (e.g., 32 for IPv4). The 551 prefix options are in prioritised order, i.e., the client should put 552 the most preferred prefix first. 554 If the client receives a Server Response message containing a group 555 address it can start sending Request messages, see the next 556 paragraph. If there is no group address option, it would typically 557 exit with an error message. The server may have included some prefix 558 options in the Server Response. The client may use this to provide 559 the user some feedback on what prefixes or scopes are available. 561 Assuming the client got a group address in a Server Response, it can 562 start pinging. Before it does that, it should let the user know 563 which group is being used. Normally, a client should send at most 564 one ping request per second. When sending ping Requests, the client 565 must always include the group option. If the last message from the 566 server contained a Session ID, then it must also include that with 567 the same value. Typically it would receive a Session ID in a Server 568 Response together with the group address, and then the ID would stay 569 the same during the entire ping sequence. However, if for instance 570 the server process is restarted, it may still be possible to continue 571 pinging but the Session ID may be changed by the server. Hence a 572 client implementation must always use the last Session ID it 573 received, and not necessarily the one from the Server Response 574 message. If a client receives a Server Response message in response 575 to a Request message (that is, a Server Response message containing a 576 sequence number), this means there is an error and it should stop 577 sending Requests. This may for instance happen after server restart. 579 The client may allow the user to request server information. If the 580 user requests server information, the client can send an Init message 581 with no prefix options, but with an Option Request Option, requesting 582 the server to return a Server Information option. The server will 583 return server information if supported, and it may also return a list 584 of prefixes it supports. It will however not return a group address. 585 The client may also try to obtain only a list of prefixes by sending 586 an Init message with no prefixes and not requesting any specific 587 options. 589 Note that a client may pick a multicast group and send Request 590 messages without first going through the Init - Server Response 591 negotiation. If this is supported by the server and the server is 592 okay with the group used, the server can then send Reply messages as 593 usual. If the server is not okay, it will send a Server Response 594 telling the client to stop. 596 7. Server Behaviour 598 We will consider how a typical server using the above protocol would 599 behave. First we consider how to respond to Init messages. If the 600 Init message contains prefix options, the server should look at them 601 in order and see if it can assign a multicast address from the given 602 prefix. The server would be configured, possibly have a default, 603 specifying which groups it can offer. It may have a large pool just 604 picking a group at random, possibly choose a group based on hashing 605 of the client's IP address or identifier, or just use a fixed group. 606 A server could possibly decide whether to include site scoped group 607 ranges based on the client's IP address. It is left to the server to 608 decide whether it should allow the same address to be used 609 simultaneously by multiple clients. If the server finds a suitable 610 group address, it returns this in a group option in a Server Response 611 message. The server should additionally include a Session ID. This 612 may help the server if it is to keep some state, for instance for 613 making sure the client uses the group it got assigned. A good 614 Session ID would be a pseudo random byte string that is hard to 615 predict. If the server cannot find a suitable group address, or if 616 there were no prefixes in the Init message, it may send a Server 617 Response message containing prefix options listing what prefixes may 618 be available to the client. Finally, if the Init message requests 619 the Server Information option, it should include that. 621 When the server receives a Request message, it may first check that 622 the group address and Session ID (if provided) are valid. If the 623 server is satisfied, it will send a unicast Reply message back to the 624 client, and also a multicast Reply message to the group address. The 625 Reply messages contain the exact options and in the same order, as in 626 the Request, and after that the server adds a TTL option and 627 additional options if needed. E.g., it may add a timestamp if 628 requested by the client. If the server is not happy with the Request 629 (bad group address or Session ID, request is too large etc), it may 630 send a Server Response message asking the client to stop. This 631 Server Response must echo the sequence number from the Request. This 632 Server Response may contain group prefixes from which a client can 633 try to request a group address. The unicast and multicast Reply 634 messages have identical UDP payload apart from possibly TTL and 635 timestamp option values. 637 Note that the server may receive Request messages with no prior Init 638 message. This may happen when the server restarts or if a client 639 sends a Request with no prior Init message. The server may go ahead 640 and respond if it is okay with the group used. In the responses it 641 may add a Session ID which will then be in later requests from the 642 client. If the group is not okay, the server sends back a Server 643 Response. The Response is just as if it got an Init message with no 644 prefixes. If the server adds or modifies the SessionID in replies, 645 it must use the exact same SessionID in the unicast and multicast 646 replies. 648 By default, a server should perform rate limiting and for a given 649 client, respond to at most one Request message per second. A leaky 650 bucket algorithm is suggested, where the rate can be higher for a few 651 seconds, but the average rate should by default be limited to a 652 message per client per second. 654 8. Recommendations for Implementers 656 The protocol as specified is fairly flexible and leaves a lot of 657 freedom for implementers. In this section we present some 658 recommendations. 660 Server administrators should be able to configure one or multiple 661 group prefixes in a server implementation. When deploying servers on 662 the Internet and in other environments, the server administrator 663 should be able to restrict the server to respond to only a few 664 multicast groups which should not be currently used by multicast 665 applications. A server implementation should also provide 666 flexibility for an administrator to apply various policies to provide 667 one or multiple group prefixes to specific clients, e.g., site scoped 668 addresses for clients that are inside the site. Clients could be 669 identified by their IP address provided that clients are required to 670 send Init messages, and they receive an unpredictable Session ID. 672 Servers must perform rate limiting, to guard against this protocol 673 being used for DoS attacks. By default, clients should send at most 674 one request per second, and servers should perform rate limiting if a 675 client sends more frequent requests. Server implementations should 676 provide administrative control of which client IP addresses to serve, 677 and may also allow certain clients to perform more rapid requests. 678 Implementers of applications/tools using this protocol should 679 consider the UDP guidelines [6], in particular if clients are to 680 send, or servers are to accept, requests at rates exceeding one per 681 second. 683 9. Acknowledgements 685 The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and 686 Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source 687 Specific Multicast, and also the Internet Draft 688 draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with 689 several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave 690 Thaler have contributed in different ways to the implementation of 691 the ssmping tools at [5]. Many people in communities like TERENA, 692 Internet2 and the M6Bone have used early implementations of ssmping 693 and provided feedback that have influenced the current protocol. 694 Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Alfred 695 Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil 696 Sarac, Pekka Savola, Trond Skjesol and Cao Wei for reviewing and 697 providing feedback on this draft. In particular Hugo, Gorry and 698 Bharat have provided lots of input on several revisions of the draft 700 10. IANA Considerations 702 IANA is requested to provide a UDP port number for use by this 703 protocol, and also to provide registries for message and option 704 types. 706 There should be a message types registry. Message types are in the 707 range 0-255. Message types 0-191 can be assigned referencing an RFC 708 (it may be Informational), while types 192-255 are freely available 709 for experimental, private or vendor specifc use. The registry should 710 include the messages defined in Section 5 712 There should also be an option type registry. Option types 0-49151 713 can be assigned referencing an RFC (it may be Informational), while 714 types 49152-65535 are freely available for experimental, private or 715 vendor specifc use. The registry should include the options defined 716 in Section 3.2. 718 11. Security Considerations 720 There are some security issues to consider. One is that a host may 721 send a request with an IP source address of another host, and make an 722 arbitrary multicast ping server on the Internet send packets to this 723 other host. This behaviour is fairly harmless. The worst case is if 724 the host receiving the unicast replies also happen to be joined to 725 the multicast group used. In this case, there would be an 726 amplification effect where the host receives twice as many replies as 727 there are requests sent. 729 In order to help prevent spoofing, a server SHOULD require the client 730 to send an Init message, and return an unpredictable Session ID in 731 the response. The ID should be associated with the IP address and 732 have a limited lifetime. The server SHOULD then only respond to 733 Request messages that have a valid Session ID associated with the 734 source IP address of the Request. 736 Server implementations should allow administrators to restrict which 737 groups a server responds to, and also perform rate limiting. This is 738 discussed in Section 8). 740 12. References 742 12.1. Normative References 744 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 745 Levels", BCP 14, RFC 2119, March 1997. 747 [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 748 August 1980. 750 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 751 Specification", RFC 2460, December 1998. 753 [4] "IANA, Address Family Numbers", 754 . 756 12.2. Informative References 758 [5] "ssmping implementation", 759 . 761 [6] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for 762 Application Designers", draft-ietf-tsvwg-udp-guidelines-10 (work 763 in progress), August 2008. 765 Author's Address 767 Stig Venaas 768 UNINETT 769 Trondheim NO-7465 770 Norway 772 Email: venaas@uninett.no 774 Full Copyright Statement 776 Copyright (C) The IETF Trust (2008). 778 This document is subject to the rights, licenses and restrictions 779 contained in BCP 78, and except as set forth therein, the authors 780 retain all their rights. 782 This document and the information contained herein are provided on an 783 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 784 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 785 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 786 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Intellectual Property 792 The IETF takes no position regarding the validity or scope of any 793 Intellectual Property Rights or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; nor does it represent that it has 797 made any independent effort to identify any such rights. Information 798 on the procedures with respect to rights in RFC documents can be 799 found in BCP 78 and BCP 79. 801 Copies of IPR disclosures made to the IETF Secretariat and any 802 assurances of licenses to be made available, or the result of an 803 attempt made to obtain a general license or permission for the use of 804 such proprietary rights by implementers or users of this 805 specification can be obtained from the IETF on-line IPR repository at 806 http://www.ietf.org/ipr. 808 The IETF invites any interested party to bring to its attention any 809 copyrights, patents or patent applications, or other proprietary 810 rights that may cover technology that may be required to implement 811 this standard. Please address the information to the IETF at 812 ietf-ipr@ietf.org.