idnits 2.17.1 draft-ietf-mboned-ssmping-04.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 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 803. 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 (February 21, 2008) is 5908 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'TBD' on line 110 ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-05 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 February 21, 2008 5 Expires: August 24, 2008 7 Multicast Ping Protocol 8 draft-ietf-mboned-ssmping-04 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 August 24, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 The Multicast Ping Protocol specified in this document allows for 42 checking whether an endpoint can receive multicast, both Source- 43 Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also 44 be used to obtain additional multicast related information like 45 multicast tree setup time etc. This protocol is based on an 46 implementation of tools called ssmping and asmping. 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [1]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6 61 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5. Message types and options . . . . . . . . . . . . . . . . . . 11 63 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12 64 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 65 8. Recommendations for Implementers . . . . . . . . . . . . . . . 15 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 71 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 Intellectual Property and Copyright Statements . . . . . . . . . . 18 75 1. Introduction 77 The Multicast Ping Protocol specified in this document allows for 78 checking multicast connectivity. In addition to checking reception 79 of multicast (SSM or ASM), the protocol can provide related 80 information like multicast tree setup time, the number of hops the 81 packets have traveled, as well as packet delay and loss. This 82 functionality resembles, in part, the ICMP Echo Request/Reply 83 mechanism, but uses UDP (RFC 768 [2] and RFC 2460 [3]) and requires 84 both a client and a server implementing this protocol. Intermediate 85 routers are not required to support this protocol. They forward 86 Protocol Messages and data traffic as usual. 88 The protocol here specified is based on the actual implementation of 89 the ssmping and asmping tools [5] which are widely used by the 90 Internet community to conduct multicast connectivity tests. 92 2. Architecture 94 Before describing the protocol in detail, we provide a brief overview 95 of how the protocol may be used and what information it may provide. 96 The typical protocol usage is as follows: A server runs continuously 97 to serve requests from clients. A client can test the multicast 98 reception from this server, provided it knows a unicast address of 99 the server. It will then send a unicast message to the server asking 100 for a group to use. Optionally the user may have requested a 101 specific group or scope, in which case the client will ask for a 102 group matching the user's request. The server will respond with a 103 group to use, or an error if no group is available. Next, for ASM, 104 the client joins an ASM group G, while for SSM it joins a channel 105 (S,G). Here G is the group specified by the server, and S is the 106 unicast address used to reach the server. 108 After joining the channel, the client unicasts multicast ping 109 requests to the server. The requests are sent using UDP with 110 destination port set to the standardised multicast ping port [TBD]. 111 The requests are sent periodically, e.g., once per second, to the 112 server. The requests contain a sequence number, and typically a 113 timestamp. The requests are echoed by the server, except the server 114 may add a few options. For each request, the server sends two 115 replies. One reply is unicast back to the source IP address and 116 source UDP port of the request, while another is multicast to the 117 requested multicast group G and the source UDP port of the request. 118 Both replies are sent from the same port on which the request was 119 received. The server should specify the TTL used for both the 120 unicast and multicast messages (we recommend at least 64) by 121 including a TTL option; allowing the client to compute the number of 122 hops. The client should leave the channel/group when it has finished 123 its measurements. 125 By use of this protocol, a client can obtain information about 126 several multicast delivery characteristics. First, by receiving 127 unicast replies, it can verify that the server is receiving the 128 unicast requests, is operational and responding. Hence, provided 129 that the client receives unicast replies, a failure to receive 130 multicast indicates either a multicast problem or a multicast 131 administrative restriction. If it does receive multicast, it knows 132 not only that it can receive; it may also estimate the amount of time 133 it took to establish the multicast tree (at least if it is in the 134 range of seconds), whether there are packet drops, and the length and 135 variation of Round Trip Times (RTT). For unicast, the RTT is the 136 time from when the unicast request is sent to when the reply is 137 received. The measured multicast RTT also references the client's 138 unicast request. By use of the TTL option specifying the TTL of the 139 replies when they are originated, the client can also determine the 140 number of router hops it is from the source. Since similar 141 information is obtained in the unicast replies, the host may compare 142 its multicast and unicast results and is able to check for 143 differences in the number of hops, RTT, etc. The number of multicast 144 hops and changes in the number of hops over time, may also reveal 145 details about the multicast tree and multicast tree changes. E.g., 146 with PIM-SM one may be able to tell whether the forwarding is on a 147 shared or source-specific tree and when an eventual switch occurs. 148 Provided that the server sends the unicast and multicast replies 149 nearly simultaneously, the client may also be able to measure the 150 difference in one way delay for unicast and multicast on the path 151 from server to client, and also differences in delay. Servers may 152 optionally specify a timestamp. This may be useful since the unicast 153 and multicast replies can not be sent simultaneously (the delay 154 depending on the host's operating system and load). 156 3. Protocol specification 158 There are four different message types. There are Echo Request and 159 Echo Reply messages used for the actual measurements; there is an 160 Init message that SHOULD be used to initialise a ping session and 161 negotiate which group to use; and finally a Server Response message 162 that is mainly used in response to the Init message. The messages 163 MUST always be in network byte order. UDP checksums MUST always be 164 used. 166 The messages share a common format: one octet specifying the message 167 type, followed by a number of options in TLV (Type, Length and Value) 168 format. This makes the protocol easily extendible. The Init message 169 generally contains some prefix options asking the server for a group 170 from one of the specified prefixes. The server responds with a 171 Server Response message that contains the group address to use, or 172 possibly prefix options describing what multicast groups the server 173 may be able to provide. For an Echo Request the client generally 174 includes a number of options, and a server MAY simply echo the 175 contents (only changing the message type) without inspecting the 176 options if it does not support any options. This might be true for a 177 simple Multicast Ping Protocol server. However, the server SHOULD 178 add a TTL option, and there are other options that a server 179 implementation MAY support, e.g., the client may ask for certain 180 information or a specific behaviour from the server. The Echo 181 Replies (one unicast and one multicast) MUST first contain the exact 182 options from the request (in the same order), and then, immediately 183 following, any options appended by the server. A server MUST NOT 184 process unknown options, but they MUST still be included in the Echo 185 Reply. A client MUST ignore any unknown options. 187 This document defines a number of different options. Some options do 188 not require processing by servers and are simply returned unmodified 189 in the reply. There are, however, other client options that the 190 server may care about, and also server options that may be requested 191 by a client. Unless otherwise specified, an option MUST NOT be used 192 multiple times in the same message. 194 3.1. Option format 196 All options are TLVs formatted as specified below. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Value | 204 | . | 205 | . | 206 | . | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Type (2 octets) specifies the option. The different options are 210 defined below. 212 Length (2 octets) specifies the length of the value field. Depending 213 on the option type, it can be from 0 to 65535. 215 Value. The value must always be of the specified length. See the 216 respective option definitions for possible values. If the length is 217 0, the value field is not included. 219 3.2. Defined Options 221 This document defines the following options: Version (0), Client ID 222 (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), 223 Option Request Option (5), Server Information (6), TTL (9), Multicast 224 Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and 225 8 are reserved. The options are defined below. 227 Version, type 0 229 Length MUST be 1. This option MUST always be included in all 230 messages, and the value MUST be set to 2 (in decimal). Note 231 that there are older implementations of ssmping that only 232 partly follow this specification. They can be regarded as 233 version 1 and do not use this option. If a server receives a 234 message with a version other than 2 (or missing), the server 235 SHOULD (unless it supports the particular version) send a 236 Response message back with version set to 2. Client ID and 237 Sequence Number options should be echoed if present. It SHOULD 238 not include any other options. A client receiving a response 239 with a version other than 2, MUST (unless it supports the 240 particular version), stop sending requests to the server. 242 Client ID, type 1 244 Length MUST be non-zero. A client SHOULD always include this 245 option in all messages (both Init and Request). The client may 246 use any value it likes to be able to detect whether a reply is 247 a reply to its Init/Request or not. A server should treat this 248 as opaque data, and simply leave it unchanged in the reply 249 (both Server Response and Reply). The value might be a process 250 ID, perhaps process ID combined with an IP address because it 251 may receive multicast responses to queries from other clients. 252 It is left to the client implementer how to make use of this 253 option. 255 Sequence Number, type 2 257 Length MUST be 4. A client MUST always include this in Request 258 messages and MUST NOT include it in Init messages. A server 259 replying to a Request message MUST copy it into the Reply (or 260 Server Response message on error). This contains a 32 bit 261 sequence number. The values would typically start at 1 and 262 increase by one for each request in a sequence. 264 Client Timestamp, type 3 266 Length MUST be 8 bytes. A client SHOULD include this in 267 Request messages and MUST NOT include it in Init messages. A 268 server replying to a Request message MUST copy it into the 269 Reply. The timestamp specifies the time when the Request 270 message is sent. The first 4 bytes specify the number of 271 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 272 bytes specify the number of microseconds since the last second 273 since the Epoch. 275 Multicast group, type 4 277 Length MUST be greater than 2. It MAY be used in Server 278 Response messages to tell the client what group to use in 279 subsequent Request messages. It MUST be used in Request 280 messages to tell the server what group address to respond to 281 (this group would typically be previously obtained in a Server 282 Response message). It MUST be used in Reply messages (copied 283 from the Request message). It MUST NOT be used in Init 284 messages. The format of the option value is as below. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Address Family | Multicast group address... | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 292 The address family is a value 0-65535 as assigned by IANA for 293 Internet Address Families [4]. This is followed by the group 294 address. Length of the option value will be 6 for IPv4, and 18 295 for IPv6. 297 Option Request Option, type 5 299 Length MUST be greater than 1. This option MAY be used in 300 client messages (Init and Request messages). A server MUST NOT 301 send this option, except that if it is present in a Request 302 message, the server MUST echo it in replies (Reply message) to 303 the Request. This option contains a list of option types for 304 options that the client is requesting from the server. Support 305 for this option is optional for both clients and servers. The 306 length of this option will be a non-zero even number, since it 307 contains one or more option types that are two octets each. 308 The format of the option value is as below. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Option Type | Option Type | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | ..... | 317 This option might be used by the client to ask the server to 318 include options like Timestamp or Server Information. A client 319 MAY request Server Information in Init messages; it MUST NOT 320 request it in other messages. A client MAY request a Timestamp 321 in Request messages; it MUST NOT request it in other messages. 322 Subject to enforcing the above restrictions, a server 323 supporting this option SHOULD include the requested options in 324 responses (Reply messages) to the Request containing the Option 325 Request Option. The server may according to implementation or 326 local configuration, not necessarily include all the requested 327 options, or possibly none. Any options included are appended 328 to the echoed options, similar to other options included by the 329 server. 331 Server Information, type 6 333 Length MUST be non-zero. It MAY be used in Server Response 334 messages and MUST NOT be used in other messages. Support for 335 this option is optional. A server supporting this option 336 SHOULD add it in Server Response messages if and only if 337 requested by the client. The value is a UTF-8 string that 338 might contain vendor and version information for the server 339 implementation. It may also contain information on which 340 options the server supports. An interactive client MAY support 341 this option, and SHOULD then allow a user to request this 342 string and display it. 344 Reserved, type 7 346 This option code value was used by early implementations for an 347 option that is now deprecated. This option should no longer be 348 used. Clients MUST NOT use this option. Servers MUST treat it 349 as an unknown option (not process it if received, but if 350 received in a Request message, it MUST be echoed in the Reply 351 message). 353 Reserved, type 8 355 This option code value was used by early implementations for an 356 option that is now deprecated. This option should no longer be 357 used. Clients MUST NOT use this option. Servers MUST treat it 358 as an unknown option (not process it if received, but if 359 received in a Request message, it MUST be echoed in the Reply 360 message). 362 TTL, type 9 364 Length MUST be 1. This option contains a single octet 365 specifying the TTL of a Reply message. Every time a server 366 sends a unicast or multicast Reply message, it SHOULD include 367 this option specifying the TTL. This is used by clients to 368 determine the number of hops the messages have traversed. It 369 MUST NOT be used in other messages. A server SHOULD specify 370 this option if it knows what the TTL of the Reply will be. In 371 general the server can specify a specific TTL to the host 372 stack. Note that the TTL is not necessarily the same for 373 unicast and multicast. 375 Multicast Prefix, type 10 377 Length MUST be greater than 2. It MAY be used in Init messages 378 to request a group within the prefix(es), it MAY be used in 379 Server Response messages to tell the client what prefix(es) it 380 may try to obtain a group from. It MUST NOT be used in 381 Request/Reply messages. Note that this option MAY be included 382 multiple times to specify multiple prefixes. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Address Family | Prefix Length |Partial address| 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 390 The address family is a value 0-65535 as assigned by IANA for 391 Internet Address Families [4]. This is followed by a prefix 392 length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special 393 'wildcard' use discussed below), and finally a group address. 394 For any family, prefix length 0 means that any multicast 395 address from that family is acceptable. This is what we call 396 'wildcard'. The group address need only contain enough octets 397 to cover the prefix length bits (i.e., the group address would 398 have to be 3 octets long if the prefix length is 17-24, and 399 there need be no group address for the wildcard with prefix 400 length 0). Any bits past the prefix length MUST be ignored. 401 For IPv4, the option value length will be 4-7, while for IPv6, 402 it will be 4-19, and for the wildcard, it will be 3. 404 Session ID, type 11 406 Length MUST be non-zero. A server MAY include this in Server 407 Response and Reply messages. If a client receives this option 408 in a message, the client MUST echo the Session ID option in 409 subsequent Request messages, with the exact same value, until 410 the next message is received from the server. If the next 411 message from the server has no Session ID or a new Session ID 412 value, the client should do the same, either not use the 413 Session ID, or use the new value. The Session ID may help the 414 server in keeping track of clients and possibly manage per 415 client state. It is left to the server implementer to decide 416 whether it is useful and how to make use of it. 418 Server Timestamp, type 12 420 Length MUST be 8 bytes. A server supporting this option, 421 SHOULD include it in Reply messages, if requested by the 422 client. The timestamp specifies the time when the Reply 423 message is sent. The first 4 bytes specify the number of 424 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 425 bytes specify the number of microseconds since the last second 426 since the Epoch. 428 4. Packet Format 430 The format of all messages is a one octet message type, directly 431 followed by a variable number of options. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | Options ... | 437 +-+-+-+-+-+-+-+-+ . | 438 | . | 439 | . | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ..... 442 There are four message types defined. Type 81 (the character Q in 443 ASCII) specifies an Echo Request (Query). Type 65 (the character A 444 in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I 445 in ASCII) is an Init message, and type 83 (the character S in ASCII) 446 is a Server Response message. 448 The options directly follow the type octet and are not aligned in any 449 way (no spacing or padding), i.e., options might start at any octet 450 boundary. The option format is specified above. 452 5. Message types and options 454 There are four message types defined. We will now describe each of 455 the message types and which options they may contain. 457 Init, type 73 459 This message is sent by a client to request information from a 460 server. It is mainly used for requesting a group address, but 461 it may also be used to check which group prefixes the server 462 may provide groups from, or other server information. It MUST 463 include a Version option, and SHOULD include a Client ID. It 464 MAY include Option Request and Multicast Prefix Options. This 465 message is a request for a group address if and only if it 466 contains Multicast Prefix options. If multiple Prefix options 467 are included, they should be in prioritised order. I.e., the 468 server will consider the prefixes in the order they are 469 specified, and if it finds a group for a prefix, it will only 470 return that one group, not considering the remaining prefixes. 472 Server Response, type 83 474 This message is sent by a server. Either as a response to an 475 Init, or in response to a Request. When responding to Init, it 476 may provide the client with a multicast group (if requested by 477 the client), or it may provide other server information. In 478 response to a Request, the message tells the client to stop 479 sending Requests. The Version option MUST always be included. 480 Client ID and Sequence Number options are echoed if present in 481 the client message. When providing a group to the client, it 482 includes a Multicast Group option. It SHOULD include Server 483 Information and Prefix options if requested. 485 Echo Request, type 81 487 This message is sent by a client, asking the server to send 488 unicast and multicast replies. It MUST include Version, 489 Sequence Number and Multicast Group options. If the last 490 message (if any) received from the server contained a Session 491 ID, then this MUST also be included. It SHOULD include Client 492 ID and Client Timestamp options. It MAY include an Option 493 Request option. 495 Echo Reply, type 65 497 This message is sent by a server in response to an Echo Request 498 message. This message is always sent in pairs, one as unicast 499 and one as multicast. The contents of the messages are mostly 500 the same. The server echoes most of the options from the Echo 501 Request (any options in the Request that are unsupported by the 502 server, are always echoed). The only option that may be 503 present in the Request which is not always echoed, is the 504 Session ID option. In most cases the server would echo it, but 505 the server may also change or omit it. The two Reply messages 506 SHOULD both contain a TTL option (not necessarily equal), and 507 both SHOULD also contain Server Timestamps (not necessarily 508 equal) when requested. 510 For the reader's convenience we provide the matrix below, showing 511 what options can go in what messages. 513 Option / Message Type | Init | Server Response | Request | Reply | 514 -----------------------------------------------------------------+ 515 Version (0) | MUST | ECHO | MUST | ECHO | 516 Client ID (1) |SHOULD| ECHO | SHOULD | ECHO | 517 Sequence Number (2) | NOT | ECHO | MUST | ECHO | 518 Client Timestamp (3) | NOT | NOT | SHOULD | ECHO | 519 Multicast Group (4) | NOT | MAY | MUST | ECHO | 520 Option Request (5) | MAY | NOT | MAY | ECHO | 521 Server Information (6)| NOT | RQ | NOT | NOT | 522 Reserved (7) | NOT | NOT | NOT | ECHO | 523 Reserved (8) | NOT | NOT | NOT | ECHO | 524 TTL (9) | NOT | NOT | NOT |SHOULD | 525 Multicast Prefix (10) | MAY | MAY | NOT | NOT | 526 Session ID (11) | NOT | MAY | ECHO | MAY | 527 Server Timestamp (12) | NOT | NOT | NOT | RQ | 529 NOT means that the option MUST NOT be included. ECHO for a server 530 means that if the option is specified by the client, then the server 531 MUST echo the option in the response, with the exact same option 532 value. ECHO for a client means that it MUST echo the option it got 533 in the last message from the server in any subsequent messages it 534 sends. RQ means that the server SHOULD include the option in the 535 response, when requested by the client using the Option Request 536 option. 538 6. Client Behaviour 540 We will consider how a typical interactive client using the above 541 protocol would behave. A client need only require a user to specify 542 the unicast address of the server. It can then send an Init message 543 with a prefix option containing the desired address family and zero 544 prefix length (wildcard entry). The server is then free to decide 545 which group, from the specified family, it should return. A client 546 may also allow a user to specify group address(es) or prefix(es) (for 547 IPv6, the user may only be required to specify a scope or an RP 548 address, from which the client can construct the desired prefix, 549 possibly embedded-RP). From this the client can specify one or more 550 prefix options in an Init message to tell the server which address it 551 would prefer. If the user specifies a group address, that can be 552 encoded as a prefix of maximal length (e.g. 32 for IPv4). The prefix 553 options are in prioritised order, i.e., the client should put the 554 most preferred prefix first. 556 If the client receives a Server Response message containing a group 557 address it can start sending Request messages, see the next 558 paragraph. If there is no group address option, it would typically 559 exit with an error message. The server may have included some prefix 560 options in the Server Response. The client may use this to provide 561 the user some feedback on what prefixes or scopes are available. 563 Assuming the client got a group address in a Server Response, it can 564 start pinging. Before it does that, it should let the user know 565 which group is being used. Normally, a client should send at most 566 one ping request per second. When sending ping Requests, the client 567 must always include the group option. If the last message from the 568 server contained a Session ID, then it must also include that with 569 the same value. Typically it would receive a Session ID in a Server 570 Response together with the group address, and then the ID would stay 571 the same during the entire ping sequence. However, if for instance 572 the server process is restarted, it may still be possible to continue 573 pinging but the Session ID may be changed by the server. Hence a 574 client implementation must always use the last Session ID it 575 received, and not necessarily the one from the Server Response 576 message. If a client receives a Server Response message in response 577 to a Request message (that is, a Server Response message containing a 578 sequence number), this means there is an error and it should stop 579 sending Requests. This may for instance happen after server restart. 581 The client may allow the user to request server information. If the 582 user requests server information, the client can send an Init message 583 with no prefix options, but with an Option Request Option, requesting 584 the server to return a Server Information option. The server will 585 return server information if supported, and it may also return a list 586 of prefixes it supports. It will however not return a group address. 587 The client may also try to obtain only a list of prefixes by sending 588 an Init message with no prefixes and not requesting any specific 589 options. 591 Note that a client may pick a multicast group and send Request 592 messages without first going through the Init - Server Response 593 negotiation. If this is supported by the server and the server is 594 okay with the group used, the server can then send Reply messages as 595 usual. If the server is not okay, it will send a Server Response 596 telling the client to stop. 598 7. Server Behaviour 600 We will consider how a typical server using the above protocol would 601 behave. First we consider how to respond to Init messages. If the 602 Init message contains prefix options, the server should look at them 603 in order and see if it can assign a multicast address from the given 604 prefix. The server would be configured, possibly have a default, 605 specifying which groups it can offer. It may have a large pool just 606 picking a group at random, possibly choose a group based on hashing 607 of the clients IP address or identifier, or just use a fixed group. 608 It is left to the server to decide whether it should allow the same 609 address to be used simultaneously by multiple clients. If the server 610 finds a suitable group address, it returns this in a group option in 611 a Server Response message. The server may additionally include a 612 Session ID. This may help the server if it is to keep some state, 613 for instance for making sure the client uses the group it got 614 assigned. A good Session ID would be a random byte string that is 615 hard to predict. If the server cannot find a suitable group address, 616 or if there were no prefixes in the Init message, it may send a 617 Server Response message containing prefix options listing what 618 prefixes may be available to the client. Finally, if the Init 619 message requests the Server Information option, it should include 620 that. 622 When the server receives a Request message, it may first check that 623 the group address and Session ID (if provided) are valid. If the 624 server is satisfied, it will send a unicast Reply message back to the 625 client, and also a multicast Reply message to the group address. The 626 Reply messages contain the exact options and in the same order, as in 627 the Request, and after that the server adds a TTL option and 628 additional options if needed. E.g., it may add a timestamp if 629 requested by the client. If the server is not happy with the Request 630 (bad group address or Session ID, request is too large etc), it may 631 send a Server Response message asking the client to stop. This 632 Server Response must echo the sequence number from the Request. This 633 Server Response may contain group prefixes from which a client can 634 try to request a group address. The unicast and multicast Reply 635 messages have identical UDP payload apart from possibly TTL and 636 timestamp option values. 638 Note that the server may receive Request messages with no prior Init 639 message. This may happen when the server restarts or if a client 640 sends a Request with no prior Init message. The server may go ahead 641 and respond if it is okay with the group used. In the responses it 642 may add a Session ID which will then be in later requests from the 643 client. If the group is not okay, the server sends back a Server 644 Response. The Response is just as if it got an Init message with no 645 prefixes. If the server adds or modifies the SessionID in replies, 646 it must use the exact same SessionID in the unicast and multicast 647 replies. 649 By default, a server should perform rate limiting and for a given 650 client, respond to at most one Request message per second. A leaky 651 bucket algorithm is suggested, where the rate can be higher for a few 652 seconds, but the average rate should by default be limited to a 653 message per client per second. 655 8. Recommendations for Implementers 657 The protocol as specified is fairly flexible and leaves a lot of 658 freedom for implementers. In this section we present some 659 recommendations. 661 Server administrators should be able to configure one or multiple 662 group prefixes in a server implementation. When deploying servers on 663 the Internet and in other environments, the server administrator 664 should be able to restrict the server to respond to only a few 665 multicast groups which should not be currently used by multicast 666 applications. A server implementation should also provide 667 flexibility for an administrator to apply various policies to provide 668 one or multiple group prefixes to specific clients. One such policy 669 could be to use the client IP address if it can be trusted. 671 Servers must perform rate limiting, to guard against this protocol 672 being used for DoS attacks. By default, clients should send at most 673 one request per second, and servers should perform rate limiting if a 674 client sends more frequent requests. Server implementations should 675 provide administrative control of which client IP addresses to serve, 676 and may also allow certain clients to perform more rapid requests. 677 Implementers of applications/tools using this protocol should 678 consider the UDP guidelines [6], in particular if clients are to 679 send, or servers are to accept, requests at rates exceeding one per 680 second. 682 9. Acknowledgements 684 The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and 685 Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source 686 Specific Multicast, and also the Internet Draft 687 draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with 688 several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave 689 Thaler have contributed in different ways to the implementation of 690 the ssmping tools at [5]. Many people in communities like TERENA, 691 Internet2 and the M6Bone have used early implementations of ssmping 692 and provided feedback that have influenced the current protocol. 693 Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Alfred 694 Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil 695 Sarac, Pekka Savola, Trond Skjesol and Cao Wei for reviewing and 696 providing feedback on this draft. In particular Hugo, Gorry and 697 Bharat have provided lots of input on several revisions of the draft 699 10. IANA Considerations 701 IANA is requested to provide a UDP port number for use by this 702 protocol, and also to provide registries for message and option 703 types. 705 There should be a message types registry. Message types are in the 706 range 0-255. Message types 0-191 can be assigned referencing an RFC 707 (it may be Informational), while types 192-255 are freely available 708 for experimental, private or vendor specifc use. The registry should 709 include the messages defined in Section 5 711 There should also be an option type registry. Option types 0-49151 712 can be assigned referencing an RFC (it may be Informational), while 713 types 49152-65535 are freely available for experimental, private or 714 vendor specifc use. The registry should include the options defined 715 in Section 3.2. 717 11. Security Considerations 719 There are some security issues to consider. One is that a host may 720 send a request with an IP source address of another host, and make an 721 arbitrary multicast ping server on the Internet send packets to this 722 other host. This behaviour is fairly harmless. The worst case is if 723 the host receiving the unicast replies also happen to be joined to 724 the multicast group used. In this case, there would be an 725 amplification effect where the host receives twice as many replies as 726 there are requests sent. 728 Server implementations should allow administrators to restrict which 729 groups a server responds to, and also perform rate limiting. This is 730 discussed in Section 8). 732 12. References 733 12.1. Normative References 735 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 736 Levels", BCP 14, RFC 2119, March 1997. 738 [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 739 August 1980. 741 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 742 Specification", RFC 2460, December 1998. 744 [4] "IANA, Address Family Numbers", 745 . 747 12.2. Informative References 749 [5] "ssmping implementation", 750 . 752 [6] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for 753 Application Designers", draft-ietf-tsvwg-udp-guidelines-05 (work 754 in progress), February 2008. 756 Author's Address 758 Stig Venaas 759 UNINETT 760 Trondheim NO-7465 761 Norway 763 Email: venaas@uninett.no 765 Full Copyright Statement 767 Copyright (C) The IETF Trust (2008). 769 This document is subject to the rights, licenses and restrictions 770 contained in BCP 78, and except as set forth therein, the authors 771 retain all their rights. 773 This document and the information contained herein are provided on an 774 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 775 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 776 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 777 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 778 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 779 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 781 Intellectual Property 783 The IETF takes no position regarding the validity or scope of any 784 Intellectual Property Rights or other rights that might be claimed to 785 pertain to the implementation or use of the technology described in 786 this document or the extent to which any license under such rights 787 might or might not be available; nor does it represent that it has 788 made any independent effort to identify any such rights. Information 789 on the procedures with respect to rights in RFC documents can be 790 found in BCP 78 and BCP 79. 792 Copies of IPR disclosures made to the IETF Secretariat and any 793 assurances of licenses to be made available, or the result of an 794 attempt made to obtain a general license or permission for the use of 795 such proprietary rights by implementers or users of this 796 specification can be obtained from the IETF on-line IPR repository at 797 http://www.ietf.org/ipr. 799 The IETF invites any interested party to bring to its attention any 800 copyrights, patents or patent applications, or other proprietary 801 rights that may cover technology that may be required to implement 802 this standard. Please address the information to the IETF at 803 ietf-ipr@ietf.org. 805 Acknowledgment 807 Funding for the RFC Editor function is provided by the IETF 808 Administrative Support Activity (IASA).