idnits 2.17.1 draft-ietf-mboned-ssmping-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 632. 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, and Servers MUST ignore it. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 2007) is 6003 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 Summary: 1 error (**), 0 flaws (~~), 2 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 H. Santos 5 Expires: May 22, 2008 NEC Europe Ltd. 6 November 19, 2007 8 ssmping Protocol 9 draft-ietf-mboned-ssmping-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 22, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The ssmping protocol specified in this document allows for checking 43 whether one can receive multicast, both Source-Specific Multicast 44 (SSM) and Any-Source Multicast (ASM), as well as to obtain additional 45 multicast related information. 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 . . . . . . . . . . . . . . . . . . . . . 5 61 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Message types and options . . . . . . . . . . . . . . . . . . 9 63 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 10 64 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 11 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 Intellectual Property and Copyright Statements . . . . . . . . . . 15 74 1. Introduction 76 The ssmping protocol specified in this document allows for checking 77 multicast connectivity. Not only reception of multicast (SSM or 78 ASM), but can also provide other information like multicast tree 79 setup time, the number of hops the packets have traveled, as well as 80 the packet delay and loss. This functionality resembles, in part, 81 the ICMP Echo Request/Reply infrastructure, but uses UDP and requires 82 both a client and a server implementing this protocol. 84 The protocol here specified is based on the actual implementation of 85 the ssmping and asmping tools [3] 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 usage of an ssmping/asmping session is as follows. A 93 server runs continuously to serve requests from clients. When a user 94 decides to verify the multicast reception from a specific server 95 (knowing one of the server's unicast addresses is required), the 96 client will send a unicast message to the server asking for a group 97 to use. Optionally the user may have requested a specific group or 98 scope, in which case the client will ask for a group matching the 99 user's request. The server will respond with a group to use, or an 100 error if no group is available. Next, the client joins an SSM 101 channel (S,G) where S is a unicast address of the target server, or 102 an ASM group G, where G is the group specified by the server. 104 After joining the channel, the client unicasts ssmping requests to 105 the server. The requests are sent using UDP with destination port 106 set to the standardised ssmping port [TBD]. The requests are sent 107 periodically, e.g., once per second, to the server. The requests 108 contain a sequence number, and typically a timestamp. The requests 109 are echoed back by the server, except the server may add a few 110 options. To each request, the server sends two replies. One as 111 unicast back to the port and address the request was sent from, and 112 also one as multicast back to the port from which the request 113 originated with the requested group G as destination address. The 114 server should specify the TTL used for both the unicast and multicast 115 messages (we recommend at least 64) and includes a TTL option for the 116 client to compute the number of hops. The client should leave the 117 channel/group when it has finished its measurements. 119 By use of this protocol, a client can obtain information about 120 several multicast delivery characteristics. First, by receiving 121 unicast replies, it can verify that the server is receiving the 122 unicast requests, is operational and responding. Hence, provided 123 that the client receives unicast replies, a failure to receive 124 multicast indicates either a multicast problem or a multicast 125 administrative restriction. If it does receive multicast, it knows 126 not only that it can receive; it may also estimate the amount of time 127 it took to establish the multicast tree (at least if it is in the 128 range of seconds), whether there are packet drops, and the length and 129 variation of Round Trip Times (RTT). For unicast, the RTT is the 130 time from when the unicast request is sent to when the reply is 131 received. The measured multicast RTT also references the client's 132 unicast request. By use of the TTL option specifying the TTL of the 133 replies when they are originated, the client can also determine the 134 number of router hops it is from the source. Since similar 135 information is obtained in the unicast replies, the host may compare 136 its multicast and unicast results and is able to check for 137 differences in the number of hops, RTT, etc. Provided that the 138 server sends the unicast and multicast replies nearly simultaneously, 139 it may also be able to measure the difference in one way delay for 140 unicast and multicast on the path from server to client, and also 141 differences in delay. Servers may optionally specify a timestamp. 142 This may be useful since the unicast and multicast replies can not be 143 sent simultaneously (the delay depending on the host's operating 144 system and load), or whether the client and server have synchronised 145 clocks. 147 3. Protocol specification 149 There are four different ssmping message types. There are Echo 150 Request and Echo Reply messages used for the actual measurements; 151 there is an Init message that SHOULD be used to initialise a ping 152 session and negotiate which group to use; and finally a Server 153 Response message that is mainly used in response to the Init message. 155 The ssmping messages share a common format: one octet specifying the 156 message type, followed by a number of options in TLV (Type, Length 157 and Value) format. This makes the protocol easily extendible. The 158 Init message generally contains some prefix options asking the server 159 for a group from one of the specified prefixes. The server responds 160 with a Server Response message that contains the group address to 161 use, or possibly prefix options describing what multicast groups the 162 server may be able to provide. For an Echo Request the client 163 generally includes a number of options, and a server may simply echo 164 the content back (only changing the message type), without inspecting 165 the options. However, the server SHOULD add a TTL option, and there 166 are some other options that a server implementation MAY support, 167 e.g., the client may ask for certain information or a specific 168 behaviour from the server. The Echo Replies (one unicast and one 169 multicast) MUST first contain the exact options from the request (in 170 the same order), and then, immediately following, options appended by 171 the server. 173 This document defines a number of different options. Some options do 174 not require processing by servers and are simply returned unmodified 175 in the reply. There are, however, other client options that the 176 server may care about, and also server options that may be requested 177 by a client. 179 Unless otherwise specified, an option MUST NOT be used multiple times 180 in the same message. 182 3.1. Option format 184 All options are TLVs formatted as specified below. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Value | 192 | . | 193 | . | 194 | . | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Type (2 octets) specifies the option. The different options are 198 defined below. 200 Length (2 octets) specifies the length of the value field. Depending 201 on the option type, it can be from 0 to 65535. 203 Value. The value must always be of the specified length. See the 204 respective option definitions for possible values. If the length is 205 0, the value field is not included. 207 3.2. Defined Options 209 Version, type 0. Length MUST be 1. This option MUST always be 210 included in all messages, and the value MUST be set to 2 (in 211 decimal). Note that there are older implementations of ssmping that 212 only partly follow this specification. They can be regarded as 213 version 1 and do not use this option. 215 Client ID, type 1. Length MUST be non-zero. A client SHOULD always 216 include this option in all messages (both Init and Request). The 217 client may use any value it likes to be able to detect whether a 218 reply is a reply to this Init/Request or not. A server should treat 219 this as opaque data, and simply leave it unchanged in the reply (both 220 Server Response and Reply). The value might be a process ID, perhaps 221 process ID combined with an IP address because it may receive 222 multicast responses to queries from other clients. It is left to the 223 client implementor how to make use of this option. 225 Sequence number, type 2. Length MUST be 4. A client MUST always 226 include this in Request messages and MUST NOT include it in Init 227 messages. A server replying to a Request message MUST copy it into 228 the Reply (or Server Response message on error). This contains a 32 229 bit sequence number. The values would typically start at 1 and 230 increase by one for each request in a sequence. 232 Timestamp, type 3. Length MUST be 8 bytes. A client SHOULD include 233 this in Request messages and MUST NOT include it in Init messages. A 234 server replying to a request MUST copy it into the Reply. In 235 addition, a server supporting this option, SHOULD include it in Reply 236 messages, if requested by the client. Note that this means that the 237 option may be present in the Reply message twice; both a client 238 timestamp as part of the echoed Request, and another timestamp added 239 by the server. The timestamp specifies the time when the message 240 (query or reply) is sent. The first 4 bytes specify the number of 241 seconds since the Epoch (beginning of the year 1970). The next 4 242 bytes specify the number of microseconds since the last second since 243 the Epoch. 245 Multicast group, type 4. Length MUST be greater than 1. It MAY be 246 used in Server Response messages to tell the client what group to use 247 in subsequent Request messages. It MUST be used in Request messages 248 to tell the server what group address to respond to (this group would 249 typically be previously obtained in a Server Response message). It 250 MUST be used in Reply messages (copied from the Request message). It 251 MUST NOT be used in Init messages. The format of the option value is 252 as below. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Address Family | Multicast group address... | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 260 The address family is a value 0-65535 as assigned by IANA for 261 Internet Address Families [2]. This is followed by the group 262 address. For IPv4 the option value length will be 6, for IPv6 18. 264 Option Request Option, type 5. Length MUST be greater than 1. This 265 option MAY be used in Init and Request messages. It MUST NOT be used 266 in any other messages, except that a server will, in a Reply, echo 267 back this option if present in the Request. This option contains a 268 list of option types for options that the client is requesting from 269 the server. Support for this option is optional for both clients and 270 servers. The length of this option will be a non-zero even number, 271 since it contains one or more option types that are two octets each. 272 The format of the option value is as below. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Option Type | Option Type | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | ..... | 281 This option might be used by the client to ask the server to include 282 options like Timestamp or Server Information. A client MAY request 283 Server Information in Init messages; it MUST NOT request it in other 284 messages. A client MAY request a Timestamp in Request messages; it 285 MUST NOT request it in other messages. 287 Server Information, type 6. Length MUST be non-zero. It MAY be used 288 in Server Response messages and MUST NOT be used in other messages. 289 Support for this option is optional. A server supporting this option 290 SHOULD add it in Server Response messages if and only if requested by 291 the client. The value is a UTF-8 string that might contain vendor 292 and version information for the server implementation. It may also 293 contain information on which options the server supports. An 294 interactive client MAY support this option, and SHOULD then allow a 295 user to request this string and display it. 297 Type 7, Reserved. This option code value was used by early 298 implementations for an option that is now deprecated. This option 299 should no longer be used. Clients MUST not use this option, and 300 Servers MUST ignore it. 302 Pad, type 8. Length can be anything, including 0. This option is 303 used by clients to increase the request size in order to have the 304 server deliver responses of a particular size. If the server adds 305 any options when responding, it should, if possible make the response 306 the same size as the request by shrinking the pad option (i.e., not 307 simply including it, as is, like all other client options). If the 308 options added by the server consume as much space as the pad option 309 does, or more, the server should remove the entire pad option. 311 TTL, type 9. Length MUST be 1. This option contains a single octet 312 specifying the TTL of a Reply message. Every time a server sends a 313 unicast or multicast Reply message, it SHOULD include this option 314 specifying the TTL. This is used by clients to determine the number 315 of hops the messages have traversed. It MUST NOT be used in other 316 messages. Although this option is not absolutely required, the 317 server is expected to use it if it knows what the TTL of the Reply 318 will be. In general the server can specify a specific TTL to the 319 host stack. 321 Multicast prefix, type 10. Length MUST be greater than 2. It MAY be 322 used in Init messages to request a group within the prefix(es), it 323 MAY be used in Server Response messages to tell the client what 324 prefix(es) it may try to obtain a group from. It MUST NOT be used in 325 Request/Reply messages. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Address Family | Prefix Length |Partial address| 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 333 The address family is a value 0-65535 as assigned by IANA for 334 Internet Address Families [2]. This is followed by a prefix length 335 (0-32 for IPv4, 0-128 for IPv6), and finally a group address. The 336 group address need only contain enough octets to cover the prefix 337 length bits (e.g., there need be no group address if the prefix 338 length is 0, the group address would have to be 3 octets long if the 339 prefix length is 17-24). Any bits past the prefix length MUST be 340 ignored. For IPv4 the option value length will be 3-7, while for 341 IPv6 3-19. 343 Session ID, type 11. Length MUST be non-zero. A server MAY include 344 this in Server Response and Reply messages. If a client receives 345 this option in a message, the client MUST echo the Session ID option 346 in Reply messages, with the exact same value, until the next message 347 is received from the server. If the next message from the server has 348 no Session ID or a new Session ID value, the client should do the 349 same, either not use the Session ID, or use the new value. 351 4. Packet Format 353 The format of all messages is a one octet message type, directly 354 followed by a variable number of options. 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type | Option | 360 +-+-+-+-+-+-+-+-+ . | 361 | . | 362 | . | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Option | 365 | . | 366 | . | 367 | . | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 . 370 . 371 . 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Option | 374 | . | 375 | . | 376 | . | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 There are four message types defined. Type 81 (the character Q in 380 ASCII) specifies an Echo Request (Query). Type 65 (the character A 381 in ASCII) specifies an Echo Response (Answer). Type 73 (the 382 character I in ASCII) is an Init message, and type 83 (the character 383 S in ACII) is a Server Response message. 385 The options directly follow the type octet and are not aligned in any 386 way (no spacing or padding), i.e., options might start at any octet 387 boundary. The option format is specified above. 389 5. Message types and options 391 For the readers convenience we provide the matrix below, showing what 392 options can go in what messages. 394 Option / Message Type | Init | Server Response | Request | Reply | 395 -----------------------------------------------------------------+ 396 Version (0) | MUST | MUST | MUST | ECHO | 397 Client ID (1) |SHOULD| ECHO | SHOULD | ECHO | 398 Sequence number (2) | NOT | ECHO | MUST | ECHO | 399 Timestamp (3) | NOT | NOT | SHOULD |ECHO/RQ| 400 Multicast group (4) | NOT | MAY | MUST | ECHO | 401 Option Request (5) | MAY | NOT | MAY | ECHO | 402 Server Information (6)| NOT | RQ | NOT | NOT | 403 Reserved (7) | NOT | NOT | NOT | NOT | 404 Pad (8) | NOT | NOT | MAY | ECHO* | 405 TTL (9) | NOT | NOT | NOT |SHOULD | 406 Multicast prefix (10) | MAY | MAY | NOT | NOT | 407 Session ID (11) | NOT | MAY | ECHO | MAY | 409 NOT means that the option MUST NOT be included. ECHO for a server 410 means that if the option is specified by the client, then the server 411 MUST echo the option back in the response, with the exact same option 412 value. The exception is ECHO* where the option value may be 413 modified. ECHO for a client means that it MUST echo the option it 414 got in the last message from the server in the following messages it 415 sends. RQ means that the server SHOULD include the option in the 416 response, when requested by the client using the Option Request 417 option. 419 6. Client Behaviour 421 We will consider how a typical interactive client using the above 422 protocol would behave. A client need only require a user to specify 423 the unicast address of the server. It can then send an Init message 424 with a prefix option containing the desired address family and zero 425 prefix length. The server is then free to decide which group it 426 should return. A client may also allow a user to specify a group 427 address(es) or prefix(es) (for IPv6, the user may only be required to 428 specify a scope or an RP address, from which the client can construct 429 the desired prefix, possibly embedded-RP). From this the client can 430 specify one or more prefix options in an Init message to tell the 431 server which address it would prefer. If the user specifies a group 432 address, that can be encoded as a prefix of maximal length (e.g. 32 433 for IPv4). The prefix options are in prioritised order, i.e., the 434 client should put the most preferred prefix first. 436 If the client receives a Server Response message containing a group 437 address it can start sending Request messages, see the next 438 paragraph. If there is no group address option, it would typically 439 exit with an error message. The server may have included some prefix 440 options in the Server Response. The client may use this to provide 441 the user some feedback on what prefixes or scopes are available. 443 Assuming the client got a group address in a Server Response it can 444 start pinging. Before it does that it should let the user know which 445 group is being used. When sending ping Requests the client must 446 always specifiy the group option. If the last message from the 447 server contained a Session ID, then it MUST also include that with 448 the same value. Typically it would receive a Session ID in a Server 449 Response together with the group address, and then the ID would stay 450 the same during the entire ping sequence. However, if for instance 451 the server process is restarted, it may still be possible to continue 452 pinging but the Session ID MAY be changed by the server. Hence a 453 client implementation MUST always use the last Session ID it 454 received, and not necessarily the one from the Server Response 455 message. If a client receives a Server Response message in response 456 to a Request message (that is, a Server Response message containing a 457 sequence number), this means there is an error and it should stop 458 sending Requests. This may for instance happen after server restart. 460 The client may have an option for the user to obtain server 461 information. If the user asks for server information, the client can 462 send an Init message with no prefix options, but with an Option 463 Request Option, requesting the server to return a Server Information 464 option. The server will return server information if supported, and 465 it may also return a list of prefixes it supports. It will however 466 not return a group address. The client may also try to obtain only a 467 list of prefixes by sending an Init message with no prefixes and not 468 requesting any specific options. 470 Note that a client may pick a multicast group and send Request 471 messages without first going through the Init - Server Response 472 negotiation. If this is supported by the server and the server is 473 okay with the group used, the server can then send Reply messages as 474 usual. If the server is not okay, it will send a Server Response 475 telling the client to stop and possibly pick a new group. 477 7. Server Behaviour 479 We will consider how a typical server using the above protocol would 480 behave. First we consider how to respond to Init messages. If the 481 Init message contains prefix options, the server should look at them 482 in order and see if it can assign a multicast address in the given 483 range. The server would be configured, possibly have a default, 484 specifying which groups it can offer. It may have a large pool just 485 picking a group at random, possibly choose a group based on hashing 486 of the clients IP address or identifier, or just use a fixed group. 487 It is left to the server to decide whether it should allow the same 488 address to be used simultaneously by multiple clients. If the server 489 finds a suitable group address, it returns this in a group option in 490 a Server Response message. The server may additionally include a 491 Session ID. This may help the server if it is to keep some state, 492 for instance for making sure the client uses the group it got 493 assigned. A good Session ID would be a random byte string that is 494 hard to predict. If the server cannot find a suitable group address, 495 or if there were no prefixes in the Init message, it may send a 496 Server Response message containing prefix options listing what 497 prefixes may be available to the client. Finally, if the Init 498 message requests the Server Information option, it should include 499 that. 501 When the server receives a Request message, it may first check that 502 the group address and Session ID (if provided) are valid. If the 503 server is satisfied it will send a unicast Reply message back to the 504 client, and also a multicast Reply message to the group address. The 505 Reply messages contain the exact options and in the same order, as in 506 the Request (only exception is the pad option), and after that the 507 server adds a TTL option and additional options if needed. E.g., it 508 may add a timestamp if requested by the client. If the server is not 509 happy with the group address and Session ID, it may send a Server 510 Response message asking the client to stop. This Server Response 511 must echo the sequence number from the Request. This Server Response 512 may contain which prefixes the client can try to request addresses 513 from. The unicast and multicast Reply messages have identical UDP 514 payload apart from possibly TTL and timestamp option values. 516 Note that the server may receive Request messages with no prior Init 517 message. This may happen when the server restarts or if a client 518 sends a Request with no prior Init message. The server may go ahead 519 and respond if it is okay with the group used. In the responses it 520 may add a Session ID which will then be in later requests from the 521 client. If the group is not okay, the server sends back a Server 522 Response. The Response is just as if it got an Init message with no 523 prefixes. If the server adds or modifies the SessionID in replies, 524 it MUST use the exact same SessionID in the unicast and multicast 525 replies. 527 8. Acknowledgements 529 The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and 530 Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source 531 Specific Multicast, and also the Internet Draft 532 draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with 533 several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave 534 Thaler have contributed in different ways to the implementation of 535 the ssmping tools at [3]. Many people in communities like TERENA, 536 Internet2 and the M6Bone have used early implementations of ssmping 537 and provided feedback that have influenced the current protocol. 538 Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Liu Hui, 539 Bharat Joshi, Olav Kvittem, Kamil Sarac, Pekka Savola, Trond Skjesol 540 and Cao Wei for reviewing and providing feedback on this draft. 542 9. IANA Considerations 544 IANA is requested to provide a UDP port number for use by this 545 protocol, and also provide a registry for ssmping option types. 547 10. Security Considerations 549 There are some security issues to consider. One is that a host may 550 send a request with an IP source address of another host, and make an 551 arbitrary ssmping server on the Internet send packets to this other 552 host. This hehaviour is fairly harmless. The worst case is if the 553 host receiving the unicast replies also happen to be performing an 554 ssmping test towards that particular server. In this unlikely event, 555 there would be an amplification effect where the host receives twice 556 as many replies as there are requests sent. An ssmping server should 557 perform rate limiting, to guard against this function being used as a 558 DoS attack. A client should also use the client ID option to 559 distinguish replies to its own requests from replies that might be to 560 other requests. 562 11. References 564 11.1. Normative References 566 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 567 Levels", BCP 14, RFC 2119, March 1997. 569 [2] "IANA, Address Family Numbers", 570 . 572 11.2. Informative References 574 [3] "ssmping implementation", 575 . 577 Authors' Addresses 579 Stig Venaas 580 UNINETT 581 Trondheim NO-7465 582 Norway 584 Email: venaas@uninett.no 586 Hugo Santos 587 NEC Europe Ltd. 588 Kurfuersten-Anlage 36 589 Heidelberg 69115 590 Germany 592 Email: hugo.santos@nw.neclab.eu 594 Full Copyright Statement 596 Copyright (C) The IETF Trust (2007). 598 This document is subject to the rights, licenses and restrictions 599 contained in BCP 78, and except as set forth therein, the authors 600 retain all their rights. 602 This document and the information contained herein are provided on an 603 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 604 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 605 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 606 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 607 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 610 Intellectual Property 612 The IETF takes no position regarding the validity or scope of any 613 Intellectual Property Rights or other rights that might be claimed to 614 pertain to the implementation or use of the technology described in 615 this document or the extent to which any license under such rights 616 might or might not be available; nor does it represent that it has 617 made any independent effort to identify any such rights. Information 618 on the procedures with respect to rights in RFC documents can be 619 found in BCP 78 and BCP 79. 621 Copies of IPR disclosures made to the IETF Secretariat and any 622 assurances of licenses to be made available, or the result of an 623 attempt made to obtain a general license or permission for the use of 624 such proprietary rights by implementers or users of this 625 specification can be obtained from the IETF on-line IPR repository at 626 http://www.ietf.org/ipr. 628 The IETF invites any interested party to bring to its attention any 629 copyrights, patents or patent applications, or other proprietary 630 rights that may cover technology that may be required to implement 631 this standard. Please address the information to the IETF at 632 ietf-ipr@ietf.org. 634 Acknowledgment 636 Funding for the RFC Editor function is provided by the IETF 637 Administrative Support Activity (IASA).