RFC 6450
Multicast Ping Protocol
RFC 6450: Multicast Ping Protocol ✨
Okay bestie, let's get into it 🦋. This is RFC 6450, a Standards Track document from December 2011 (ISSN 2070-1721), published by the Internet Engineering Task Force (IETF). The author is S. Venaas from Cisco Systems. The header doesn't list any document that it obsoletes or updates, so it stands on its own 💅.
Abstract
The Multicast Ping Protocol is all about checking whether an endpoint can receive multicast, both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM) 🌸. It can also pull out extra multicast info, like how long it takes to set up a multicast tree ⭐. The protocol is based on an implementation of tools called "ssmping" and "asmping" 🎀.
Status of This Memo
This is an Internet Standards Track document 💜.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more on Internet Standards, check Section 2 of RFC 5741 🧚.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6450 🍓.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this document 🫶. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as the Simplified BSD License describes 💅.
Table of Contents
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. Architecture ....................................................3
3. Protocol Specification ..........................................6
3.1. Option Format ..............................................7
3.2. Defined Options ............................................7
3.3. Packet Format .............................................13
3.4. Message Types and Options .................................13
3.5. Rate Limiting .............................................15
3.5.1. Message Rate Variables .............................16
4. Client Behaviour ...............................................16
5. Server Behaviour ...............................................18
6. Recommendations for Implementers ...............................19
7. IANA Considerations ............................................20
8. Security Considerations ........................................21
9. Acknowledgments ................................................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................231. Introduction ✨
Okay so the Multicast Ping Protocol checks multicast connectivity 🦋. Beyond checking reception of multicast (SSM or ASM), it can also give you related info like multicast tree setup time, the number of hops the packets traveled, and packet delay and loss 📡. This kinda resembles the ICMP Echo Request/Reply mechanism [RFC0792] 💖, but it uses UDP [RFC0768] instead, and it requires that both a client and a server implement this protocol 🎀. Intermediate routers are not required to support this protocol. They just forward protocol messages and data traffic as usual 🧚.
The protocol is based on the current implementation of the ssmping and asmping tools [IMPL]. People across the Internet use those tools a lot to run multicast connectivity tests 🌸.
1.1. Requirements Language
Here's the key bit, so pay attention 💅. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 👑.
Part 1 of 6 is done, bestie 🎀✨. Part 2 is coming next, so stay tuned 💜.
2. Architecture ✨
Okay bestie, before we get into the nitty-gritty, here's the vibe check on how this protocol is used and what info it can actually give you 💅🫶
The protocol runs between clients and servers to check multicast connectivity. Servers are the multicast sources and clients are the multicast receivers. A server can be configured with a set of multicast address ranges for testing, or it can just use implementation defaults 🌸 Depending on the config or the implementation, the server can control which clients (by unicast address) get to use which group ranges, whether clients can pick their own group address or whether the server picks it for them, and whether several clients are allowed to use the same multicast address at once. All of that is config and/or implementation dependent, so it's giving "it depends" energy 🙈
Now the server also keeps some runtime soft state, which is very main character 🦋 It has to do rate limiting to restrict how many client requests it handles, and this rate limiting is per-client IP address. That state usually only needs to stick around for a few seconds, depending on the limit used. If the server hands out unique multicast addresses to clients, it also has to track which address is used by which client IP address. That state should expire if the server hasn't gotten requests for a few minutes, and the exact timeout should ideally be configurable so it can handle different environments 🎀 If a client is going to run multicast ping checks continuously for a long time, and it needs to survive requests not reaching it for several minutes, the timeout has to be extended. To verify the client IP address, the server should do a return routability check by giving the client a non-predictable session ID. That session ID then becomes part of the server's soft state for that client 🔐
Before a client can run a multicast ping test, it has to know the unicast address of a server. It can also be configured with a multicast address or range to use. If it is, the client tells the server which group or range it wants. If not, the server gets to decide the group 👑 Normally a client sends Default-Client-Request-Rate requests per second, but it can be configured to use a different rate. See the definition of Default-Client-Request-Rate in Section 3.5.1. Also, the value can be less than 1, which is so specific and I love it 🧚
At runtime, the client makes up a client ID that's unique for the ping test. That ID goes in every message the client sends 💖 If the client wasn't given a specific group address, the server hands it one to use for the ping requests. The server might also give it a Session ID. The client ID, group address, and Session ID (if one was received) stay fixed for every ping request in that session, so it's all locked in 🔒 When a client gets replies from a server, it checks the client ID in the reply, and if it doesn't match what the client used in the requests, the client ignores that reply. For each valid reply, the client can print or record stuff like round trip time, number of hops, etc. Once the ping session ends, the client can calculate and print or record statistics for the whole session 📊✨
Here's how the typical usage goes 🍓
- Setup: A server runs nonstop to serve clients. A client has somehow found out the server's unicast address and wants to test multicast reception from it 🌈
- Asking for a group: The client app sends a unicast message to the server asking for a group to use. If the user wants a specific group or scope, the client asks for a group that matches what they requested. The server replies with a group to use, or an error if no group is available 🙅♀️
- Joining: For ASM, the client joins an ASM group G. For SSM, it joins a channel (S,G), where G is the multicast group address the server specified and S is the unicast address used to reach the server 💜
- Pinging: After joining, the client unicasts multicast ping requests to the server. The requests go over UDP with the destination port set to the standardised multicast ping port (9903). They're sent periodically, and the rate is Default-Client-Request-Rate (Section 3.5.1) requests per second by default, though the client can be configured to use another rate. Each request has a sequence number and usually a timestamp. The server echoes the requests back and might add a few options 🦋
- Replies: For each request, the server sends two replies. One is unicast to the source IP address and source UDP port of the client that asked. The other is multicast to the requested multicast group G and to the source UDP port of that client. Both replies go out from the same port the request came in on 🫶 The server should set the TTL (IPv4 time-to-live or IPv6 hop-count) for both the unicast and multicast messages (a TTL of at least 64 is recommended) by including a TTL option. That lets the client work out how many hops there were 🔥
- Leaving: Once the client is done measuring, it should leave the group/channel 👋
So what can a client actually learn from all this? Lots, bestie 🤯 First, by getting unicast replies, the client can confirm the server is getting its unicast requests and is up and responding. So if the client gets unicast replies but no multicast, the problem is either a multicast problem or a multicast administrative restriction 😭 If it does receive multicast, it knows it can receive multicast traffic, and it can also estimate how long it took to set up the multicast tree (at least if that's in the range of seconds), whether packets are getting dropped, and the length and variation of round trip times (RTTs) 💅
For unicast, the RTT is the time from sending the unicast request to getting the reply. The measured multicast RTT also references the client's unicast request. By setting the TTL on the replies when they're originated, the client can also figure out how many router hops it is from the source 🧚 Since the unicast replies give similar info, the host can compare multicast and unicast results and check for differences, like hop count and RTT. It's literally a whole comparison arc 🍿
The number of multicast hops, and how that number changes over time, can reveal details about the multicast tree and how it changes 🌳 And if the server sends the unicast and multicast replies nearly at the same time, the client may also be able to measure the difference in one-way delay between unicast and multicast on the path from server to client. Iconic science 👑
Servers may optionally include a timestamp. This can be really useful, because the unicast and multicast replies can't be sent at the exact same moment (the delay depends on the host's operating system and load) ⏱️💀
3. Protocol Specification 🎀
Okay, the message types! There are four kinds, and we're going to be very organised about it 💖
- Echo Request and Echo Reply messages, which are used for the actual measurements 📏
- An Init message, which SHOULD be used to initialise a ping session and negotiate which group to use ✨
- A Server Response message, which is mainly used in response to the Init message 🌸
The messages MUST always be in network byte order. UDP checksums MUST always be used. Non-negotiable, bestie 🙅♀️
All the messages share the same format: one octet for the message type, followed by a bunch of options in TLV (Type, Length, and Value) format. This is what makes the protocol so easy to extend 🦋
Message types 0-253 are reserved and available for allocation in an IANA registry. Message types 254 and 255 are freely available for experimental use. See Section 7 💅
The Init message usually contains some prefix options asking the server for a group from one of the prefixes listed. The server answers with a Server Response message that has the group address to use, or possibly prefix options describing what multicast groups the server might be able to provide 🌈
For an Echo Request, the client includes a bunch of options, and a server MAY simply echo the contents back (only changing the message type) without looking at the options, if it doesn't support any options. Honestly that's giving simple Multicast Ping Protocol server energy, but it really limits what info a client can get, so the protocol becomes way less useful 😭 That said, the server SHOULD add a TTL option (so the client can figure out how many router hops a reply has been through), and there are other options a server implementation MAY support. For example, the client might ask for certain info or a specific behaviour from the server 🧚 Both Echo Reply messages (the unicast one and the multicast one) MUST first contain the exact options from the request, in the same order, and then, right after those, any options the server appended. A server MUST NOT process unknown options, but they MUST still be included in the Echo Reply. A client MUST ignore any unknown options. Respect the boundaries, babe 🫶
The protocol messages are usually smaller than the Path MTU, so fragmentation isn't really a concern. There might be cases where the Path MTU is super small, or where a client sends big requests to check that it can receive fragmented multicast datagrams. This document doesn't say whether Path MTU Discovery should be performed, etc. A possible extension could be an option where a client asks for Path MTU Discovery and gets the current Path MTU from the server. Future-me's problem, but I love the plot twist 🔮
This document defines a bunch of options. Some options don't need the server to process them and are just returned unmodified in the reply. Other client options the server may care about, and some server options can be requested by a client. Unless otherwise specified, an option MUST NOT be used multiple times in the same message. Rule of the group chat 🚫💜
3.1. Option Format 🦋
Every option is a TLV, and it looks like this 👇
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Type (2 octets) specifies the option 🎀
The Length (2 octets) specifies the length of the value field. Depending on the option type, it can be anywhere from 0 to 65535 📏
The Value must always be the specified length. Check the respective option definitions for possible values. If the length is 0, the value field isn't included at all. Zero drama, zero bytes 🧚
3.2. Defined Options 💖
okay so bestie, this is the list of every option in the protocol 💖 we've got Version (0), Client ID (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), Option Request (5), Server Information (6), TTL (9), Multicast Prefix (10), Session ID (11), and Server Timestamp (12) 🦋
Option values 7 and 8 are deprecated and must not be allocated by any future document 🙈 Option types 0-65531 are reserved and available for allocation in an IANA registry, and types 65532-65535 are not registered and are freely available for experimental use 🧪 See Section 7 🎀
Version, type 0 ✨
Length MUST be 1. 💅 This option MUST always be included in all messages, and for the current protocol version it MUST be set to 2 (in decimal) 👑 Older revisions of this protocol only partly follow this spec, and they can be regarded as version 1 and don't use this option 🙈 If a server gets a message with a version other than 2 (or no version at all), the server SHOULD send a Server Response message back with version set to 2, unless it supports that particular version 🌸 This tells the client the server expects version 2 messages 💜 The Client ID and Sequence Number options MUST be echoed if present, so a client can be certain it's a response to one of its messages, and to exactly which message 🫶 The server SHOULD NOT include any other options 🙅 And a client that gets a response with a version other than 2 MUST stop sending requests to that server, unless it supports that particular version 😭
Client ID, type 1 🦋
Length MUST be non-zero. 🌈 A client SHOULD always include this option in all messages (both Init and Echo Request). The client can use any value it likes to figure out whether a reply is for its Init or Echo Request or not ✨ A server should treat this as opaque data, and MUST echo this option back in the reply if present (both Server Response and Echo Reply) 🎀 The value might be a pseudo-random byte string that's likely to be unique, maybe combined with the client IP address 💖 Predictability isn't a big concern here 🙌 This is how the client makes sure server messages are answers to its own requests. Sometimes a client can get multicast responses to queries from other clients 👀 How to use this option is left up to the client implementer 🧚
Sequence Number, type 2 🔥
Length MUST be 4. A client MUST always include this in Echo Request messages and MUST NOT include it in Init messages 💅 A server replying to an Echo Request MUST copy it into the Echo Reply (or the Server Response message, if there's an error) 🫶 The sequence number is a 32-bit integer. Values typically start at 1 and go up by one for each Echo Request in a sequence 🔢
Client Timestamp, type 3 ⏰
Length MUST be 8. A client SHOULD include this in Echo Request messages and MUST NOT include it in Init messages 💖 A server replying to an Echo Request MUST copy it into the Echo Reply ✨ The timestamp tells you the time when the Echo Request message was sent. The first 4 bytes are the number of seconds since the Epoch (0000 UTC Jan 1, 1970), and the next 4 bytes are the number of microseconds since the second given in the first 4 bytes 🕰️ A client would typically use this to compute round trip times 🌸
Ngl, this next bit is a little bit of a "wish they'd done it differently" moment 🙈 While this protocol uses the 32-bit format above, it would have been better to use another format, like the one defined in NTPv4 [RFC5905]. This should be considered for future extensions of the protocol 💜
Multicast Group, type 4 🌈
Length MUST be greater than 2. 🦋 It MAY be used in Server Response messages to tell the client which group to use in later Echo Request messages. It MUST be used in Echo Request messages to tell the server which group address to respond to (this group would typically be one you got earlier in a Server Response message) 💅 It MUST be used in Echo Reply messages (copied from the Echo Request message) 🫶 And it MUST NOT be used in Init messages 🙅 The format of the option value is below ✨
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Multicast group address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |The address family is a value from 0-65535, assigned by IANA for Internet address families [ADDRFAMILY] 🌍 It's followed by the group address. The length of the option value is 6 for IPv4 and 18 for IPv6 💖
Option Request, type 5 🎀
Length MUST be greater than 1. 🙌 This option MAY be used in client messages (Init and Echo Request messages). A server MUST NOT send this option. The exception: if it's present in an Echo Request message, the server MUST echo it in the replies (Echo Reply messages) to that Echo Request 🔁 This option holds a list of option types for the options the client is asking the server for 📋 Support for this option is OPTIONAL for both clients and servers 🫶 The length is a non-zero even number, since it holds one or more option types that are two octets each. The format is below 👇
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |A client might use this to ask the server to include options like Server Timestamp or Server Information 🧁 A client MAY request Server Information in Init messages, but MUST NOT request it in other messages 🙅 A client MAY request a Server Timestamp in Echo Request messages, but MUST NOT request it in other messages 💜 As long as those restrictions are followed, a server that supports this option SHOULD include the requested options in its responses (Echo Reply messages) to the Echo Request that contained the Option Request option ✨ The server may, depending on its implementation or local configuration, not include all the requested options, or possibly none of them 🤷 Any options it does include get appended to the echoed options, just like any other options the server adds 🌈
Server Information, type 6 💅
Length MUST be non-zero. It MAY be used in Server Response messages and MUST NOT be used in other messages 🫶 Support for this option is OPTIONAL 🧁 A server that supports it SHOULD add it to Server Response messages if and only if the client requested it 🙏 The value is a UTF-8 [RFC3629] string that might include vendor and version info for the server implementation. It may also say which options the server supports 📚 An interactive client MAY support this option, and if it does, SHOULD let a user request this string and display it 👀 Even though support is OPTIONAL, we say a server SHOULD return it when requested, since it can be helpful to a user running the client 🎀 It's purely informational though 💁 The protocol doesn't need it to function 🫶
Deprecated, type 7 🙈
This option code value was used by implementations of version 1 of this protocol, and it isn't used in this version 🕰️ Servers MUST treat it as an unknown option. That means they don't process it if they receive it, but if it shows up in an Echo Request message, it MUST be echoed in the Echo Reply message 🔁
Deprecated, type 8 🙈
Same deal as type 7 💖 This option code value was used by implementations of version 1 of this protocol, and it isn't used in this version. Servers MUST treat it as an unknown option (no processing if received, but if it's in an Echo Request message, it MUST be echoed in the Echo Reply message) 🫶
TTL, type 9 ⭐
Length MUST be 1. This option holds a single octet that specifies the TTL of an Echo Reply message 🌸 Every time a server sends a unicast or multicast Echo Reply message, it SHOULD include this option with the TTL. Clients use this to figure out how many hops the messages have traversed 🦋 It MUST NOT be used in other messages 🙅 A server SHOULD specify this option if it knows what the TTL of the Echo Reply will be 💅 In general, the server can set a specific TTL on the host stack ✨ The TTL isn't necessarily the same for unicast and multicast, so keep that in mind 👀 Also, this option SHOULD be included even when the client didn't request it 🫶 The protocol still works without it, but it limits what info a client can get 🥺
If the server didn't include this TTL option, there's no reliable way for the client to know the initial TTL of the Echo Reply. So the client SHOULD NOT try to calculate the number of hops the message has traversed 🙃
Multicast Prefix, type 10 🌷
Length MUST be greater than 2. 🦋 It MAY be used in Init messages to request a group within the prefix(es), and it MAY be used in Server Response messages to tell the client which prefix(es) it may try to get a group from 💖 It MUST NOT be used in Echo Request/Reply messages 🙅 This option MAY be included multiple times to specify multiple prefixes 🧩 Format below 👇
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Prefix Length |Partial address|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |The address family is a value from 0-65535, assigned by IANA for Internet address families [ADDRFAMILY] 🌍 It's followed by a prefix length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special "wildcard" use we'll talk about), and then a group address 💅 For any family, a prefix length of 0 means any multicast address from that family is acceptable. This is what we call "wildcard" 🃏 The group address only needs enough octets to cover the prefix length bits. For example, the group address would have to be 3 octets long if the prefix length is 17-24, and there doesn't need to be a group address at all for the wildcard with prefix length 0 ✨ Any bits past the prefix length MUST be ignored 🙈 For IPv4 the option value length will be 4-7, for IPv6 it'll be 4-19, and for the wildcard it'll be 3 🧮
Session ID, type 11 🧚
Okay bestie, so the Length has to be 4 or larger 🎀. A server SHOULD include this in Server Response messages 📨, and when a client gets it, the client MUST echo the Session ID option in later Echo Request messages with the exact same value 🫶. The Session ID helps the server keep track of clients and maybe manage per-client state 🗂️. A brand new Session ID SHOULD be a pseudo-random byte string that's hard to predict, see [RFC4086] 🔐. The string MUST be at least 4 bytes long, no cap 💅. The Session ID can help mitigate spoofing of the source address of Echo Request messages 🛡️. We say this option SHOULD be used because it's important for security reasons 😭. There may be environments where it isn't required though, so see Section 8, "Security Considerations", for the full tea ☕.
Server Timestamp, type 12 ⏰
Length MUST be 8 bytes. A server that supports this option SHOULD include it in Echo Reply messages if the client asks for it 🙌. The timestamp shows when the Echo Reply message is sent. The first 4 bytes are the number of seconds since the Epoch (0000 UTC Jan 1, 1970), and the next 4 bytes are the number of microseconds since the second in the first 4 bytes 🧮. If this option isn't included, the protocol still works, but a client can't compute one-way delay 🙈.
Ngl, the 32-bit format is kinda giving outdated. It would've been better to use another format, like the one in NTPv4 [RFC5905] 💜. This SHOULD be considered for future extensions of the protocol 🔮.
3.3. Packet Format
The format of all messages is a one-octet message type, followed by a variable number of options ✨.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Options ... |
+-+-+-+-+-+-+-+-+ . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+There are four message types defined 🦋. Type 81 (the character Q in ASCII) is an Echo Request (Query). Type 65 (the character A in ASCII) is an Echo Reply (Answer). Type 73 (the character I in ASCII) is an Init message. Type 83 (the character S in ASCII) is a Server Response message 💌.
The options come right after the type octet and aren't aligned in any way, no spacing or padding, so options might start at any octet boundary 🧩. The option format is specified above.
3.4. Message Types and Options
We're about to go through each of the four message types and which options they can contain 💅.
Init, type 73 🌱
This message is sent by a client to request information from a server. It's mainly for requesting a group address, but it can also check which group prefixes the server may provide groups from, or other server info 🔍. It MUST include a Version option, and SHOULD include a Client ID. It MAY include Option Request and Multicast Prefix options. This message is a request for a group address if and only if it contains Multicast Prefix options. If multiple Prefix options are included, they should be in prioritised order. That means the server will consider the prefixes in the order they're specified, and if it finds a group for a prefix, it only returns that one group and doesn't look at the remaining prefixes 🎯.
Server Response, type 83 📬
This message is sent by a server, either as a response to an Init or in response to an Echo Request. When responding to an Init, it may give the client a multicast group (if the client asked for one), or other server information 🎁. In response to an Echo Request, the message tells the client to stop sending Echo Request messages 🛑. The Version option MUST always be included. Client ID and Sequence Number options get echoed if they were in the client message 🔁. When providing a group to the client, it includes a Multicast Group option. It SHOULD include Server Information and Prefix options if they were requested. It SHOULD also include the Session ID option 🫧.
Echo Request, type 81 🏓
This message is sent by a client, asking the server to send unicast and multicast Echo Reply messages. It MUST include Version, Sequence Number, and Multicast Group options. If a Session ID was received in a Server Response message, then the Session ID MUST be included. It SHOULD include Client ID and Client Timestamp options. It MAY include an Option Request option 🙋.
Echo Reply, type 65 👯
This message is sent by a server in response to an Echo Request message. It's always sent in pairs, one unicast and one multicast 👭. The contents are mostly the same. The server always echoes all of the options (but never the Session ID) from the Echo Request. Any options in the Echo Request that the server doesn't support are also to be echoed. The two Echo Reply messages SHOULD both always contain a TTL option (not necessarily equal). When requested, both Echo Reply messages SHOULD also contain Server Timestamps (not necessarily equal) ⏱️.
The matrix below sums up what options can go in what messages 📊.
\ Message Type | Init | Server | Echo | Echo |
Option \ | | Response | Request | Reply |
---------------------- -+--------+----------+---------+--------+
Version (0) | MUST | MUST | MUST | ECHO |
Client ID (1) | SHOULD | ECHO | SHOULD | ECHO |
Sequence Number (2) | NOT | ECHO | MUST | ECHO |
Client Timestamp (3) | NOT | NOT | SHOULD | ECHO |
Multicast Group (4) | NOT | MAY | MUST | ECHO |
Option Request (5) | MAY | NOT | MAY | ECHO |
Server Information (6) | NOT | RQ | NOT | NOT |
Deprecated (7) | NOT | NOT | NOT | ECHO |
Deprecated (8) | NOT | NOT | NOT | ECHO |
TTL (9) | NOT | NOT | NOT | SHOULD |
Multicast Prefix (10) | MAY | MAY | NOT | NOT |
Session ID (11) | NOT | SHOULD | ECHO | NOT |
Server Timestamp (12) | NOT | NOT | NOT | RQ |
---------------------- -+--------+----------+---------+--------+"NOT" means that the option MUST NOT be included. "ECHO" for a server means that if the client specifies the option, the server MUST echo it in the response with the exact same option value 🪞. ECHO for a client only applies to the Session ID option. If it's present in the Server Response, then it MUST be present with the exact same option value in the following Echo Request messages 🔑. "RQ" means the server SHOULD include the option in the response when the client asks for it with the Option Request option 🙏.
3.5. Rate Limiting
Clients MUST by default send at most Default-Client-Request-Rate (Section 3.5.1) Echo Request messages per second 🐢. The value can be less than 1. Servers MUST by default perform rate limiting, to guard against this protocol being used for denial-of-service (DoS) attacks 🚨. A server MUST by default limit the number of clients that can be served at the same time. For a given client, a server MUST also by default respond to, on average, at most Default-Server-Rate-Limit (see Section 3.5.1) Echo Request messages per second 🚦. The value can be less than 1. Server implementations should provide configuration options that let certain clients send Echo Request messages at faster rates 🔧. If higher rates are allowed for specific client IP addresses, then Init messages and the Session ID option MUST be used to help mitigate spoofing 🫡.
Implementers of applications and tools using this protocol SHOULD consider the UDP guidelines [RFC5405], especially if clients are going to send, or servers are going to accept, Echo Request messages at rates above the defaults in this document 📚. See Section 8, "Security Considerations", for additional discussion 🔒.
3.5.1. Message Rate Variables
There are two variables that control message rates. They're defined as follows 🎛️.
Default-Client-Request-Rate 📤
This variable sets the default client echo request rate, as the number of requests per second. The value may be less than one. For example, a value of 0.1 means one packet per 10 seconds 🐌. The value 1 is RECOMMENDED, but it might be too small or too large depending on the type of network the client is deployed in 🌐. The value 1 is chosen because it should be safe in most deployments, and it's similar to what the common tool "ping" uses for ICMP Echo Request messages 🏓.
Default-Server-Rate-Limit 📥
This variable sets the default per-client rate limit a server uses when responding to Echo Request messages. The average rate of replies MUST NOT exceed Default-Server-Rate-Limit per second 🚫. The value may be less than one. For example, a value of 0.1 means an average of one packet per 10 seconds ⏳. The value 1 is RECOMMENDED, but it might be too small or too large depending on the type of network the client is deployed in 🌍. The value 1 is chosen because it should be safe in most deployments. This value SHOULD be high enough to accept the value chosen for Default-Client-Request-Rate 💯.
4. Client Behaviour ✨
okay so let's talk about how a totally typical interactive client would act with this protocol 💖
A client only needs the user to give it the unicast address of the server 🎀. Then it can send an Init message with a prefix option that has the address family it wants and a zero prefix length, which is the wildcard entry 🧚. The server then gets to decide which group from that family it hands back 💅. A client can also let the user type in group address(es) or prefix(es) if they want. For IPv6, the user might only need to pick a scope or a Rendezvous Point (RP) address, and the client can build the prefix from that, possibly embedded-RP 🌈. From there the client can put one or more prefix options into an Init message to tell the server which address it would prefer 🦋. If the user picks a group address, it can be encoded as a prefix of maximal length (e.g., 32 for IPv4) 🍓. The prefix options are in prioritised order, so the client should put the most preferred prefix first 👑.
If the client gets a Server Response message with a group address in it, it can start sending Echo Request messages (more on that in the next paragraph 💜). If there's no group address option, the client would typically exit with an error message 💀. The server may have included some prefix options in the Server Response too, and the client can use those to show the user which prefixes or scopes are available ✨.
Once the client has a group address from a Server Response, it can start the multicast pings, after letting the user know which group is being used 🔥. Normally, a client should send at most Default-Client-Request-Rate (Section 3.5.1) Echo Request messages per second 🫶.
When sending Echo Request messages, the client must always include the group option 🎀. If the Server Response contained a Session ID option, the client must also include a Session ID option with the exact same value in the Echo Request messages 💅. If a client receives a Server Response message in reply to an Echo Request (that is, one containing a sequence number), that means there's an error, and it should stop sending Echo Request messages 😭. This could happen after a server restart 🥺.
The client may let the user ask for server information. If the user does, the client can send an Init message with no prefix options but with an Option Request option, asking the server to return a Server Information option 🌸. The server will return server information if it supports it, and it may also return a list of prefixes it supports 🧚. It will not, however, return a group address 🙈. The client may also try to get only a list of prefixes by sending an Init message with no prefixes and not requesting any specific options 💜.
Although this technique is not recommended, a client may pick a multicast group and send Echo Request messages without first going through the Init - Server Response negotiation 🙃. If the server supports this and is okay with the group used, the server can then send Echo Reply messages as usual 🦋. If the server is not okay with the group used, it will send a Server Response telling the client to stop 🛑.
5. Server Behaviour 🌈
now let's look at how a typical server using this protocol would behave, starting with how it responds to Init messages 🎀.
If the Init message contains prefix options, the server should look at them in order and see if it can assign a multicast address from the given prefix 🔍. The server is configured with a (possibly default) set of groups it can offer 🍓. It may have a big pool and pick a group at random, or choose one based on hashing the client's IP address or identifier, or just use a fixed group 🎲. A server could also decide whether to include site-scoped group ranges based on the client's IP address 🏠. It's left up to the server to decide whether the same address can be used by multiple clients at the same time 🤷♀️.
If the server finds a suitable group address, it returns that address in a group option in a Server Response message 🎁. The server should also include a Session ID 🔐. This can help the server if it needs to keep some state, for instance to make sure the client uses the group assigned to it 👑. A good Session ID would be a pseudo-random byte string that is hard to predict, see [RFC4086] 🧠. If the server can't find a suitable group address, or if there were no prefixes in the Init message, it may send a Server Response message containing prefix options that list which prefixes might be available to the client 🌸. Finally, if the Init message requests the Server Information option, the server should include that option 💖.
When the server gets an Echo Request message, it must first check that the group address and Session ID (if provided) are valid 🔎. If the server is satisfied, it sends a unicast Echo Reply message back to the client, and also a multicast Echo Reply message to the group address 🦋. The Echo Reply messages contain the exact options (but no Session ID), in the same order as in the Echo Request 💅. After that, the server adds a TTL option and any additional options it needs 🧚. For example, it may add a timestamp if the client asked for one ⏰. If the server isn't happy with the Echo Request (for example a bad group address or Session ID, or a request that's too large), it may send a Server Response message asking the client to stop 🛑. This Server Response must echo the sequence number from the Echo Request 🫶.
This Server Response may contain group prefixes that a client can use to try to request a group address 🎀. The unicast and multicast Echo Reply messages have identical UDP payloads, apart from possibly the TTL and timestamp option values 💜.
Note that the server may receive Echo Request messages with no prior Init message 👀. This can happen when the server restarts, or if a client sends an Echo Request with no prior Init message 🔄. The server may go ahead and respond if it's okay with the group and Session ID (if included) used ✅. If it isn't okay with that information, the server sends back a Server Response 🙅♀️.
6. Recommendations for Implementers 💅
the protocol, as specified, is pretty flexible and leaves a lot of freedom for implementers 🦋. In this section we share some recommendations 💡.
Server administrators should be able to configure one group prefix or multiple group prefixes in a server implementation 🌈. When deploying servers on the Internet and in other environments, the server administrator should be able to restrict the server to respond to only a few multicast groups that should not currently be used by multicast applications 🛡️. A server implementation should also give administrators the flexibility to apply various policies, such as providing one or multiple group prefixes to specific clients, e.g., site-scoped addresses for clients inside the site 🏡.
As specified in Section 3.5, for a given client, a server must by default respond to at most an average rate of Default-Server-Rate-Limit Echo Request messages per second ⏱️. A leaky bucket algorithm is suggested, where the rate can be higher for a few seconds, but the average rate should by default be limited to Default-Server-Rate-Limit messages per client per second 🪣. Server implementations should provide administrative control over which client IP addresses to serve, and may also allow certain clients to send Echo Request messages more rapidly 🏃♀️.
If a server uses different policies for different IP addresses, it should require clients to send Init messages and return an unpredictable Session ID to help mitigate spoofing 🕵️♀️. > This is an absolute requirement if exceeding the default rate limit 🚨. See the specification in Section 3.5 📖.
7. IANA Considerations 🌸
IANA has assigned UDP user port 9903 (multicast-ping) for use by this protocol 🎀. IANA also provides registries for message and option types 📚.
IANA has created a message types registry 🦋. Message types are in the range 0-255. Message types 0-253 are registered following the procedures for Specification Required from RFC 5226 [RFC5226], while types 254 and 255 are for experimental use 🧪. The registry includes the messages defined in Section 3.4. A message specification MUST describe the behaviour with known option types, as well as the default behaviour with unknown option types 💜.
IANA has created an option type registry 🧩. Option types 0-65531 are registered following the procedures for Specification Required from RFC 5226 [RFC5226], while types 65532-65535 are for experimental use 🔬. The registry should include the options defined in Section 3.2. An option specification must describe how the option may be used with the known message types 📝. This includes which message types the option may be used with 🫶.
The initial registry definitions are as follows 👑:
Multicast Ping Protocol Parameters:
Registry Name: Multicast Ping Protocol Message Types
Reference: RFC 6450
Registration Procedures: Specification Required
Registry:
Type Name Reference
----------- ------------------------------------ ----------
65 Echo Reply RFC 6450
73 Init RFC 6450
81 Echo Request RFC 6450
83 Server Response RFC 6450
254-255 ExperimentalRegistry Name: Multicast Ping Protocol Option Types
Reference: RFC 6450
Registration Procedures: Specification Required
Registry:
Type Name Reference
----------- ------------------------------------ ----------
0 Version RFC 6450
1 Client ID RFC 6450
2 Sequence Number RFC 6450
3 Client Timestamp RFC 6450
4 Multicast Group RFC 6450
5 Option Request RFC 6450
6 Server Information RFC 6450
7 Deprecated RFC 6450
8 Deprecated RFC 6450
9 TTL RFC 6450
10 Multicast Prefix RFC 6450
11 Session ID RFC 6450
12 Server Timestamp RFC 6450
65532-65535 Experimental8. Security Considerations 🔒✨
Okay bestie, security is the spicy part, so let's go. One issue is that a host can send an Echo Request with the IP source address of a different host, and basically make some random multicast ping server on the Internet send packets over to that victim 😬. This is mostly harmless. The real danger is if the victim is also joined to the multicast group being used, because then they get the unicast Echo Reply messages and are in the group. This is less of a problem for SSM, since the server's source address also has to match the one that was joined 🙈. In that case you get an amplification effect, where the victim gets twice as many replies as requests sent 💀. Spoofing mitigation comes up below.
For ASM (Any-Source Multicast) 🎀, a host could also make a multicast ping server send multicast packets to a group that's being used for something else, which could mess with other uses of that group. Server implementations should let administrators restrict which groups the server responds to, and the administrator should then try to set up groups that aren't used for anything else 🧹. Bandwidth is another worry 🌊. To keep bandwidth in check, a server MUST by default limit how many clients it can serve at the same time, and a server MUST also by default do per-client rate limiting 🚦.
To help with spoofing 🕵️♀️, a server SHOULD require the client to send an Init message, and return an unpredictable Session ID in the response. The ID should be tied to the IP address and have a limited lifetime ⏳. The server SHOULD then only respond to Echo Request messages that have a valid Session ID linked to the source IP address of the Echo Request. Now here's the tea ☕: the server still sends back a Server Response message if the Session ID is invalid. That's how it tells the client something's wrong, so the client should stop sending requests and start over if needed. BUT this means someone could spoof a client request and get the server to send a message back to the client's address 😭. One fix would be for the server to have a very low rate limit on Server Response messages.
Also, using a Session ID only helps with spoofing to some degree 🫠. An attacker on the path between a client and a server can eavesdrop on the traffic, learn a valid Session ID, and generate Echo Request messages using it. The server will keep responding as long as that Session ID stays valid.
This protocol may be used to set up a covert channel 🕳️ between a multicast ping client and other hosts listening to a multicast group. For example, a client can send an Echo Request with an undefined option that carries arbitrary data. The server would echo that back in an Echo Reply, which might reach other hosts listening to the group 👀. One idea to consider for future protocol versions is replying with a hash of the data instead of just copying the same data back 🔐.
9. Acknowledgments 🫶
The ssmping concept was proposed by Pavan Namburi, Kamil Sarac, and Kevin C. Almeroth in the paper "SSM-Ping: A Ping Utility for Source Specific Multicast" (2004), and also in "MPing: A Ping Utility for IP Multicast" (Sarac and Almeroth, 2004) 👑. Mickael Hoerdt contributed several ideas 💡. Alexander Gall, Nicholas Humfrey, Nick Lamb, and Dave Thaler have helped out in different ways with the implementation of the ssmping tools [IMPL] 🛠️. Lots of people in communities like the Trans-European Research and Education Networking Association (TERENA), Internet2, and the M6Bone (IPv6 multicast network) used early implementations of ssmping and gave feedback that shaped the current protocol 🌈. Huge thanks to Kevin Almeroth, Tony Ballardie, Bill Cerveny, Toerless Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, Trond Skjesol, and Cao Wei for reviewing and giving feedback on this document 💖. Hugo, Gorry, and Bharat especially gave tons of input across several revisions 🦋.
10. References 📚
10.1. Normative References
[ADDRFAMILY]IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.[RFC0768]Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.[RFC0792]Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC3629]Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.[RFC4086]Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
10.2. Informative References
[IMPL]Venaas, S., "ssmping implementation", <http://software.uninett.no/ssmping/>.[RFC5405]Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.[RFC5905]Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
Author's Address 💌
Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
EMail: stig@cisco.com📦 where this page comes from
- ietf: rfc6450 2011-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms