idnits 2.17.1 draft-ietf-mboned-ssmping-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (October 5, 2011) is 4580 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 175, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- 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 cisco Systems 4 Intended status: Standards Track October 5, 2011 5 Expires: April 7, 2012 7 Multicast Ping Protocol 8 draft-ietf-mboned-ssmping-09.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 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). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 7, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 7 63 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 7 64 3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 13 65 3.4. Message Types and Options . . . . . . . . . . . . . . . . 13 66 3.5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 15 67 3.5.1. Message Rate Variables . . . . . . . . . . . . . . . . 16 68 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 16 69 5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 17 70 6. Recommendations for Implementers . . . . . . . . . . . . . . . 19 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 1. Introduction 81 The Multicast Ping Protocol specified in this document allows for 82 checking multicast connectivity. In addition to checking reception 83 of multicast (SSM or ASM), the protocol can provide related 84 information such as multicast tree setup time, the number of hops the 85 packets have traveled, as well as packet delay and loss. This 86 functionality resembles, in part, the ICMP Echo Request/Reply 87 mechanism [RFC0792], but uses UDP [RFC0768] and requires both a 88 client and a server implementing this protocol. Intermediate routers 89 are not required to support this protocol. They forward Protocol 90 Messages and data traffic as usual. 92 This protocol is based on the current implementation of the ssmping 93 and asmping tools [impl] which are widely used by the Internet 94 community to conduct multicast connectivity tests. 96 2. Architecture 98 Before describing the protocol in detail, we provide a brief overview 99 of how the protocol may be used and what information it may provide. 101 The protocol is used between clients and servers to check multicast 102 connectivity. Servers are multicast sources and clients are 103 multicast receivers. A server may be configured with a set of ranges 104 of multicast addresses that can be used for testing, or it may use 105 some implementation defaults. Depending on the server configuration 106 or the implementation it may control which clients (which unicast 107 addresses) are allowed to use different group ranges, and also 108 whether clients can select a group address, or if the group address 109 is selected by the server. It also depends on configuration and/or 110 implementation whether several clients are allowed to simultaneously 111 use the same multicast address. 113 In addition to the above state, a server normally has runtime soft 114 state. The server must generally perform rate limiting to restrict 115 the number of client requests it handles. This rate limiting is per 116 client IP address. This state need usually only be maintained for a 117 few seconds, depending on the limit used. If the server provides 118 unique multicast addresses to clients, it must also have soft state 119 tracking which multicast addresses are used by which client IP 120 address. This state should expire if the server has not received 121 requests within a few minutes. The exact timeout should ideally be 122 configurable to cope with different environments. If a client is 123 expected to perform multicast ping checks continuously for a long 124 period of time, and to cope with requests not reaching the client for 125 several minutes, then this timeout needs to be extended. In order to 126 verify the client IP address, the server should perform a return 127 routability check by giving the client a non-predictable session ID. 128 This would then also be part of the server soft-state for that 129 client. 131 A client must before it can perform a multicast ping test, know the 132 unicast address of a server. In addition it may be configured with a 133 multicast address or range to use. In that case the client will tell 134 the server which group or range it wishes to use. If not, the server 135 is left to decide the group. Normally a client sends Default-Client- 136 Request-Rate requests per second. It may however be configured to 137 use another rate. See definition of Default-Client-Request-Rate in 138 Section 3.5.1. Note that the value can be less than 1. 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 175 [TBD]. The requests are sent periodically to the server. The 176 rate is by default Default-Client-Request-Rate Section 3.5.1 177 requests per second, but the client may be configured to use 178 another rate. These requests contain a sequence number, and 179 typically a timestamp. The requests are echoed by the server, 180 which may add a few options. 182 For each request, the server sends two replies. One reply is 183 unicast to the source IP address and source UDP port of the 184 requesting client. The other reply is multicast to the requested 185 multicast group G and the source UDP port of the requesting 186 client. 188 Both replies are sent from the same port on which the request was 189 received. The server should specify the TTL (IPv4 time-to-live or 190 IPv6 hop-count) used for both the unicast and multicast messages 191 (TTL of at least 64 is recommended) by including a TTL option. 192 This allows the client to compute the number of hops. The client 193 should leave the group/channel when it has finished its 194 measurements. 196 By use of this protocol, a client (or a user of the client) can 197 obtain information about several multicast delivery characteristics. 198 First, by receiving unicast replies, the client can verify that the 199 server is receiving the unicast requests, is operational and 200 responding. Hence, provided that the client receives unicast 201 replies, a failure to receive multicast indicates either a multicast 202 problem or a multicast administrative restriction. If it does 203 receive multicast, it knows not only that it can receive multicast 204 traffic, it may also estimate the amount of time it took to establish 205 the multicast tree (at least if it is in the range of seconds), 206 whether there are packet drops, and the length and variation of Round 207 Trip Times (RTT). 209 For unicast, the RTT is the time from when the unicast request is 210 sent to the time when the reply is received. The measured multicast 211 RTT also references the client's unicast request. By specifying the 212 TTL of the replies when they are originated, the client can also 213 determine the number of router hops it is from the source. Since 214 similar information is obtained in the unicast replies, the host may 215 compare its multicast and unicast results and is able to check for 216 differences such as the number of hops, and RTT. 218 The number of multicast hops and changes in the number of hops over 219 time may reveal details about the multicast tree and multicast tree 220 changes. Provided that the server sends the unicast and multicast 221 replies nearly simultaneously, the client may also be able to measure 222 the difference in one way delay for unicast and multicast on the path 223 from server to client, and also differences in delay. 225 Servers may optionally specify a timestamp. This may be useful since 226 the unicast and multicast replies can not be sent simultaneously (the 227 delay is dependent on the host's operating system and load). 229 3. Protocol Specification 231 There are four different message types. Echo Request and Echo Reply 232 messages are used for the actual measurements. An Init message 233 SHOULD be used to initialise a ping session and negotiate which group 234 to use. Finally a Server Response message that is mainly used in 235 response to the Init message. The messages MUST always be in network 236 byte order. UDP checksums MUST always be used. 238 The messages share a common format: one octet specifying the message 239 type, followed by a number of options in TLV (Type, Length and Value) 240 format. This makes the protocol easily extendible. 242 Message types in the range 0-253 are reserved and available for 243 allocation in an IANA Registry. Message types 254 and 255 are not 244 registered and are freely available for experimental use. See 245 Section 8. 247 The Init message generally contains some prefix options asking the 248 server for a group from one of the specified prefixes. The server 249 responds with a Server Response message that contains the group 250 address to use, or possibly prefix options describing what multicast 251 groups the server may be able to provide. 253 For an Echo Request the client includes a number of options, and a 254 server MAY simply echo the contents (only changing the message type) 255 without inspecting the options if it does not support any options. 256 This might be true for a simple Multicast Ping Protocol server, but 257 it severly limits what information a client can obtain, and hence 258 makes the protocol less useful. However, the server SHOULD add a TTL 259 option (allowing the client to determine the number of router hops a 260 reply has traversed), and there are other options that a server 261 implementation MAY support, e.g., the client may ask for certain 262 information or a specific behaviour from the server. The Echo 263 Replies (one unicast and one multicast) MUST first contain the exact 264 options from the request (in the same order), and then, immediately 265 following, any options appended by the server. A server MUST NOT 266 process unknown options, but they MUST still be included in the Echo 267 Reply. A client MUST ignore any unknown options. 269 The size of the protocol messages is generally smaller than the Path 270 MTU and fragmentation is not a concern. There may however be cases 271 where the Path MTU is really small, or that a client sends large 272 requests in order to verify that it can receive fragmented multicast 273 datagrams. This document does not specify whether Path MTU Discovery 274 should be performed, etc. A possible extension could be an option 275 where a client requests Path MTU Discovery and receives the current 276 Path MTU from the server. 278 This document defines a number of different options. Some options do 279 not require processing by servers and are simply returned unmodified 280 in the reply. There are, however, other client options that the 281 server may care about, as well as server options that may be 282 requested by a client. Unless otherwise specified, an option MUST 283 NOT be used multiple times in the same message. 285 3.1. Option Format 287 All options are TLVs formatted as below. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type | Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Value | 295 | . | 296 | . | 297 | . | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Type (2 octets) specifies the option. 302 Length (2 octets) specifies the length of the value field. Depending 303 on the option type, it can be from 0 to 65535. 305 Value must always be of the specified length. See the respective 306 option definitions for possible values. If the length is 0, the 307 value field is not included. 309 3.2. Defined Options 311 This document defines the following options: Version (0), Client ID 312 (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), 313 Option Request Option (5), Server Information (6), TTL (9), Multicast 314 Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and 315 8 are deprecated and must not be allocated by any future document. 316 The options are defined below. 318 Option types in the range 0-65531 are reserved and available for 319 allocation in an IANA Registry. Option types in the range 65532- 320 65535 are not registered and are freely available for experimental 321 use. See Section 8. 323 Version, type 0 325 Length MUST be 1. This option MUST always be included in all 326 messages, and for the current specified protocol this value 327 MUST be set to 2 (in decimal). Note that there are 328 implementations of older revisions of this protocol that only 329 partly follow this specification. They can be regarded as 330 version 1 and do not use this option. If a server receives a 331 message with a version other than 2 (or missing), the server 332 SHOULD (unless it supports the particular version) send a 333 Server Response message back with version set to 2. This tells 334 the client that the server expects version 2 messages. Client 335 ID and Sequence Number options MUST be echoed if present, so 336 that a client can be certain it is a response to one of its 337 messages, and exactly which message. The server SHOULD NOT 338 include any other options. A client receiving a response with 339 a version other than 2 MUST stop sending requests to the server 340 (unless it supports the particular version). 342 Client ID, type 1 344 Length MUST be non-zero. A client SHOULD always include this 345 option in all messages (both Init and Echo Request). The 346 client may use any value it likes to detect whether a reply is 347 a reply to its Init/Echo Request or not. A server should treat 348 this as opaque data, and MUST echo this option back in the 349 reply if present (both Server Response and Echo Reply). The 350 value might be a pseudo random byte string that is likely to be 351 unique, possibly combined with the client IP address. 352 Predictability is not a big concern here. This is used by the 353 client to ensure that server messages are in response to its 354 requests. In some cases a client may receive multicast 355 responses to queries from other clients. It is left to the 356 client implementer how to use this option. 358 Sequence Number, type 2 360 Length MUST be 4. A client MUST always include this in Echo 361 Request messages and MUST NOT include it in Init messages. A 362 server replying to an Echo Request message MUST copy it into 363 the Echo Reply (or Server Response message on error). The 364 sequence number is a 32-bit integer. Values typically start at 365 1 and increase by one for each Echo Request in a sequence. 367 Client Timestamp, type 3 369 Length MUST be 8. A client SHOULD include this in Echo Request 370 messages and MUST NOT include it in Init messages. A server 371 replying to an Echo Request message MUST copy it into the Echo 372 Reply. The timestamp specifies the time when the Echo Request 373 message is sent. The first 4 bytes specify the number of 374 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 375 bytes specify the number of microseconds since the second 376 specified in the first 4 bytes. This option would typically be 377 used by a client to compute round trip times. 379 Note that while this protocol uses the above 32 bit format, it 380 would have been better to use another format, such as the one 381 defined in NTPv4 [RFC5905]. This should be considered for 382 future extensions of the protocol. 384 Multicast Group, type 4 386 Length MUST be greater than 2. It MAY be used in Server 387 Response messages to tell the client what group to use in 388 subsequent Echo Request messages. It MUST be used in Echo 389 Request messages to tell the server what group address to 390 respond to (this group would typically be previously obtained 391 in a Server Response message). It MUST be used in Echo Reply 392 messages (copied from the Echo Request message). It MUST NOT 393 be used in Init messages. The format of the option value is as 394 below. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Address Family | Multicast group address... | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 402 The address family is a value 0-65535 as assigned by IANA for 403 Internet address families [addrfamily]. This is followed by 404 the group address. Length of the option value will be 6 for 405 IPv4, and 18 for IPv6. 407 Option Request Option, type 5 409 Length MUST be greater than 1. This option MAY be used in 410 client messages (Init and Echo Request messages). A server 411 MUST NOT send this option, except that if it is present in an 412 Echo Request message, the server MUST echo it in replies (Echo 413 Reply message) to the Echo Request. This option contains a 414 list of option types for options that the client is requesting 415 from the server. Support for this option is OPTIONAL for both 416 clients and servers. The length of this option will be a non- 417 zero even number, since it contains one or more option types 418 that are two octets each. The format of the option value is as 419 below. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Option Type | Option Type | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | ..... | 428 This option might be used by the client to ask the server to 429 include options like Timestamp or Server Information. A client 430 MAY request Server Information in Init messages; it MUST NOT 431 request it in other messages. A client MAY request a timestamp 432 in Echo Request messages; it MUST NOT request it in other 433 messages. Subject to enforcing the above restrictions, a 434 server supporting this option SHOULD include the requested 435 options in responses (Echo Reply messages) to the Echo Request 436 containing the Option Request Option. The server may, 437 according to implementation or local configuration, not 438 necessarily include all the requested options, or possibly 439 none. Any options included are appended to the echoed options, 440 similar to other options included by the server. 442 Server Information, type 6 444 Length MUST be non-zero. It MAY be used in Server Response 445 messages and MUST NOT be used in other messages. Support for 446 this option is OPTIONAL. A server supporting this option 447 SHOULD add it in Server Response messages if and only if 448 requested by the client. The value is a UTF-8 [RFC3629] string 449 that might contain vendor and version information for the 450 server implementation. It may also contain information on 451 which options the server supports. An interactive client MAY 452 support this option, and SHOULD then allow a user to request 453 this string and display it. Although support for this is 454 OPTIONAL, we say that a server SHOULD return it if requested, 455 since this may be helpful to a user running the client. It is 456 however purely informational, it is not needed for the protocol 457 to function. 459 Deprecated, type 7 461 This option code value was used by implementations of version 1 462 of this protocol, and is not used in this version. Servers 463 MUST treat it as an unknown option (not process it if received, 464 but if received in an Echo Request message, it MUST be echoed 465 in the Echo Reply message). 467 Deprecated, type 8 469 This option code value was used by implementations of version 1 470 of this protocol, and is not used in this version. Servers 471 MUST treat it as an unknown option (not process it if received, 472 but if received in an Echo Request message, it MUST be echoed 473 in the Echo Reply message). 475 TTL, type 9 477 Length MUST be 1. This option contains a single octet 478 specifying the TTL of an Echo Reply message. Every time a 479 server sends a unicast or multicast Echo Reply message, it 480 SHOULD include this option specifying the TTL. This is used by 481 clients to determine the number of hops the messages have 482 traversed. It MUST NOT be used in other messages. A server 483 SHOULD specify this option if it knows what the TTL of the Echo 484 Reply will be. In general the server can specify a specific 485 TTL to the host stack. Note that the TTL is not necessarily 486 the same for unicast and multicast. Also note that this option 487 SHOULD be included even when not requested by the client. The 488 protocol will work even if this option is not included, but it 489 limits what information a client can obtain. 491 If the server did not include this TTL option, there is no 492 reliable way for the client to know the initial TTL of the Echo 493 Reply, and therefore the client SHOULD NOT attempt to calculate 494 the number of hops the message has traversed. 496 Multicast Prefix, type 10 498 Length MUST be greater than 2. It MAY be used in Init messages 499 to request a group within the prefix(es) and it MAY be used in 500 Server Response messages to tell the client what prefix(es) it 501 may try to obtain a group from. It MUST NOT be used in Echo 502 Request/Reply messages. Note that this option MAY be included 503 multiple times to specify multiple prefixes. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Address Family | Prefix Length |Partial address| 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | 510 The address family is a value 0-65535 as assigned by IANA for 511 Internet address families [addrfamily]. This is followed by a 512 prefix length (4-32 for IPv4, 8-128 for IPv6, or 0 for the 513 special "wildcard" use discussed below), and finally a group 514 address. For any family, prefix length 0 means that any 515 multicast address from that family is acceptable. This is what 516 we call "wildcard." The group address need only contain enough 517 octets to cover the prefix length bits (i.e., the group address 518 would have to be 3 octets long if the prefix length is 17-24, 519 and there need be no group address for the wildcard with prefix 520 length 0). Any bits past the prefix length MUST be ignored. 521 For IPv4, the option value length will be 4-7, while for IPv6, 522 it will be 4-19, and for the wildcard, it will be 3. 524 Session ID, type 11 526 Length MUST be 4 or larger. A server SHOULD include this in 527 Server Response messages. If a client receives this option in 528 a message, the client MUST echo the Session ID option in 529 subsequent Echo Request messages, with the exact same value. 530 The Session ID may help the server in keeping track of clients 531 and possibly manage per client state. The value of a new 532 Session ID SHOULD be a pseudo random byte string that is hard 533 to predict, see [RFC4086]. The string MUST be at least 4 bytes 534 long. The Session ID can be used to mitigate spoofing of the 535 source address of Echo Request messages. We say that this 536 option SHOULD be used, because it is important for security 537 reasons. There may however be environments where this is not 538 required. See the Security Considerations for details. 540 Server Timestamp, type 12 542 Length MUST be 8 bytes. A server supporting this option, 543 SHOULD include it in Echo Reply messages, if requested by the 544 client. The timestamp specifies the time when the Echo Reply 545 message is sent. The first 4 bytes specify the number of 546 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 547 bytes specify the number of microseconds since the second 548 specified in the first 4 bytes. If this option is not 549 included, the protocol will still work, but it makes it 550 impossible for a client to compute one way delay. 552 Note that while this protocol uses the above 32 bit format, it 553 would have been better to use another format, such as the one 554 defined in NTPv4 [RFC5905]. This should be considered for 555 future extensions of the protocol. 557 3.3. Packet Format 559 The format of all messages is a one octet message type, followed by a 560 variable number of options. 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type | Options ... | 566 +-+-+-+-+-+-+-+-+ . | 567 | . | 568 | . | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ..... 571 There are four message types defined. Type 81 (the character Q in 572 ASCII) specifies an Echo Request (Query). Type 65 (the character A 573 in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I 574 in ASCII) is an Init message, and type 83 (the character S in ASCII) 575 is a Server Response message. 577 The options immediately follow the type octet and are not aligned in 578 any way (no spacing or padding), i.e., options might start at any 579 octet boundary. The option format is specified above. 581 3.4. Message Types and Options 583 There are four message types defined. We will now describe each of 584 the message types and which options they may contain. 586 Init, type 73 588 This message is sent by a client to request information from a 589 server. It is mainly used for requesting a group address, but 590 it may also be used to check which group prefixes the server 591 may provide groups from, or other server information. It MUST 592 include a Version option, and SHOULD include a Client ID. It 593 MAY include Option Request and Multicast Prefix Options. This 594 message is a request for a group address if and only if it 595 contains Multicast Prefix options. If multiple Prefix options 596 are included, they should be in prioritised order. I.e., the 597 server will consider the prefixes in the order they are 598 specified, and if it finds a group for a prefix, it will only 599 return that one group, not considering the remaining prefixes. 601 Server Response, type 83 603 This message is sent by a server, either as a response to an 604 Init, or in response to an Echo Request. When responding to 605 Init, it may provide the client with a multicast group (if 606 requested by the client), or it may provide other server 607 information. In response to an Echo Request, the message tells 608 the client to stop sending Echo Requests. The Version option 609 MUST always be included. Client ID and Sequence Number options 610 are echoed if present in the client message. When providing a 611 group to the client, it includes a Multicast Group option. It 612 SHOULD include Server Information and Prefix options if 613 requested. It SHOULD also include the Session ID option. 615 Echo Request, type 81 617 This message is sent by a client, asking the server to send 618 unicast and multicast Echo Replies. It MUST include Version, 619 Sequence Number and Multicast Group options. If a Session ID 620 was received in a Server Response message, then the Session ID 621 MUST be included. It SHOULD include Client ID and Client 622 Timestamp options. It MAY include an Option Request option. 624 Echo Reply, type 65 626 This message is sent by a server in response to an Echo Request 627 message. This message is always sent in pairs, one as unicast 628 and one as multicast. The contents of the messages are mostly 629 the same. The server always echoes all of the options (but 630 never the Session ID) from the Echo Request. Any options in 631 the Echo Request that are unsupported by the server, are also 632 to be echoed. The two Echo Reply messages SHOULD both always 633 contain a TTL option (not necessarily equal). Both Echo Reply 634 messages SHOULD also when requested contain Server Timestamps 635 (not necessarily equal). 637 The below matrix summarises what options can go in what messages. 639 \ Message Type | Init | Server | Echo | Echo | 640 Option \ | | Response | Request | Reply | 641 -----------------------+--------+----------+---------+--------+ 642 Version (0) | MUST | MUST | MUST | ECHO | 643 Client ID (1) | SHOULD | ECHO | SHOULD | ECHO | 644 Sequence Number (2) | NOT | ECHO | MUST | ECHO | 645 Client Timestamp (3) | NOT | NOT | SHOULD | ECHO | 646 Multicast Group (4) | NOT | MAY | MUST | ECHO | 647 Option Request (5) | MAY | NOT | MAY | ECHO | 648 Server Information (6) | NOT | RQ | NOT | NOT | 649 Deprecated (7) | NOT | NOT | NOT | ECHO | 650 Deprecated (8) | NOT | NOT | NOT | ECHO | 651 TTL (9) | NOT | NOT | NOT | SHOULD | 652 Multicast Prefix (10) | MAY | MAY | NOT | NOT | 653 Session ID (11) | NOT | SHOULD | ECHO | NOT | 654 Server Timestamp (12) | NOT | NOT | NOT | RQ | 655 -----------------------+--------+----------+---------+--------+ 657 NOT means that the option MUST NOT be included. ECHO for a server 658 means that if the option is specified by the client, then the server 659 MUST echo the option in the response, with the exact same option 660 value. ECHO for a client only applies to the Session ID option. If 661 it is present in the Server Response, then it MUST be present with 662 the exact same option value in the following Echo Requests. RQ means 663 that the server SHOULD include the option in the response, when 664 requested by the client using the Option Request option. 666 3.5. Rate Limiting 668 Clients MUST by default send at most Default-Client-Request-Rate 669 Section 3.5.1 Echo Requests per second. Note that the value can be 670 less than 1. Servers MUST by default perform rate limiting, to guard 671 against this protocol being used for DoS attacks. A server MUST by 672 default limit the number of clients that can be served at the same 673 time, and a server MUST also by default for a given client, respond 674 to on average at most Default-Server-Rate-Limit (see Section 3.5.1) 675 Echo Request messages per second. Note that the value can be less 676 than 1. Server implementations should provide configuration options 677 allowing certain clients to perform more rapid Echo Requests. If 678 higher rates are allowed for specific client IP addresses, then Init 679 messages and the Session ID option MUST be used to help mitigate 680 spoofing. 682 Implementers of applications/tools using this protocol SHOULD 683 consider the UDP guidelines [RFC5405], in particular if clients are 684 to send, or servers are to accept, Echo Requests at rates exceeding 685 the defaults given in this document. See Section 9, "Security 686 Considerations", for additional discussion. 688 3.5.1. Message Rate Variables 690 There are two variables that control message rates. They are defined 691 as follows. 693 Default-Client-Request-Rate 695 This variable defines the default client echo request rate, 696 specifying the number of requests per second. Note that the 697 value may be less than one. E.g., a value of 0.1 means one 698 packet per 10 seconds. The value 1 is RECOMMENDED, but the 699 value might be too small or large depending on the type of 700 network the client is deployed in. The value 1 is chosen 701 because it should be safe in most deployments, and it is 702 similar to what is typically used for the common tool "ping" 703 for ICMP Echo Requests. 705 Default-Server-Rate-Limit 707 This variable defines the default per client rate limit that a 708 server uses for responding to Echo Request messages. The 709 average rate of replies, MUST NOT exceed Default-Server-Rate- 710 Limit per second. Note that the value may be less than one. 711 E.g., a value of 0.1 means an average of one packet per 10 712 seconds. The value 1 is RECOMMENDED, but the value might be 713 too small or large depending on the type of network the client 714 is deployed in. The value 1 is chosen because it should be 715 safe in most deployments. This value SHOULD be high enough to 716 accept the value chosen for the Default-Client-Request-Rate. 718 4. Client Behaviour 720 We will consider how a typical interactive client using the above 721 protocol would behave. 723 A client only requires a user to specify the unicast address of the 724 server. It can then send an Init message with a prefix option 725 containing the desired address family and zero prefix length 726 (wildcard entry). The server can then decide which group, from the 727 specified family, it should return. A client may also allow the user 728 to specify group address(es) or prefix(es) (for IPv6, the user may 729 only be required to specify a scope or an RP address, from which the 730 client can construct the desired prefix, possibly embedded-RP). From 731 this the client can specify one or more prefix options in an Init 732 message to tell the server which address it would prefer. If the 733 user specifies a group address, that can be encoded as a prefix of 734 maximal length (e.g., 32 for IPv4). The prefix options are in 735 prioritised order, i.e., the client should put the most preferred 736 prefix first. 738 If the client receives a Server Response message containing a group 739 address it can start sending Echo Request messages, see the next 740 paragraph. If there is no group address option, the client would 741 typically exit with an error message. The server may have included 742 some prefix options in the Server Response. The client may use this 743 to provide the user some feedback on what prefixes or scopes are 744 available. 746 Assuming the client got a group address in a Server Response, it can 747 start the multicast pings, after letting the user know which group is 748 being used. Normally, a client should send at most Default-Client- 749 Request-Rate Section 3.5.1 Echo Requests per second. 751 When sending the Echo Requests, the client must always include the 752 group option. If the Server Response contained a Session ID, then it 753 must also include that, with the exact same value, in the Echo 754 Requests. If a client receives a Server Response message in response 755 to an Echo Request (that is, a Server Response message containing a 756 sequence number), this means there is an error and it should stop 757 sending Echo Requests. This could happen after server restart. 759 The client may allow the user to request server information. If the 760 user requests server information, the client can send an Init message 761 with no prefix options, but with an Option Request Option, requesting 762 the server to return a Server Information option. The server will 763 return server information if supported, and it may also return a list 764 of prefixes it supports. It will however not return a group address. 765 The client may also try to obtain only a list of prefixes by sending 766 an Init message with no prefixes and not requesting any specific 767 options. 769 Although not recommended, a client may pick a multicast group and 770 send Echo Request messages without first going through the Init - 771 Server Response negotiation. If this is supported by the server and 772 the server is okay with the group used, the server can then send Echo 773 Reply messages as usual. If the server is not okay, it will send a 774 Server Response telling the client to stop. 776 5. Server Behaviour 778 We will consider how a typical server using the above protocol would 779 behave, first looking at how to respond to Init messages. 781 If the Init message contains prefix options, the server should look 782 at them in order and see if it can assign a multicast address from 783 the given prefix. The server would be configured with, possibly have 784 a default, a set of groups it can offer. It may have a large pool 785 and pick a group at random, or possibly choosing a group based on 786 hashing of the client's IP address or identifier, or simply use a 787 fixed group. A server could possibly decide whether to include site 788 scoped group ranges based on the client's IP address. It is left to 789 the server to decide whether it should allow the same address to be 790 used simultaneously by multiple clients. 792 If the server finds a suitable group address, it returns this in a 793 group option in a Server Response message. The server should 794 additionally include a Session ID. This may help the server if it is 795 to keep some state, for instance to make sure the client uses the 796 group it got assigned. A good Session ID would be a pseudo random 797 byte string that is hard to predict, see [RFC4086]. If the server 798 cannot find a suitable group address, or if there were no prefixes in 799 the Init message, it may send a Server Response message containing 800 prefix options listing what prefixes may be available to the client. 801 Finally, if the Init message requests the Server Information option, 802 the server should include that. 804 When the server receives an Echo Request message, it must first check 805 that the group address and Session ID (if provided) are valid. If 806 the server is satisfied, it will send a unicast Echo Reply message 807 back to the client, and also a multicast Echo Reply message to the 808 group address. The Echo Reply messages contain the exact options 809 (but no Session ID) and in the same order, as in the Echo Request, 810 and after that the server adds a TTL option and additional options if 811 needed. For example, it may add a timestamp if requested by the 812 client. If the server is not happy with the Echo Request (such as 813 bad group address or Session ID, request is too large), it may send a 814 Server Response message asking the client to stop. This Server 815 Response must echo the sequence number from the Echo Request. This 816 Server Response may contain group prefixes from which a client can 817 try to request a group address. The unicast and multicast Echo Reply 818 messages have identical UDP payload apart from possibly TTL and 819 timestamp option values. 821 Note that the server may receive Echo Request messages with no prior 822 Init message. This may happen when the server restarts or if a 823 client sends an Echo Request with no prior Init message. The server 824 may go ahead and respond if it is okay with the group and Session ID 825 (if included) used. If it is not okay, the server sends back a 826 Server Response. 828 6. Recommendations for Implementers 830 The protocol as specified is fairly flexible and leaves a lot of 831 freedom for implementers. In this section we present some 832 recommendations. 834 Server administrators should be able to configure one or multiple 835 group prefixes in a server implementation. When deploying servers on 836 the Internet and in other environments, the server administrator 837 should be able to restrict the server to respond to only a few 838 multicast groups which should not be currently used by multicast 839 applications. A server implementation should also provide 840 flexibility for an administrator to apply various policies to provide 841 one or multiple group prefixes to specific clients, e.g., site scoped 842 addresses for clients that are inside the site. 844 As specified in Section 3.5, a server must by default for a given 845 client, respond to at most an average rate of Default-Server-Rate- 846 Limit Echo Request messages per second. A leaky bucket algorithm is 847 suggested, where the rate can be higher for a few seconds, but the 848 average rate should by default be limited to Default-Server-Rate- 849 Limit messages per per client per second. Server implementations 850 should provide administrative control of which client IP addresses to 851 serve, and may also allow certain clients to perform more rapid Echo 852 Requests. 854 If a server uses different policies for different IP addresses, it 855 should require clients to send Init messages and return an 856 unpredictable Session ID to help mitigate spoofing. This is an 857 absolute requirement if exceeding the default rate limit. See 858 specification in Section 3.5. 860 7. Acknowledgments 862 The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and 863 Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source 864 Specific Multicast, and also the Internet Draft 865 draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with 866 several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave 867 Thaler have contributed in different ways to the implementation of 868 the ssmping tools at [impl]. Many people in communities like TERENA, 869 Internet2 and the M6Bone have used early implementations of ssmping 870 and provided feedback that have influenced the current protocol. 871 Thanks to Kevin Almeroth, Tony Ballardie, Bill Cerveny, Toerless 872 Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui, 873 Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, 874 Trond Skjesol and Cao Wei for reviewing and providing feedback on 875 this draft. In particular Hugo, Gorry and Bharat have provided lots 876 of input on several revisions of the draft. 878 8. IANA Considerations 880 IANA is requested to assign a UDP user-port in the range 1024-49151 881 for use by this protocol, and also to provide registries for message 882 and option types. The string "[TBD]" in this document should be 883 replaced with the assigned port. 885 There should be a message types registry. Message types are in the 886 range 0-255. Message types 0-253 are registered following the 887 procedures for Specification Required from RFC 5226 [RFC5226], while 888 types 254 and 255 are for experimental use and are not registered. 889 The registry should include the messages defined in Section 3.4. A 890 message specification MUST describe the behaviour with known option 891 types as well as the default behaviour with unknown ones. 893 There should also be an option type registry. Option types 0-65531 894 are registered following the procedures for Specification Required 895 from RFC 5226 [RFC5226], while types 65532-65535 are for experimental 896 use and are not registered. The registry should include the options 897 defined in Section 3.2. An option specification must describe how 898 the option may be used with the known message types. This includes 899 which message types the option may be used with. 901 The initial registry definitions are as follows: 903 Multicast Ping Protocol Parameters: 905 Registry Name: Multicast Ping Protocol Message Types 906 Reference: [this doc] 907 Registration Procedures: Specification Required 909 Registry: 910 Type Name Reference 911 ----------- ------------------------------------ ---------- 912 65 Echo Reply [this doc] 913 73 Init [this doc] 914 81 Echo Request [this doc] 915 83 Server Response [this doc] 916 254-255 Experimental 918 Registry Name: Multicast Ping Protocol Option Types 919 Reference: [this doc] 920 Registration Procedures: Specification Required 922 Registry: 923 Type Name Reference 924 ----------- ------------------------------------ ---------- 925 0 Version [this doc] 926 1 Client ID [this doc] 927 2 Sequence Number [this doc] 928 3 Client Timestamp [this doc] 929 4 Multicast Group [this doc] 930 5 Option Request Option [this doc] 931 6 Server Information [this doc] 932 7 Deprecated [this doc] 933 8 Deprecated [this doc] 934 9 TTL [this doc] 935 10 Multicast Prefix [this doc] 936 11 Session ID [this doc] 937 12 Server Timestamp [this doc] 938 65532-65535 Experimental 940 9. Security Considerations 942 There are some security issues to consider. One is that a host may 943 send an Echo Request with an IP source address of another host, and 944 make an arbitrary multicast ping server on the Internet send packets 945 to this other host. This behaviour is fairly harmless. The worst 946 case is if the host receiving the unicast Echo Replies also happens 947 to be joined to the multicast group used. This is less of a problem 948 for SSM where also the source address of the server must match the 949 address joined. In this case, there would be an amplification effect 950 where the host receives twice as many replies as there are requests 951 sent. See below for how spoofing can be mitigated. 953 For ASM (Any-Source Multicast) a host could also make a multicast 954 ping server send multicast packets to a group that is used for 955 something else, possibly disturbing other uses of that group. 956 However, server implementations should allow administrators to 957 restrict which groups a server responds to. The administrator should 958 then try to configure a set of groups that are not used for other 959 purposes. Another concern is bandwidth. To limit the bandwidth 960 used, a server MUST by default limit the number of clients that can 961 be served at the same time, and a server MUST also by default perform 962 per client rate limiting. 964 In order to help mitigate spoofing, a server SHOULD require the 965 client to send an Init message, and return an unpredictable Session 966 ID in the response. The ID should be associated with the IP address 967 and have a limited lifetime. The server SHOULD then only respond to 968 Echo Request messages that have a valid Session ID associated with 969 the source IP address of the Echo Request. Note however that a 970 server is replying with a Server Response message if the Session ID 971 is invalid. This is used to tell the client that something is wrong 972 and that is should stop sending requests, and start over if 973 necessary. This means however, that someone may spoof a client 974 request, and have the server send a message back to the client 975 address. One solution here would be for the server to have a very 976 low rate limit for the Server Responses. 978 Note that the use of a Session ID only to some degree helps mitigate 979 spoofing. An attacker that is on the path between a client and a 980 server, may eavesdrop the traffic, learn a valid Session ID, and 981 generate Echo Requests using this ID. The server will respond as 982 long as the Session ID remains valid. 984 This protocol may be used to establish a covert channel between a 985 multicast ping client and other hosts listening to a multicast group. 986 A client can for instance send an Echo Request containing an 987 undefined option with arbitrary data. The server would echo this 988 back in an Echo Reply that may reach other hosts listening to that 989 group. One solution to this which should be considered for future 990 protocol versions, is to reply with a hash of the data, rather than 991 simply a copy of the same data. 993 10. References 994 10.1. Normative References 996 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 997 August 1980. 999 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1000 RFC 792, September 1981. 1002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1003 Requirement Levels", BCP 14, RFC 2119, March 1997. 1005 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1006 10646", STD 63, RFC 3629, November 2003. 1008 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1009 Requirements for Security", BCP 106, RFC 4086, June 2005. 1011 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1012 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1013 May 2008. 1015 [addrfamily] 1016 "IANA, Address Family Numbers", 1017 . 1019 10.2. Informative References 1021 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1022 for Application Designers", BCP 145, RFC 5405, 1023 November 2008. 1025 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1026 Time Protocol Version 4: Protocol and Algorithms 1027 Specification", RFC 5905, June 2010. 1029 [impl] "ssmping implementation", 1030 . 1032 Author's Address 1034 Stig Venaas 1035 cisco Systems 1036 Tasman Drive 1037 San Jose, CA 95134 1038 USA 1040 Email: stig@cisco.com