idnits 2.17.1 draft-ietf-mboned-ssmping-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2010) is 5167 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 174, but not defined -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft UNINETT 4 Intended status: Standards Track March 4, 2010 5 Expires: September 5, 2010 7 Multicast Ping Protocol 8 draft-ietf-mboned-ssmping-08.txt 10 Abstract 12 The Multicast Ping Protocol specified in this document allows for 13 checking whether an endpoint can receive multicast, both Source- 14 Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also 15 be used to obtain additional multicast-related information such as 16 multicast tree setup time. This protocol is based on an 17 implementation of tools called ssmping and asmping. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on September 5, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 7 69 3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 12 70 3.4. Message Types and Options . . . . . . . . . . . . . . . . 13 71 3.5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 14 72 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 15 73 5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 16 74 6. Recommendations for Implementers . . . . . . . . . . . . . . . 17 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 The Multicast Ping Protocol specified in this document allows for 86 checking multicast connectivity. In addition to checking reception 87 of multicast (SSM or ASM), the protocol can provide related 88 information such as multicast tree setup time, the number of hops the 89 packets have traveled, as well as packet delay and loss. This 90 functionality resembles, in part, the ICMP Echo Request/Reply 91 mechanism [RFC0792], but uses UDP [RFC0768] and requires both a 92 client and a server implementing this protocol. Intermediate routers 93 are not required to support this protocol. They forward Protocol 94 Messages and data traffic as usual. 96 This protocol is based on the current implementation of the ssmping 97 and asmping tools [impl] which are widely used by the Internet 98 community to conduct multicast connectivity tests. 100 2. Architecture 102 Before describing the protocol in detail, we provide a brief overview 103 of how the protocol may be used and what information it may provide. 105 The protocol is used between clients and servers. A server may be 106 configured with a set of ranges of multicast addresses that can be 107 used for testing, or it may use some implementation defaults. 108 Depending on the server configuration or the implementation it may 109 control which clients (which unicast addresses) are allowed to use 110 different group ranges, and also whether clients can select a group 111 address, or if the group address is selected by the server. It also 112 depends on configuration and/or implementation whether several 113 clients are allowed to simultaneously use the same multicast address. 115 In addition to the above state, a server normally has runtime soft 116 state. The server must generally perform rate limiting to restrict 117 the number of client requests it handles. This rate limiting is per 118 client IP address. This state need only be maintained for a few 119 seconds (normally to have an average rate of maximum one request per 120 second). If the server provides unique multicast addresses to 121 clients, it must also have soft state tracking which multicast 122 addresses are used by which client IP address. This state should 123 expire if the server has not received requests within a few minutes. 124 The exact timeout should ideally be configurable to cope with 125 different environments. If a client is expected to perform multicast 126 ping checks continuously for a long period of time, and to cope with 127 requests not reaching the client for several minutes, then this 128 timeout needs to be extended. In order to verify the client IP 129 address, the server should perform a return routability check by 130 giving the client a non-predictable session ID. This would then also 131 be part of the server soft-state for that client. 133 A client must before it can perform a multicast ping test, know the 134 unicast address of a server. In addition it may be configured with a 135 multicast address or range to use. In that case the client will tell 136 the server which group or range it wishes to use. If not, the server 137 is left to decide the group. Normally a client sends one request per 138 second. It may however be configured to use another rate. 140 At runtime, a client generates a client ID that is unique for the 141 ping test. This ID is included in all messages sent by the client. 142 Further, if not supplied with a specific group address, the client 143 will receive a group address from the server, that is used for the 144 ping requests. It may also receive a Session ID from the server. 145 The client ID, group address and Session ID (if received) will then 146 be fixed for all ping requests in this session. When a client 147 receives replies from a server, it will verify the client ID in the 148 reply, and ignore it if not matching what it used in the requests. 149 For each reply it may print or record information like round trip 150 time, number of hops etc. The client may once a ping session is 151 ended, calculate and print or record statistics based on the entire 152 ping session. 154 The typical protocol usage is as follows: 156 A server runs continuously to serve requests from clients. A 157 client has somehow learned the unicast address of the server and 158 tests the multicast reception from the server. 160 The client application will then send a unicast message to the 161 server asking for a group to use. Optionally a user may request a 162 specific group or scope, in which case the client will ask for a 163 group matching the user's request. The server will respond with a 164 group to use, or an error if no group is available. 166 Next, for ASM, the client joins an ASM group G, while for SSM it 167 joins a channel (S,G), where G is the multicast group address 168 specified by the server, and S is the unicast address used to 169 reach the server. 171 After joining the group/channel, the client unicasts multicast 172 ping requests to the server. The requests are sent using UDP with 173 the destination port set to the standardised multicast ping port 174 [TBD]. The requests are sent periodically, perhaps once per 175 second, to the server. These requests contain a sequence number, 176 and typically a timestamp. The requests are echoed by the server, 177 which may add a few options. 179 For each request, the server sends two replies. One reply is 180 unicast to the source IP address and source UDP port of the 181 requesting client. The other reply is multicast to the requested 182 multicast group G and the source UDP port of the requesting 183 client. 185 Both replies are sent from the same port on which the request was 186 received. The server should specify the TTL (IPv4 time-to-live or 187 IPv6 hop-count) used for both the unicast and multicast messages 188 (TTL of at least 64 is recommended) by including a TTL option. 189 This allows the client to compute the number of hops. The client 190 should leave the group/channel when it has finished its 191 measurements. 193 By use of this protocol, a client (or a user of the client) can 194 obtain information about several multicast delivery characteristics. 195 First, by receiving unicast replies, the client can verify that the 196 server is receiving the unicast requests, is operational and 197 responding. Hence, provided that the client receives unicast 198 replies, a failure to receive multicast indicates either a multicast 199 problem or a multicast administrative restriction. If it does 200 receive multicast, it knows not only that it can receive multicast 201 traffic, it may also estimate the amount of time it took to establish 202 the multicast tree (at least if it is in the range of seconds), 203 whether there are packet drops, and the length and variation of Round 204 Trip Times (RTT). 206 For unicast, the RTT is the time from when the unicast request is 207 sent to the time when the reply is received. The measured multicast 208 RTT also references the client's unicast request. By specifying the 209 TTL of the replies when they are originated, the client can also 210 determine the number of router hops it is from the source. Since 211 similar information is obtained in the unicast replies, the host may 212 compare its multicast and unicast results and is able to check for 213 differences such as the number of hops, and RTT. 215 The number of multicast hops and changes in the number of hops over 216 time may reveal details about the multicast tree and multicast tree 217 changes. Provided that the server sends the unicast and multicast 218 replies nearly simultaneously, the client may also be able to measure 219 the difference in one way delay for unicast and multicast on the path 220 from server to client, and also differences in delay. 222 Servers may optionally specify a timestamp. This may be useful since 223 the unicast and multicast replies can not be sent simultaneously (the 224 delay is dependent on the host's operating system and load). 226 3. Protocol Specification 228 There are four different message types. Echo Request and Echo Reply 229 messages are used for the actual measurements. An Init message 230 SHOULD be used to initialise a ping session and negotiate which group 231 to use. Finally a Server Response message that is mainly used in 232 response to the Init message. The messages MUST always be in network 233 byte order. UDP checksums MUST always be used. 235 The messages share a common format: one octet specifying the message 236 type, followed by a number of options in TLV (Type, Length and Value) 237 format. This makes the protocol easily extendible. 239 Message types in the range 0-191 are reserved and available for 240 allocation in an IANA Registry. Message types in the range 192-255 241 are not registered and are freely available for experimental use. 242 See Section 8. 244 The Init message generally contains some prefix options asking the 245 server for a group from one of the specified prefixes. The server 246 responds with a Server Response message that contains the group 247 address to use, or possibly prefix options describing what multicast 248 groups the server may be able to provide. 250 For an Echo Request the client generally includes a number of 251 options, and a server MAY simply echo the contents (only changing the 252 message type) without inspecting the options if it does not support 253 any options. This might be true for a simple Multicast Ping Protocol 254 server, but it severly limits what information a client can obtain, 255 and hence makes the protocol less useful. However, the server SHOULD 256 add a TTL option (allowing the client to determine the number of 257 router hops a reply has traversed), and there are other options that 258 a server implementation MAY support, e.g., the client may ask for 259 certain information or a specific behaviour from the server. The 260 Echo Replies (one unicast and one multicast) MUST first contain the 261 exact options from the request (in the same order), and then, 262 immediately following, any options appended by the server. A server 263 MUST NOT process unknown options, but they MUST still be included in 264 the Echo Reply. A client MUST ignore any unknown options. 266 The size of the protocol messages is generally smaller than the Path 267 MTU and fragmentation is not a concern. There may however be cases 268 where the Path MTU is really small, or that a client sends large 269 requests in order to verify that it can receive fragmented multicast 270 datagrams. This document does not specify whether Path MTU Discovery 271 should be performed, etc. A possible extension could be an option 272 where a client requests Path MTU Discovery and receives the current 273 Path MTU from the server. 275 This document defines a number of different options. Some options do 276 not require processing by servers and are simply returned unmodified 277 in the reply. There are, however, other client options that the 278 server may care about, as well as server options that may be 279 requested by a client. Unless otherwise specified, an option MUST 280 NOT be used multiple times in the same message. 282 3.1. Option Format 284 All options are TLVs formatted 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 | Type | Length | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Value | 292 | . | 293 | . | 294 | . | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Type (2 octets) specifies the option. 299 Length (2 octets) specifies the length of the value field. Depending 300 on the option type, it can be from 0 to 65535. 302 Value must always be of the specified length. See the respective 303 option definitions for possible values. If the length is 0, the 304 value field is not included. 306 3.2. Defined Options 308 This document defines the following options: Version (0), Client ID 309 (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), 310 Option Request Option (5), Server Information (6), TTL (9), Multicast 311 Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and 312 8 are reserved. The options are defined below. 314 Option types in the range 0-49151 are reserved and available for 315 allocation in an IANA Registry. Option types in the range 49152- 316 65535 are not registered and are freely available for experimental 317 use. See Section 8. 319 Version, type 0 321 Length MUST be 1. This option MUST always be included in all 322 messages, and for the current specified protocol this value 323 MUST be set to 2 (in decimal). Note that there are 324 implementations of older revisions of this protocol that only 325 partly follow this specification. They can be regarded as 326 version 1 and do not use this option. If a server receives a 327 message with a version other than 2 (or missing), the server 328 SHOULD (unless it supports the particular version) send a 329 Server Response message back with version set to 2. This tells 330 the client that the server expects version 2 messages. Client 331 ID and Sequence Number options SHOULD be echoed if present, so 332 that a client can be certain it is a response to one of its 333 messages, and exactly which message. The server SHOULD NOT 334 include any other options. A client receiving a response with 335 a version other than 2 MUST stop sending requests to the server 336 (unless it supports the particular version). 338 Client ID, type 1 340 Length MUST be non-zero. A client SHOULD always include this 341 option in all messages (both Init and Echo Request). The 342 client may use any value it likes to detect whether a reply is 343 a reply to its Init/Echo Request or not. A server should treat 344 this as opaque data, and MUST echo this option back in the 345 reply if present (both Server Response and Echo Reply). The 346 value might be a randomised string that is likely to be unique, 347 possibly combined with the client IP address. This is used by 348 the client to ensure that server messages are in response to 349 its requests. In some cases a client may receive multicast 350 responses to queries from other clients. It is left to the 351 client implementer how to use this option. 353 Sequence Number, type 2 355 Length MUST be 4. A client MUST always include this in Echo 356 Request messages and MUST NOT include it in Init messages. A 357 server replying to an Echo Request message MUST copy it into 358 the Echo Reply (or Server Response message on error). The 359 sequence number is a 32-bit integer. Values typically start at 360 1 and increase by one for each Echo Request in a sequence. 362 Client Timestamp, type 3 364 Length MUST be 8 bytes. A client SHOULD include this in Echo 365 Request messages and MUST NOT include it in Init messages. A 366 server replying to an Echo Request message MUST copy it into 367 the Echo Reply. The timestamp specifies the time when the Echo 368 Request message is sent. The first 4 bytes specify the number 369 of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 370 bytes specify the number of microseconds since the second 371 specified in the first 4 bytes. This option would typically be 372 used by a client to compute round trip times. 374 Multicast Group, type 4 376 Length MUST be greater than 2. It MAY be used in Server 377 Response messages to tell the client what group to use in 378 subsequent Echo Request messages. It MUST be used in Echo 379 Request messages to tell the server what group address to 380 respond to (this group would typically be previously obtained 381 in a Server Response message). It MUST be used in Echo Reply 382 messages (copied from the Echo Request message). It MUST NOT 383 be used in Init messages. The format of the option value is as 384 below. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Address Family | Multicast group address... | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 392 The address family is a value 0-65535 as assigned by IANA for 393 Internet address families [addrfamily]. This is followed by 394 the group address. Length of the option value will be 6 for 395 IPv4, and 18 for IPv6. 397 Option Request Option, type 5 399 Length MUST be greater than 1. This option MAY be used in 400 client messages (Init and Echo Request messages). A server 401 MUST NOT send this option, except that if it is present in an 402 Echo Request message, the server MUST echo it in replies (Echo 403 Reply message) to the Echo Request. This option contains a 404 list of option types for options that the client is requesting 405 from the server. Support for this option is optional for both 406 clients and servers. The length of this option will be a non- 407 zero even number, since it contains one or more option types 408 that are two octets each. The format of the option value is as 409 below. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Option Type | Option Type | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | ..... | 418 This option might be used by the client to ask the server to 419 include options like Timestamp or Server Information. A client 420 MAY request Server Information in Init messages; it MUST NOT 421 request it in other messages. A client MAY request a timestamp 422 in Echo Request messages; it MUST NOT request it in other 423 messages. Subject to enforcing the above restrictions, a 424 server supporting this option SHOULD include the requested 425 options in responses (Echo Reply messages) to the Echo Request 426 containing the Option Request Option. The server may, 427 according to implementation or local configuration, not 428 necessarily include all the requested options, or possibly 429 none. Any options included are appended to the echoed options, 430 similar to other options included by the server. 432 Server Information, type 6 434 Length MUST be non-zero. It MAY be used in Server Response 435 messages and MUST NOT be used in other messages. Support for 436 this option is optional. A server supporting this option 437 SHOULD add it in Server Response messages if and only if 438 requested by the client. The value is a UTF-8 string that 439 might contain vendor and version information for the server 440 implementation. It may also contain information on which 441 options the server supports. An interactive client MAY support 442 this option, and SHOULD then allow a user to request this 443 string and display it. Although support for this is optional, 444 we say that a server SHOULD return it if requested, since this 445 may be helpful to a user running the client. It is however 446 purely informational, it is not needed for the protocol to 447 function. 449 Reserved, type 7 451 This option code value was used by early implementations for an 452 option that is now deprecated. This option should no longer be 453 used. Clients MUST NOT use this option. Servers MUST treat it 454 as an unknown option (not process it if received, but if 455 received in an Echo Request message, it MUST be echoed in the 456 Echo Reply message). 458 Reserved, type 8 460 This option code value was used by early implementations for an 461 option that is now deprecated. This option should no longer be 462 used. Clients MUST NOT use this option. Servers MUST treat it 463 as an unknown option (not process it if received, but if 464 received in an Echo Request message, it MUST be echoed in the 465 Echo Reply message). 467 TTL, type 9 469 Length MUST be 1. This option contains a single octet 470 specifying the TTL of an Echo Reply message. Every time a 471 server sends a unicast or multicast Echo Reply message, it 472 SHOULD include this option specifying the TTL. This is used by 473 clients to determine the number of hops the messages have 474 traversed. It MUST NOT be used in other messages. A server 475 SHOULD specify this option if it knows what the TTL of the Echo 476 Reply will be. In general the server can specify a specific 477 TTL to the host stack. Note that the TTL is not necessarily 478 the same for unicast and multicast. Also note that this option 479 SHOULD be included even when not requested by the client. The 480 protocol will work even if this option is not included, but it 481 limits what information a client can obtain. 483 Multicast Prefix, type 10 485 Length MUST be greater than 2. It MAY be used in Init messages 486 to request a group within the prefix(es) and it MAY be used in 487 Server Response messages to tell the client what prefix(es) it 488 may try to obtain a group from. It MUST NOT be used in Echo 489 Request/Reply messages. Note that this option MAY be included 490 multiple times to specify multiple prefixes. 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Address Family | Prefix Length |Partial address| 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 498 The address family is a value 0-65535 as assigned by IANA for 499 Internet address families [addrfamily]. This is followed by a 500 prefix length (4-32 for IPv4, 8-128 for IPv6, or 0 for the 501 special "wildcard" use discussed below), and finally a group 502 address. For any family, prefix length 0 means that any 503 multicast address from that family is acceptable. This is what 504 we call "wildcard." The group address need only contain enough 505 octets to cover the prefix length bits (i.e., the group address 506 would have to be 3 octets long if the prefix length is 17-24, 507 and there need be no group address for the wildcard with prefix 508 length 0). Any bits past the prefix length MUST be ignored. 509 For IPv4, the option value length will be 4-7, while for IPv6, 510 it will be 4-19, and for the wildcard, it will be 3. 512 Session ID, type 11 513 Length MUST be non-zero. A server SHOULD include this in 514 Server Response messages. If a client receives this option in 515 a message, the client MUST echo the Session ID option in 516 subsequent Echo Request messages, with the exact same value. 517 The Session ID may help the server in keeping track of clients 518 and possibly manage per client state. The value of a new 519 Session ID SHOULD be chosen pseudo randomly so that it is hard 520 to predict. The Session ID can be used to prevent spoofing of 521 the source address of Echo Request messages. We say that this 522 option SHOULD be used, because it is important for security 523 reasons. There may however be environments where this is not 524 required. See the Security Considerations for details. 526 Server Timestamp, type 12 528 Length MUST be 8 bytes. A server supporting this option, 529 SHOULD include it in Echo Reply messages, if requested by the 530 client. The timestamp specifies the time when the Echo Reply 531 message is sent. The first 4 bytes specify the number of 532 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 533 bytes specify the number of microseconds since the second 534 specified in the first 4 bytes. If this option is not 535 included, the protocol will still work, but it makes it 536 impossible for a client to compute one way delay. 538 3.3. Packet Format 540 The format of all messages is a one octet message type, followed by a 541 variable number of options. 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Options ... | 547 +-+-+-+-+-+-+-+-+ . | 548 | . | 549 | . | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ..... 552 There are four message types defined. Type 81 (the character Q in 553 ASCII) specifies an Echo Request (Query). Type 65 (the character A 554 in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I 555 in ASCII) is an Init message, and type 83 (the character S in ASCII) 556 is a Server Response message. 558 The options immediately follow the type octet and are not aligned in 559 any way (no spacing or padding), i.e., options might start at any 560 octet boundary. The option format is specified above. 562 3.4. Message Types and Options 564 There are four message types defined. We will now describe each of 565 the message types and which options they may contain. 567 Init, type 73 569 This message is sent by a client to request information from a 570 server. It is mainly used for requesting a group address, but 571 it may also be used to check which group prefixes the server 572 may provide groups from, or other server information. It MUST 573 include a Version option, and SHOULD include a Client ID. It 574 MAY include Option Request and Multicast Prefix Options. This 575 message is a request for a group address if and only if it 576 contains Multicast Prefix options. If multiple Prefix options 577 are included, they should be in prioritised order. I.e., the 578 server will consider the prefixes in the order they are 579 specified, and if it finds a group for a prefix, it will only 580 return that one group, not considering the remaining prefixes. 582 Server Response, type 83 584 This message is sent by a server, either as a response to an 585 Init, or in response to an Echo Request. When responding to 586 Init, it may provide the client with a multicast group (if 587 requested by the client), or it may provide other server 588 information. In response to an Echo Request, the message tells 589 the client to stop sending Echo Requests. The Version option 590 MUST always be included. Client ID and Sequence Number options 591 are echoed if present in the client message. When providing a 592 group to the client, it includes a Multicast Group option. It 593 SHOULD include Server Information and Prefix options if 594 requested. 596 Echo Request, type 81 598 This message is sent by a client, asking the server to send 599 unicast and multicast Echo Replies. It MUST include Version, 600 Sequence Number and Multicast Group options. If a Session ID 601 was received in a Server Response message, then the Session ID 602 MUST be included. It SHOULD include Client ID and Client 603 Timestamp options. It MAY include an Option Request option. 605 Echo Reply, type 65 607 This message is sent by a server in response to an Echo Request 608 message. This message is always sent in pairs, one as unicast 609 and one as multicast. The contents of the messages are mostly 610 the same. The server always echoes all of the options (but 611 never the Session ID) from the Echo Request. Any options in 612 the Echo Request that are unsupported by the server, are also 613 to be echoed. The two Echo Reply messages SHOULD both always 614 contain a TTL option (not necessarily equal). Both Echo Reply 615 messages SHOULD also when requested contain Server Timestamps 616 (not necessarily equal). 618 The below matrix summarises what options can go in what messages. 620 \ Message Type | Init | Server | Echo | Echo | 621 Option \ | | Response | Request | Reply | 622 -----------------------+--------+----------+---------+--------+ 623 Version (0) | MUST | MUST | MUST | ECHO | 624 Client ID (1) | SHOULD | ECHO | SHOULD | ECHO | 625 Sequence Number (2) | NOT | ECHO | MUST | ECHO | 626 Client Timestamp (3) | NOT | NOT | SHOULD | ECHO | 627 Multicast Group (4) | NOT | MAY | MUST | ECHO | 628 Option Request (5) | MAY | NOT | MAY | ECHO | 629 Server Information (6) | NOT | RQ | NOT | NOT | 630 Reserved (7) | NOT | NOT | NOT | ECHO | 631 Reserved (8) | NOT | NOT | NOT | ECHO | 632 TTL (9) | NOT | NOT | NOT | SHOULD | 633 Multicast Prefix (10) | MAY | MAY | NOT | NOT | 634 Session ID (11) | NOT | SHOULD | ECHO | NOT | 635 Server Timestamp (12) | NOT | NOT | NOT | RQ | 636 -----------------------+--------+----------+---------+--------+ 638 NOT means that the option MUST NOT be included. ECHO for a server 639 means that if the option is specified by the client, then the server 640 MUST echo the option in the response, with the exact same option 641 value. ECHO for a client only applies to the Session ID option. If 642 it is present in the Server Response, then it MUST be present with 643 the exact same option value in the following Echo Requests. RQ means 644 that the server SHOULD include the option in the response, when 645 requested by the client using the Option Request option. 647 3.5. Rate Limiting 649 Clients MUST by default send at most one Echo Request per second. 650 Servers MUST by default perform rate limiting, to guard against this 651 protocol being used for DoS attacks. The server MUST by default for 652 a given client, respond to on average at most one Echo Request 653 message per second. Server implementations should provide 654 configuration options allowing certain clients to perform more rapid 655 Echo Requests. If higher rates are allowed for specific client IP 656 addresses, then Init messages and the Session ID option MUST be used 657 to help prevent spoofing. 659 Implementers of applications/tools using this protocol SHOULD 660 consider the UDP guidelines [RFC5405], in particular if clients are 661 to send, or servers are to accept, Echo Requests at rates exceeding 662 one per second. See Section 9, "Security Considerations", for 663 additional discussion. 665 4. Client Behaviour 667 We will consider how a typical interactive client using the above 668 protocol would behave. 670 A client only requires a user to specify the unicast address of the 671 server. It can then send an Init message with a prefix option 672 containing the desired address family and zero prefix length 673 (wildcard entry). The server can then decide which group, from the 674 specified family, it should return. A client may also allow the user 675 to specify group address(es) or prefix(es) (for IPv6, the user may 676 only be required to specify a scope or an RP address, from which the 677 client can construct the desired prefix, possibly embedded-RP). From 678 this the client can specify one or more prefix options in an Init 679 message to tell the server which address it would prefer. If the 680 user specifies a group address, that can be encoded as a prefix of 681 maximal length (e.g., 32 for IPv4). The prefix options are in 682 prioritised order, i.e., the client should put the most preferred 683 prefix first. 685 If the client receives a Server Response message containing a group 686 address it can start sending Echo Request messages, see the next 687 paragraph. If there is no group address option, the client would 688 typically exit with an error message. The server may have included 689 some prefix options in the Server Response. The client may use this 690 to provide the user some feedback on what prefixes or scopes are 691 available. 693 Assuming the client got a group address in a Server Response, it can 694 start the multicast pings, after letting the user know which group is 695 being used. Normally, a client should send at most one Echo Request 696 per second. 698 When sending the Echo Requests, the client must always include the 699 group option. If the Server Response contained a Session ID, then it 700 must also include that, with the exact same value, in the Echo 701 Requests. If a client receives a Server Response message in response 702 to an Echo Request (that is, a Server Response message containing a 703 sequence number), this means there is an error and it should stop 704 sending Echo Requests. This could happen after server restart. 706 The client may allow the user to request server information. If the 707 user requests server information, the client can send an Init message 708 with no prefix options, but with an Option Request Option, requesting 709 the server to return a Server Information option. The server will 710 return server information if supported, and it may also return a list 711 of prefixes it supports. It will however not return a group address. 712 The client may also try to obtain only a list of prefixes by sending 713 an Init message with no prefixes and not requesting any specific 714 options. 716 Although not recommended, a client may pick a multicast group and 717 send Echo Request messages without first going through the Init - 718 Server Response negotiation. If this is supported by the server and 719 the server is okay with the group used, the server can then send Echo 720 Reply messages as usual. If the server is not okay, it will send a 721 Server Response telling the client to stop. 723 5. Server Behaviour 725 We will consider how a typical server using the above protocol would 726 behave, first looking at how to respond to Init messages. 728 If the Init message contains prefix options, the server should look 729 at them in order and see if it can assign a multicast address from 730 the given prefix. The server would be configured with, possibly have 731 a default, a set of groups it can offer. It may have a large pool 732 and pick a group at random, or possibly choosing a group based on 733 hashing of the client's IP address or identifier, or simply use a 734 fixed group. A server could possibly decide whether to include site 735 scoped group ranges based on the client's IP address. It is left to 736 the server to decide whether it should allow the same address to be 737 used simultaneously by multiple clients. 739 If the server finds a suitable group address, it returns this in a 740 group option in a Server Response message. The server should 741 additionally include a Session ID. This may help the server if it is 742 to keep some state, for instance to make sure the client uses the 743 group it got assigned. A good Session ID would be a pseudo random 744 byte string that is hard to predict. If the server cannot find a 745 suitable group address, or if there were no prefixes in the Init 746 message, it may send a Server Response message containing prefix 747 options listing what prefixes may be available to the client. 748 Finally, if the Init message requests the Server Information option, 749 the server should include that. 751 When the server receives an Echo Request message, it may first check 752 that the group address and Session ID (if provided) are valid. If 753 the server is satisfied, it will send a unicast Echo Reply message 754 back to the client, and also a multicast Echo Reply message to the 755 group address. The Echo Reply messages contain the exact options 756 (but no Session ID) and in the same order, as in the Echo Request, 757 and after that the server adds a TTL option and additional options if 758 needed. For example, it may add a timestamp if requested by the 759 client. If the server is not happy with the Echo Request (such as 760 bad group address or Session ID, request is too large), it may send a 761 Server Response message asking the client to stop. This Server 762 Response must echo the sequence number from the Echo Request. This 763 Server Response may contain group prefixes from which a client can 764 try to request a group address. The unicast and multicast Echo Reply 765 messages have identical UDP payload apart from possibly TTL and 766 timestamp option values. 768 Note that the server may receive Echo Request messages with no prior 769 Init message. This may happen when the server restarts or if a 770 client sends an Echo Request with no prior Init message. The server 771 may go ahead and respond if it is okay with the group used. If the 772 group is not okay, the server sends back a Server Response. 774 6. Recommendations for Implementers 776 The protocol as specified is fairly flexible and leaves a lot of 777 freedom for implementers. In this section we present some 778 recommendations. 780 Server administrators should be able to configure one or multiple 781 group prefixes in a server implementation. When deploying servers on 782 the Internet and in other environments, the server administrator 783 should be able to restrict the server to respond to only a few 784 multicast groups which should not be currently used by multicast 785 applications. A server implementation should also provide 786 flexibility for an administrator to apply various policies to provide 787 one or multiple group prefixes to specific clients, e.g., site scoped 788 addresses for clients that are inside the site. 790 As specified in Section 3.5, a server must by default for a given 791 client, respond to at most one Echo Request message per second. A 792 leaky bucket algorithm is suggested, where the rate can be higher for 793 a few seconds, but the average rate should by default be limited to a 794 message per client per second. Server implementations should provide 795 administrative control of which client IP addresses to serve, and may 796 also allow certain clients to perform more rapid Echo Requests. 798 If a server uses different policies for different IP addresses, it 799 should require clients to send Init messages and return an 800 unpredictable Session ID to help prevent spoofing. This is an 801 absolute requirement if exceeding the default rate limit. See 802 specification in Section 3.5. 804 7. Acknowledgments 806 The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and 807 Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source 808 Specific Multicast, and also the Internet Draft 809 draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with 810 several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave 811 Thaler have contributed in different ways to the implementation of 812 the ssmping tools at [impl]. Many people in communities like TERENA, 813 Internet2 and the M6Bone have used early implementations of ssmping 814 and provided feedback that have influenced the current protocol. 815 Thanks to Kevin Almeroth, Tony Ballardie, Bill Cerveny, Toerless 816 Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui, 817 Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, 818 Trond Skjesol and Cao Wei for reviewing and providing feedback on 819 this draft. In particular Hugo, Gorry and Bharat have provided lots 820 of input on several revisions of the draft. 822 8. IANA Considerations 824 IANA is requested to assign a UDP user-port in the range 1024-49151 825 for use by this protocol, and also to provide registries for message 826 and option types. The string "[TBD]" in this document should be 827 replaced with the assigned port. 829 There should be a message types registry. Message types are in the 830 range 0-255. Message types 0-191 require specification (an RFC or 831 other permanent and readily available reference), while types 192-255 832 are for experimental use and are not registered. The registry should 833 include the messages defined in Section 3.4. A message specification 834 must describe the behaviour with known option types as well as the 835 default behaviour with unknown ones. 837 There should also be an option type registry. Option types 0-49151 838 require specification (an RFC or other permanent and readily 839 available reference), while types 49152-65535 are for experimental 840 use and are not registered. The registry should include the options 841 defined in Section 3.2. An option specification must describe how 842 the option may be used with the known message types. This includes 843 which message types the option may be used with. 845 The initial registry definitions are as follows: 847 Multicast Ping Protocol Parameters: 849 Registry Name: Multicast Ping Protocol Message Types 850 Reference: [this doc] 851 Registration Procedures: Specification Required 853 Registry: 854 Type Name Reference 855 ----------- ------------------------------------ ---------- 856 65 Echo Reply [this doc] 857 73 Init [this doc] 858 81 Echo Request [this doc] 859 83 Server Response [this doc] 860 192-255 Experimental 862 Registry Name: Multicast Ping Protocol Option Types 863 Reference: [this doc] 864 Registration Procedures: Specification Required 866 Registry: 867 Type Name Reference 868 ----------- ------------------------------------ ---------- 869 0 Version [this doc] 870 1 Client ID [this doc] 871 2 Sequence Number [this doc] 872 3 Client Timestamp [this doc] 873 4 Multicast Group [this doc] 874 5 Option Request Option [this doc] 875 6 Server Information [this doc] 876 7 Reserved [this doc] 877 8 Reserved [this doc] 878 9 TTL [this doc] 879 10 Multicast Prefix [this doc] 880 11 Session ID [this doc] 881 12 Server Timestamp [this doc] 882 49152-65535 Experimental 884 9. Security Considerations 886 There are some security issues to consider. One is that a host may 887 send an Echo Request with an IP source address of another host, and 888 make an arbitrary multicast ping server on the Internet send packets 889 to this other host. This behaviour is fairly harmless. The worst 890 case is if the host receiving the unicast Echo Replies also happens 891 to be joined to the multicast group used. In this case, there would 892 be an amplification effect where the host receives twice as many 893 replies as there are requests sent. See below for how spoofing can 894 be prevented. 896 For ASM (Any-Source Multicast) a host could also make a multicast 897 ping server send multicast packets to a group that is used for 898 something else, possibly disturbing other uses of that group. 899 However, server implementations should allow administrators to 900 restrict which groups a server responds to. The main concern is 901 bandwidth. To limit the bandwidth used, a server MUST by default 902 perform rate limiting, responding to at most one Echo Request per 903 second. 905 In order to help prevent spoofing, a server SHOULD require the client 906 to send an Init message, and return an unpredictable Session ID in 907 the response. The ID should be associated with the IP address and 908 have a limited lifetime. The server SHOULD then only respond to Echo 909 Request messages that have a valid Session ID associated with the 910 source IP address of the Echo Request. 912 10. References 914 10.1. Normative References 916 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 917 August 1980. 919 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 920 RFC 792, September 1981. 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, March 1997. 925 [addrfamily] 926 "IANA, Address Family Numbers", 927 . 929 10.2. Informative References 931 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 932 for Application Designers", BCP 145, RFC 5405, 933 November 2008. 935 [impl] "ssmping implementation", 936 . 938 Author's Address 940 Stig Venaas 941 UNINETT 942 Trondheim NO-7465 943 Norway 945 Email: venaas@uninett.no