idnits 2.17.1 draft-ietf-mboned-ssmping-03.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 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. 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 'MUST not' in this paragraph: Type 7, Reserved. This option code value was used by early implementations for an option that is now deprecated. This option should no longer be used. Clients MUST not use this option. Servers MUST treat it as an unknown option (not process it if received, but if received in a Request message, it MUST be echoed back in the Reply message). == 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 'MUST not' in this paragraph: Type 8, Reserved. This option code value was used by early implementations for an option that is now deprecated. This option should no longer be used. Clients MUST not use this option. Servers MUST treat it as an unknown option (not process it if received, but if received in a Request message, it MUST be echoed back in the Reply message). -- 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 12, 2008) is 5911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'TBD' on line 107 ** 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 (~~), 4 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 12, 2008 5 Expires: August 15, 2008 7 Multicast Ping Protocol 8 draft-ietf-mboned-ssmping-03 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 15, 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 62 5. Message types and options . . . . . . . . . . . . . . . . . . 10 63 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 10 64 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 70 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 Intellectual Property and Copyright Statements . . . . . . . . . . 16 74 1. Introduction 76 The Multicast Ping Protocol specified in this document allows for 77 checking multicast connectivity. In addition to checking reception 78 of multicast (SSM or ASM), the protocol can provide related 79 information like multicast tree setup time, the number of hops the 80 packets have traveled, as well as packet delay and loss. This 81 functionality resembles, in part, the ICMP Echo Request/Reply 82 mechanism, but uses UDP (RFC 768 [2] and RFC 2460 [3]) and requires 83 both a client and a server implementing this protocol. 85 The protocol here specified is based on the actual implementation of 86 the ssmping and asmping tools [5] which are widely used by the 87 Internet community 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. 93 The typical protocol usage is as follows: A server runs continuously 94 to serve requests from clients. A client can test the multicast 95 reception from this server, provided it knows a unicast address of 96 the server. It will then send a unicast message to the server asking 97 for a group to use. Optionally the user may have requested a 98 specific group or scope, in which case the client will ask for a 99 group matching the user's request. The server will respond with a 100 group to use, or an error if no group is available. Next, for ASM, 101 the client joins an ASM group G, while for SSM it joins a channel 102 (S,G). Here G is the group specified by the server, and S is the 103 unicast address used to reach the server. 105 After joining the channel, the client unicasts multicast ping 106 requests to the server. The requests are sent using UDP with 107 destination port set to the standardised multicast ping port [TBD]. 108 The requests are sent periodically, e.g., once per second, to the 109 server. The requests contain a sequence number, and typically a 110 timestamp. The requests are echoed back by the server, except the 111 server may add a few options. For each request, the server sends two 112 replies. One reply is unicast to the source IP address and source 113 UDP port of the request, while another is multicast back to requested 114 multicast group G and the source UDP port of the request. Both the 115 replies are sent from the same port from which the request was 116 received. The server should specify the TTL used for both the 117 unicast and multicast messages (we recommend at least 64) and 118 includes a TTL option for the client to compute the number of hops. 119 The client should leave the channel/group when it has finished its 120 measurements. 122 By use of this protocol, a client can obtain information about 123 several multicast delivery characteristics. First, by receiving 124 unicast replies, it can verify that the server is receiving the 125 unicast requests, is operational and responding. Hence, provided 126 that the client receives unicast replies, a failure to receive 127 multicast indicates either a multicast problem or a multicast 128 administrative restriction. If it does receive multicast, it knows 129 not only that it can receive; it may also estimate the amount of time 130 it took to establish the multicast tree (at least if it is in the 131 range of seconds), whether there are packet drops, and the length and 132 variation of Round Trip Times (RTT). For unicast, the RTT is the 133 time from when the unicast request is sent to when the reply is 134 received. The measured multicast RTT also references the client's 135 unicast request. By use of the TTL option specifying the TTL of the 136 replies when they are originated, the client can also determine the 137 number of router hops it is from the source. Since similar 138 information is obtained in the unicast replies, the host may compare 139 its multicast and unicast results and is able to check for 140 differences in the number of hops, RTT, etc. The number of multicast 141 hops and changes in the number of hops over time, may also reveal 142 details about the multicast tree and multicast tree changes. E.g., 143 with PIM-SM one may be able to tell whether the forwarding is on a 144 shared or source-specific tree and when an eventual switch occurs. 145 Provided that the server sends the unicast and multicast replies 146 nearly simultaneously, the client may also be able to measure the 147 difference in one way delay for unicast and multicast on the path 148 from server to client, and also differences in delay. Servers may 149 optionally specify a timestamp. This may be useful since the unicast 150 and multicast replies can not be sent simultaneously (the delay 151 depending on the host's operating system and load). 153 3. Protocol specification 155 There are four different message types. There are Echo Request and 156 Echo Reply messages used for the actual measurements; there is an 157 Init message that SHOULD be used to initialise a ping session and 158 negotiate which group to use; and finally a Server Response message 159 that is mainly used in response to the Init message. The messages 160 MUST always be in network byte order. UDP checksums MUST always be 161 used. 163 The messages share a common format: one octet specifying the message 164 type, followed by a number of options in TLV (Type, Length and Value) 165 format. This makes the protocol easily extendible. The Init message 166 generally contains some prefix options asking the server for a group 167 from one of the specified prefixes. The server responds with a 168 Server Response message that contains the group address to use, or 169 possibly prefix options describing what multicast groups the server 170 may be able to provide. For an Echo Request the client generally 171 includes a number of options, and a server may simply echo the 172 content back (only changing the message type), without inspecting the 173 options. However, the server SHOULD add a TTL option, and there are 174 other options that a server implementation MAY support, e.g., the 175 client may ask for certain information or a specific behaviour from 176 the server. The Echo Replies (one unicast and one multicast) MUST 177 first contain the exact options from the request (in the same order), 178 and then, immediately following, any options appended by the server. 179 A server MUST NOT process unknown options, but they MUST still be 180 included in the Echo Reply. A client MUST ignore any unknown 181 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 Version, type 0. Length MUST be 1. This option MUST always be 218 included in all messages, and the value MUST be set to 2 (in 219 decimal). Note that there are older implementations of ssmping that 220 only partly follow this specification. They can be regarded as 221 version 1 and do not use this option. 223 Client ID, type 1. Length MUST be non-zero. A client SHOULD always 224 include this option in all messages (both Init and Request). The 225 client may use any value it likes to be able to detect whether a 226 reply is a reply to its Init/Request or not. A server should treat 227 this as opaque data, and simply leave it unchanged in the reply (both 228 Server Response and Reply). The value might be a process ID, perhaps 229 process ID combined with an IP address because it may receive 230 multicast responses to queries from other clients. It is left to the 231 client implementor how to make use of this option. 233 Sequence number, type 2. Length MUST be 4. A client MUST always 234 include this in Request messages and MUST NOT include it in Init 235 messages. A server replying to a Request message MUST copy it into 236 the Reply (or Server Response message on error). This contains a 32 237 bit sequence number. The values would typically start at 1 and 238 increase by one for each request in a sequence. 240 Client Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD 241 include this in Request messages and MUST NOT include it in Init 242 messages. A server replying to a Request message MUST copy it into 243 the Reply. The timestamp specifies the time when the Request message 244 is sent. The first 4 bytes specify the number of seconds since the 245 Epoch (beginning of the year 1970). The next 4 bytes specify the 246 number of microseconds since the last second since the Epoch. 248 Multicast group, type 4. Length MUST be greater than 1. It MAY be 249 used in Server Response messages to tell the client what group to use 250 in subsequent Request messages. It MUST be used in Request messages 251 to tell the server what group address to respond to (this group would 252 typically be previously obtained in a Server Response message). It 253 MUST be used in Reply messages (copied from the Request message). It 254 MUST NOT be used in Init messages. The format of the option value is 255 as below. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Address Family | Multicast group address... | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 263 The address family is a value 0-65535 as assigned by IANA for 264 Internet Address Families [4]. This is followed by the group 265 address. Length of the option value will be 6 for IPv4, and 18 for 266 IPv6. 268 Option Request Option, type 5. Length MUST be greater than 1. This 269 option MAY be used in client messages (Init and Request messages). A 270 server MUST NOT send this option, except that if it is present in a 271 Request message, the server MUST include it in a reply (Reply 272 message) to the Request. This option contains a list of option types 273 for options that the client is requesting from the server. Support 274 for this option is optional for both clients and servers. The length 275 of this option will be a non-zero even number, since it contains one 276 or more option types that are two octets each. The format of the 277 option value is as below. 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Option Type | Option Type | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | ..... | 286 This option might be used by the client to ask the server to include 287 options like Timestamp or Server Information. A client MAY request 288 Server Information in Init messages; it MUST NOT request it in other 289 messages. A client MAY request a Timestamp in Request messages; it 290 MUST NOT request it in other messages. 292 Server Information, type 6. Length MUST be non-zero. It MAY be used 293 in Server Response messages and MUST NOT be used in other messages. 294 Support for this option is optional. A server supporting this option 295 SHOULD add it in Server Response messages if and only if requested by 296 the client. The value is a UTF-8 string that might contain vendor 297 and version information for the server implementation. It may also 298 contain information on which options the server supports. An 299 interactive client MAY support this option, and SHOULD then allow a 300 user to request this string and display it. 302 Type 7, Reserved. This option code value was used by early 303 implementations for an option that is now deprecated. This option 304 should no longer be used. Clients MUST not use this option. Servers 305 MUST treat it as an unknown option (not process it if received, but 306 if received in a Request message, it MUST be echoed back in the Reply 307 message). 309 Type 8, Reserved. This option code value was used by early 310 implementations for an option that is now deprecated. This option 311 should no longer be used. Clients MUST not use this option. Servers 312 MUST treat it as an unknown option (not process it if received, but 313 if received in a Request message, it MUST be echoed back in the Reply 314 message). 316 TTL, type 9. Length MUST be 1. This option contains a single octet 317 specifying the TTL of a Reply message. Every time a server sends a 318 unicast or multicast Reply message, it SHOULD include this option 319 specifying the TTL. This is used by clients to determine the number 320 of hops the messages have traversed. It MUST NOT be used in other 321 messages. A server SHOULD specify this option if it knows what the 322 TTL of the Reply will be. In general the server can specify a 323 specific TTL to the host stack. Note that the TTL is not necessarily 324 the same for unicast and multicast. 326 Multicast prefix, type 10. Length MUST be greater than 2. It MAY be 327 used in Init messages to request a group within the prefix(es), it 328 MAY be used in Server Response messages to tell the client what 329 prefix(es) it may try to obtain a group from. It MUST NOT be used in 330 Request/Reply messages. Note that this option MAY be included 331 multiple times to specify multiple prefixes. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Address Family | Prefix Length |Partial address| 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 339 The address family is a value 0-65535 as assigned by IANA for 340 Internet Address Families [4]. This is followed by a prefix length 341 (0-32 for IPv4, 0-128 for IPv6), and finally a group address. The 342 group address need only contain enough octets to cover the prefix 343 length bits (e.g., there need be no group address if the prefix 344 length is 0, the group address would have to be 3 octets long if the 345 prefix length is 17-24). Any bits past the prefix length MUST be 346 ignored. For IPv4 the option value length will be 3-7, while for 347 IPv6 3-19. 349 Session ID, type 11. Length MUST be non-zero. A server MAY include 350 this in Server Response and Reply messages. If a client receives 351 this option in a message, the client MUST echo the Session ID option 352 in subsequent Reply messages, with the exact same value, until the 353 next message is received from the server. If the next message from 354 the server has no Session ID or a new Session ID value, the client 355 should do the same, either not use the Session ID, or use the new 356 value. The Session ID may help the server in keeping track of 357 clients and possibly manage client state. It is left to the server 358 implementer to decide whether it is useful and how to make use of it. 360 Server Timestamp, type 12. Length MUST be 8 bytes. A server 361 supporting this option, SHOULD include it in Reply messages, if 362 requested by the client. The timestamp specifies the time when the 363 Reply message is sent. The first 4 bytes specify the number of 364 seconds since the Epoch (beginning of the year 1970). The next 4 365 bytes specify the number of microseconds since the last second since 366 the Epoch. 368 4. Packet Format 370 The format of all messages is a one octet message type, directly 371 followed by a variable number of options. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Type | Option | 377 +-+-+-+-+-+-+-+-+ . | 378 | . | 379 | . | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Option | 382 | . | 383 | . | 384 | . | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 . 387 . 388 . 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Option | 391 | . | 392 | . | 393 | . | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 There are four message types defined. Type 81 (the character Q in 397 ASCII) specifies an Echo Request (Query). Type 65 (the character A 398 in ASCII) specifies an Echo Response (Answer). Type 73 (the 399 character I in ASCII) is an Init message, and type 83 (the character 400 S in ACII) is a Server Response message. 402 The options directly follow the type octet and are not aligned in any 403 way (no spacing or padding), i.e., options might start at any octet 404 boundary. The option format is specified above. 406 5. Message types and options 408 For the readers convenience we provide the matrix below, showing what 409 options can go in what messages. 411 Option / Message Type | Init | Server Response | Request | Reply | 412 -----------------------------------------------------------------+ 413 Version (0) | MUST | ECHO | MUST | ECHO | 414 Client ID (1) |SHOULD| ECHO | SHOULD | ECHO | 415 Sequence number (2) | NOT | ECHO | MUST | ECHO | 416 Client Timestamp (3) | NOT | NOT | SHOULD | ECHO | 417 Multicast group (4) | NOT | MAY | MUST | ECHO | 418 Option Request (5) | MAY | NOT | MAY | ECHO | 419 Server Information (6)| NOT | RQ | NOT | NOT | 420 Reserved (7) | NOT | NOT | NOT | ECHO | 421 Reserved (8) | NOT | NOT | NOT | ECHO | 422 TTL (9) | NOT | NOT | NOT |SHOULD | 423 Multicast prefix (10) | MAY | MAY | NOT | NOT | 424 Session ID (11) | NOT | MAY | ECHO | MAY | 425 Server Timestamp (12) | NOT | NOT | NOT | RQ | 427 NOT means that the option MUST NOT be included. ECHO for a server 428 means that if the option is specified by the client, then the server 429 MUST echo the option back in the response, with the exact same option 430 value. ECHO for a client means that it MUST echo the option it got 431 in the last message from the server in any subsequent messages it 432 sends. RQ means that the server SHOULD include the option in the 433 response, when requested by the client using the Option Request 434 option. 436 6. Client Behaviour 438 We will consider how a typical interactive client using the above 439 protocol would behave. A client need only require a user to specify 440 the unicast address of the server. It can then send an Init message 441 with a prefix option containing the desired address family and zero 442 prefix length. The server is then free to decide which group it 443 should return. A client may also allow a user to specify a group 444 address(es) or prefix(es) (for IPv6, the user may only be required to 445 specify a scope or an RP address, from which the client can construct 446 the desired prefix, possibly embedded-RP). From this the client can 447 specify one or more prefix options in an Init message to tell the 448 server which address it would prefer. If the user specifies a group 449 address, that can be encoded as a prefix of maximal length (e.g. 32 450 for IPv4). The prefix options are in prioritised order, i.e., the 451 client should put the most preferred prefix first. 453 If the client receives a Server Response message containing a group 454 address it can start sending Request messages, see the next 455 paragraph. If there is no group address option, it would typically 456 exit with an error message. The server may have included some prefix 457 options in the Server Response. The client may use this to provide 458 the user some feedback on what prefixes or scopes are available. 460 Assuming the client got a group address in a Server Response it can 461 start pinging. Before it does that it should let the user know which 462 group is being used. Normally, a client should send at most one ping 463 request per second. When sending ping Requests the client must 464 always specifiy the group option. If the last message from the 465 server contained a Session ID, then it must also include that with 466 the same value. Typically it would receive a Session ID in a Server 467 Response together with the group address, and then the ID would stay 468 the same during the entire ping sequence. However, if for instance 469 the server process is restarted, it may still be possible to continue 470 pinging but the Session ID may be changed by the server. Hence a 471 client implementation must always use the last Session ID it 472 received, and not necessarily the one from the Server Response 473 message. If a client receives a Server Response message in response 474 to a Request message (that is, a Server Response message containing a 475 sequence number), this means there is an error and it should stop 476 sending Requests. This may for instance happen after server restart. 478 The client may have an option for the user to obtain server 479 information. If the user asks for server information, the client can 480 send an Init message with no prefix options, but with an Option 481 Request Option, requesting the server to return a Server Information 482 option. The server will return server information if supported, and 483 it may also return a list of prefixes it supports. It will however 484 not return a group address. The client may also try to obtain only a 485 list of prefixes by sending an Init message with no prefixes and not 486 requesting any specific options. 488 Note that a client may pick a multicast group and send Request 489 messages without first going through the Init - Server Response 490 negotiation. If this is supported by the server and the server is 491 okay with the group used, the server can then send Reply messages as 492 usual. If the server is not okay, it will send a Server Response 493 telling the client to stop and possibly pick a new group. 495 7. Server Behaviour 497 We will consider how a typical server using the above protocol would 498 behave. First we consider how to respond to Init messages. If the 499 Init message contains prefix options, the server should look at them 500 in order and see if it can assign a multicast address in the given 501 range. The server would be configured, possibly have a default, 502 specifying which groups it can offer. It may have a large pool just 503 picking a group at random, possibly choose a group based on hashing 504 of the clients IP address or identifier, or just use a fixed group. 505 It is left to the server to decide whether it should allow the same 506 address to be used simultaneously by multiple clients. If the server 507 finds a suitable group address, it returns this in a group option in 508 a Server Response message. The server may additionally include a 509 Session ID. This may help the server if it is to keep some state, 510 for instance for making sure the client uses the group it got 511 assigned. A good Session ID would be a random byte string that is 512 hard to predict. If the server cannot find a suitable group address, 513 or if there were no prefixes in the Init message, it may send a 514 Server Response message containing prefix options listing what 515 prefixes may be available to the client. Finally, if the Init 516 message requests the Server Information option, it should include 517 that. 519 When the server receives a Request message, it may first check that 520 the group address and Session ID (if provided) are valid. If the 521 server is satisfied it will send a unicast Reply message back to the 522 client, and also a multicast Reply message to the group address. The 523 Reply messages contain the exact options and in the same order, as in 524 the Request, and after that the server adds a TTL option and 525 additional options if needed. E.g., it may add a timestamp if 526 requested by the client. If the server is not happy with the Request 527 (bad group address or Session ID, request is too large etc), it may 528 send a Server Response message asking the client to stop. This 529 Server Response must echo the sequence number from the Request. This 530 Server Response may contain which prefixes the client can try to 531 request addresses from. The unicast and multicast Reply messages 532 have identical UDP payload apart from possibly TTL and timestamp 533 option values. 535 Note that the server may receive Request messages with no prior Init 536 message. This may happen when the server restarts or if a client 537 sends a Request with no prior Init message. The server may go ahead 538 and respond if it is okay with the group used. In the responses it 539 may add a Session ID which will then be in later requests from the 540 client. If the group is not okay, the server sends back a Server 541 Response. The Response is just as if it got an Init message with no 542 prefixes. If the server adds or modifies the SessionID in replies, 543 it must use the exact same SessionID in the unicast and multicast 544 replies. 546 By default a server should perform rate limiting and for a given 547 client, respond to at most one Request message per second. A leaky 548 bucket algorithm is suggested, where the rate can be higher for a few 549 seconds, but the average rate should by default be limited to a 550 message per client per second. 552 8. Acknowledgements 554 The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and 555 Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source 556 Specific Multicast, and also the Internet Draft 557 draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with 558 several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave 559 Thaler have contributed in different ways to the implementation of 560 the ssmping tools at [5]. Many people in communities like TERENA, 561 Internet2 and the M6Bone have used early implementations of ssmping 562 and provided feedback that have influenced the current protocol. 563 Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui, 564 Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, 565 Trond Skjesol and Cao Wei for reviewing and providing feedback on 566 this draft. In particular Hugo, Gorry and Bharat have provided lots 567 of input on several revisions of the draft 569 9. IANA Considerations 571 IANA is requested to provide a UDP port number for use by this 572 protocol, and also to provide registries for message and option 573 types. 575 There should be a message types registry. Message types are in the 576 range 0-255. Message types 0-191 can be assigned referencing an RFC 577 (it may be Informational), while types 192-255 are freely available 578 for experimental, private or vendor specifc use. 580 There should also be an option type registry. Option types 0-49151 581 can be assigned referencing an RFC (it may be Informational), while 582 types 49152-65535 are freely available for experimental, private or 583 vendor specifc use. 585 10. Security Considerations 587 There are some security issues to consider. One is that a host may 588 send a request with an IP source address of another host, and make an 589 arbitrary multicast ping server on the Internet send packets to this 590 other host. This behaviour is fairly harmless. The worst case is if 591 the host receiving the unicast replies also happen to be joined to 592 the multicast group used. In this case, there would be an 593 amplification effect where the host receives twice as many replies as 594 there are requests sent. 596 Servers should perform rate limiting, to guard against this function 597 being used as a DoS attack. By default, clients should send at most 598 one request per second, and servers should perform rate limiting if a 599 client sends more frequent requests. Server implementations should 600 provide administrative control of which client IP addresses to serve, 601 and may also allow certain clients to perform more rapid requests. 602 Implementors of applications/tools using this protocol should 603 consider the UDP guidelines [6], in particular if clients are to 604 send, or servers are to accept, requests at rates exceeding one per 605 second. 607 A client should use the client ID option to distinguish replies to 608 its own requests from replies that might be to other requests. 610 11. References 612 11.1. Normative References 614 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 615 Levels", BCP 14, RFC 2119, March 1997. 617 [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 618 August 1980. 620 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 621 Specification", RFC 2460, December 1998. 623 [4] "IANA, Address Family Numbers", 624 . 626 11.2. Informative References 628 [5] "ssmping implementation", 629 . 631 [6] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for 632 Application Designers", draft-ietf-tsvwg-udp-guidelines-05 (work 633 in progress), February 2008. 635 Author's Address 637 Stig Venaas 638 UNINETT 639 Trondheim NO-7465 640 Norway 642 Email: venaas@uninett.no 644 Full Copyright Statement 646 Copyright (C) The IETF Trust (2008). 648 This document is subject to the rights, licenses and restrictions 649 contained in BCP 78, and except as set forth therein, the authors 650 retain all their rights. 652 This document and the information contained herein are provided on an 653 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 654 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 655 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 656 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 657 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 658 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 660 Intellectual Property 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed to 664 pertain to the implementation or use of the technology described in 665 this document or the extent to which any license under such rights 666 might or might not be available; nor does it represent that it has 667 made any independent effort to identify any such rights. Information 668 on the procedures with respect to rights in RFC documents can be 669 found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use of 674 such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository at 676 http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 this standard. Please address the information to the IETF at 682 ietf-ipr@ietf.org. 684 Acknowledgment 686 Funding for the RFC Editor function is provided by the IETF 687 Administrative Support Activity (IASA).