RFC 4884
Extended ICMP to Support Multi-Part Messages
Extended ICMP to Support Multi-Part Messages 💖
Okay bestie, this RFC is the one that gave ICMP its glow-up 🦋. It's Standards Track, so it's an official Internet standard, and it's dated April 2007 ✨. Richard Bonica from Juniper Networks is the lead author, with Dan Gan, Dave Tappan (both consultants), and Carlos Pignataro from Cisco Systems. It updates RFC 792 and RFC 4443, which are the original ICMPv4 and ICMPv6 specs 🎀. Nothing in this document obsoletes another one.
Status of This Memo 📜
This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Copyright Notice ©️
Copyright (C) The IETF Trust (2007).
Abstract 🌸
So this doc redefines some selected ICMP messages so they can do multi-part operation 🧚. A multi-part ICMP message carries everything ICMP messages carried before, plus extra info that applications might need 💅.
Multi-part messages are powered by an ICMP extension structure 🔥. That structure sits at the very end of the ICMP message, and it has an extension header followed by one or more extension objects. Each extension object has an object header and an object payload, and all object headers share the same format 💜.
The memo also redefines the messages that can carry an extension structure by giving them a length attribute 🍓. All of the currently defined ICMP messages that can get an extension structure have an "original datagram" field. That field holds the initial octets of the datagram that set off the ICMP error message 👀. The problem is the field is variable length, but the message doesn't have anything that says how long it is 💀. So to make parsing possible, this doc takes eight previously reserved bits and uses them to show the length of the "original datagram" field ✨.
The proposed changes also change the requirements for ICMP compliance 😭. The memo talks about how those changes affect compliant implementations, and it presents new requirements for future implementations 🎀.
This memo updates RFC 792 and RFC 4443 🦋.
Table of Contents 🗂️
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Summary of Changes to ICMP ......................................4
4. ICMP Extensibility ..............................................4
4.1. ICMPv4 Destination Unreachable .............................7
4.2. ICMPv4 Time Exceeded .......................................8
4.3. ICMPv4 Parameter Problem ...................................8
4.4. ICMPv6 Destination Unreachable .............................9
4.5. ICMPv6 Time Exceeded .......................................9
4.6. ICMP Messages That Can Be Extended ........................10
5. Backwards Compatibility ........................................10
5.1. Classic Application Receives ICMP Message with
Extensions ................................................12
5.2. Non-Compliant Application Receives ICMP Message
with No Extensions ........................................12
5.3. Non-Compliant Application Receives ICMP Message
with Compliant Extensions .................................13
5.4. Compliant Application Receives ICMP Message with
No Extensions .............................................14
5.5. Compliant Application Receives ICMP Message with
Non-Compliant Extensions ..................................14
6. Interaction with Network Address Translation ...................14
7. The ICMP Extension Structure ...................................15
8. ICMP Extension Objects .........................................16
9. Security Considerations ........................................16
10. IANA Considerations ...........................................17
11. Acknowledgments ...............................................17
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................171. Introduction 🌈
This doc redefines some selected ICMPv4 [RFC0792] and ICMPv6 [RFC4443] messages so they can include an extension structure and a length attribute 💖. The extension structure is what powers multi-part ICMP operation ✨. Protocol designers can make an ICMP message carry extra information by encoding that info in the extension structure 🫶.
This doc also tackles a fundamental problem with ICMP extensibility 🙈. All of the ICMP messages this memo covers have an "original datagram" field. That field holds the initial octets of the datagram that set off the ICMP error message. The thing is, the "original datagram" field is variable length, and the ICMP message doesn't have a field that says how long it is 😩.
Application software figures out how long the "original datagram" field is by looking at the total length of the ICMP message 🧠. Now if you appended an extension structure to the message without adding a length attribute for the "original datagram" field, the message would become unparsable 💀. Applications wouldn't be able to tell where the "original datagram" field ends and where the extension structure begins. So this doc proposes a length attribute, plus an extension structure that gets appended to the ICMP message 🎀.
The current memo also deals with backwards compatibility 🦋. It covers existing ICMP implementations that either don't implement the extensions defined here, or implement them without adding the required length attributes 👀. In particular, it covers certain widely deployed, MPLS-aware ICMPv4 implementations that send the extensions defined here without adding the required length attribute 🍓.
This memo doesn't define any ICMP extension objects 🙅♀️. It only defines the extension header and a common header that all extension objects share. [UNNUMBERED], [ROUTING-INST], and [MPLS-ICMP] provide sample applications of the ICMP Extension Object 🧚.
All of those memos have something in common 💅. They all append information to the ICMP Time Expired message so that TRACEROUTE can consume it. In this case, like in many others, appending info to the existing ICMP Time Expired message is better than defining a new message and emitting two messages every time a packet gets dropped because its TTL expired 🔥.
2. Conventions Used in This Document 📚
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 [RFC2119] 🫶.
3. Summary of Changes to ICMP 💜
Here's a quick summary of the changes to ICMP that this memo introduces 🌸:
- An ICMP Extension Structure MAY be appended to ICMPv4 Destination Unreachable, Time Exceeded, and Parameter Problem messages ✨.
- An ICMP Extension Structure MAY be appended to ICMPv6 Destination Unreachable and Time Exceeded messages 🦋.
- The messages above include an "original datagram" field, and their message formats are updated to specify a length attribute for that field 🎀.
- When an ICMP Extension Structure is appended to an ICMP message and that ICMP message contains an "original datagram" field, the "original datagram" field MUST contain at least 128 octets 🔥.
- When an ICMP Extension Structure is appended to an ICMPv4 message and that ICMPv4 message contains an "original datagram" field, the "original datagram" field MUST be zero padded to the nearest 32-bit boundary 🍓.
- When an ICMP Extension Structure is appended to an ICMPv6 message and that ICMPv6 message contains an "original datagram" field, the "original datagram" field MUST be zero padded to the nearest 64-bit boundary 🧚.
- ICMP messages defined in the future SHOULD indicate whether or not they support the extension mechanism defined in this specification 👀. It is recommended that all new messages support extensions 🫶.
Part 1 of 4 is done, babe 🎀. Part 2 is coming next with Section 4 and the ICMPv4 and ICMPv6 details, so stay tuned 💅✨.
4. ICMP Extensibility ✨
okay so RFC 792 defines these ICMPv4 message types 🎀
- Destination Unreachable
- Time Exceeded
- Parameter Problem
- Source Quench
- Redirect
- Echo Request/Reply
- Timestamp/Timestamp Reply
- Information Request/Information Reply
[RFC1191] reserves bits for the "Next-Hop MTU" field in the Destination Unreachable message 🦋
RFC 4443 defines these ICMPv6 message types 💜
- Destination Unreachable
- Packet Too Big
- Time Exceeded
- Parameter Problem
- Echo Request/Reply
Many ICMP messages are extensible as currently defined, bestie 🫶 Protocol designers can extend them by simply appending fields or data structures to the end.
However, these ICMP messages are not extensible as currently defined 😭
- ICMPv4 Destination Unreachable (type = 3)
- ICMPv4 Time Exceeded (type = 11)
- ICMPv4 Parameter Problem (type = 12)
- ICMPv6 Destination Unreachable (type = 1)
- ICMPv6 Packet Too Big (type = 2)
- ICMPv6 Time Exceeded (type = 3)
- ICMPv6 Parameter Problem (type = 4)
Here's the tea. These messages carry an "original datagram" field, which is the leading octets of the datagram the ICMP message is responding to. RFC 792 defines that field for ICMPv4 messages, and it holds the IP header plus the next eight octets of the original datagram. [RFC1812] stretches the field to hold as many octets as possible without making the ICMP message go over the minimum IPv4 reassembly buffer size (576 octets). RFC 4443 defines the field for ICMPv6 messages, where it always held as many octets as possible without the ICMP message exceeding the minimum IPv6 MTU (1280 octets). ✨
Now the problem 💀 The "original datagram" field has no length attribute. Application software figures out how long the field is from the total length of the ICMP message. So if you slapped an extension structure on the end without adding a length attribute, the whole message would become unparsable. The software would have no way to tell where the "original datagram" field stops and the extension structure starts. Not it 🙈
To fix this, this memo introduces an 8-bit length attribute to these ICMPv4 messages 🌈
- Destination Unreachable (type = 3)
- Time Exceeded (type = 11)
- Parameter Problem (type = 12)
It also introduces an 8-bit length attribute to these ICMPv6 messages 🍓
- Destination Unreachable (type = 1)
- Time Exceeded (type = 3)
The length attribute MUST be specified when the ICMP Extension Structure is appended to the ICMP messages above. Non-negotiable, babes 💅
The length attribute represents the length of the "original datagram" field. The space for it is claimed from reserved octets, which used to be required to be zero. Glow-up energy 🌸
For ICMPv4 messages, the length attribute is measured in 32-bit words. When it's specified, the "original datagram" field MUST be zero padded to the nearest 32-bit boundary. The sixth octet of each affected ICMPv4 message was reserved for future use, so that octet was picked as the home for the length attribute in ICMPv4 🧚
For ICMPv6 messages, the length attribute is measured in 64-bit words. When it's specified, the "original datagram" field MUST be zero padded to the nearest 64-bit boundary. The fifth octet of each affected ICMPv6 message was reserved for future use, so that octet got chosen as the length attribute spot in ICMPv6 👑
For backwards compatibility, when an ICMP Extension Structure is appended to an ICMP message that contains an "original datagram" field, the "original datagram" field MUST contain at least 128 octets. If the original datagram didn't have 128 octets, the "original datagram" field MUST be zero padded to 128 octets. (See Section 5.1 for the rationale.) This is the kind of detail that keeps everyone's parsers happy 🥹
The following sub-sections show the length attribute as it's been introduced to the selected ICMP messages. Let's go 🦋
4.1. ICMPv4 Destination Unreachable
Figure 1 shows the ICMPv4 Destination Unreachable Message 🎀
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | Next-Hop MTU* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: ICMPv4 Destination Unreachable
The syntax and semantics of all fields are unchanged from RFC 792. The one new thing is a length attribute in the second word 🧁 It represents the length of the padded "original datagram" field, measured in 32-bit words.
* The Next-Hop MTU field is not required in all cases. It's only shown to prove those bits aren't up for grabs in this memo 🙅♀️
4.2. ICMPv4 Time Exceeded
Figure 2 shows the ICMPv4 Time Exceeded Message ⭐
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: ICMPv4 Time Exceeded
The syntax and semantics of all fields are unchanged from RFC 792, except for a length attribute added to the second word 🦋 It represents the length of the padded "original datagram" field, measured in 32-bit words.
4.3. ICMPv4 Parameter Problem
Figure 3 shows the ICMPv4 Parameter Problem Message 🌸
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: ICMPv4 Parameter Problem
The syntax and semantics of all fields are unchanged from RFC 792, except for a length attribute added to the second word 💖 It represents the length of the padded "original datagram" field, measured in 32-bit words.
4.4. ICMPv6 Destination Unreachable
Figure 4 shows the ICMPv6 Destination Unreachable Message 🧚
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [RFC4443] |Figure 4: ICMPv6 Destination Unreachable
The syntax and semantics of all fields are unchanged from RFC 4443. The one new thing is a length attribute in the second word 🍓 It represents the length of the padded "original datagram" field, measured in 64-bit words.
4.5. ICMPv6 Time Exceeded
Figure 5 shows the ICMPv6 Time Exceeded Message 💜
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [RFC4443] |Figure 5: ICMPv6 Time Exceeded
The syntax and semantics of all fields are unchanged from RFC 4443, except for a length attribute added to the second word 🫶 It represents the length of the padded "original datagram" field, measured in 64-bit words.
4.6. ICMP Messages That Can Be Extended
The ICMP Extension Structure MAY be appended to messages of these types 🎀
- ICMPv4 Destination Unreachable
- ICMPv4 Time Exceeded
- ICMPv4 Parameter Problem
- ICMPv6 Destination Unreachable
- ICMPv6 Time Exceeded
The ICMP Extension Structure MUST NOT be appended to any of the other ICMP messages mentioned in Section 4. Extensions were never defined for the ICMPv6 "Packet Too Big" and "Parameter Problem" messages, because those messages don't have space for a length attribute 🙈💅
5. Backwards Compatibility 💖
okay bestie, let's talk about the whole crew of ICMP messages and how they get along 🧚 ICMP messages fall into three groups:
- Messages that do not include any ICMP extensions
- Messages that include non-compliant ICMP extensions
- Messages that include compliant ICMP extensions
Any ICMP implementation can send a message with no extensions, obviously ✨ ICMP implementations made before 1999 aren't known to send extensions at all 🙈
Then there are the implementations from 1999 up until this memo was published 💀 Some of them may send a non-compliant version of the ICMP extensions described here. They tack the ICMP Extension Structure onto Time Exceeded and Destination Unreachable messages. When they do, they send exactly 128 octets for the original datagram, with zero padding if it's needed. They even calculate checksums the way this document describes 🫶 But they don't specify a length attribute for the "original datagram" field, which is the part that makes this messy.
It's assumed that ICMP implementations made in the future will send extensions that are compliant with this specification 👑
Now the applications that consume ICMP messages also sort into three categories:
- Classic applications
- Non-compliant applications
- Compliant applications
Classic applications don't parse the extensions defined in this memo 🫠 They don't care about the length attribute tied to the "original datagram" field either.
Non-compliant applications do parse the extensions defined here, but only alongside Time Expired and Destination Unreachable messages. They need the "original datagram" field to contain exactly 128 octets, and they don't care about the length attribute. These were produced between 1999 and the time this memo was published 🌸
Compliant applications comply fully with the specifications of this document 💅
To show how backwards compatible all this is, Table 1 lays out how each application category would parse each category of ICMP message 🎀
+----------------+----------------+----------------+----------------+
| | No Extensions | Non-compliant | Compliant |
| | | Extensions | Extensions |
+----------------+----------------+----------------+----------------+
| Classic | - | Section 5.1 | Section 5.1 |
| Application | | | |
| | | | |
| Non-compliant | Section 5.2 | - | Section 5.3 |
| Application | | | |
| | | | |
| Compliant | Section 5.4 | Section 5.5 | - |
| Application | | | |
+----------------+----------------+----------------+----------------+
Table 1Any cell with a dash is the nominal case and needs no explanation 🍓 In the sections that follow, we assume that the ICMP message type is "Time Exceeded" ✨
5.1. Classic Application Receives ICMP Message with Extensions
When a classic application gets an ICMP message that includes extensions, it will wrongly read those extensions as part of the "original datagram" field 😭 The good news is that the extensions are guaranteed to begin at least 128 octets past the start of the "original datagram" field. So only the ICMP applications that process the 129th octet of that field will be adversely effected. So far, only two applications in this category have been identified, and the damage they take is minimal 🦋
Some TCP stacks verify the checksum in the original datagram field when they receive an ICMP message [ATTACKS] 🔐 If that checksum is incorrect, the TCP stack throws the ICMP message away for security reasons. If ICMP extensions overwrite the trailing octets of the original datagram field, the TCP stack will discard an ICMP message it otherwise wouldn't have discarded. The impact is considered minimal because plenty of ICMP messages get discarded for other reasons anyway (e.g., ICMP filtering, network congestion, checksum was incorrect because original datagram field was truncated.) 🙃
There's also a theoretically possible but highly improbably scenario 🙈 Extensions could overwrite the part of the original datagram field that holds the TCP header, so the TCP stack ends up operating on the wrong TCP connection. This is highly unlikely, because it only happens when the TCP header sits at or beyond the 128th octet of the original datagram field, and then only when the extensions look close enough to a valid TCP header.
5.2. Non-Compliant Application Receives ICMP Message with No Extensions
When a non-compliant ICMPv4 application gets a message with no extensions, it checks the total length of the ICMPv4 message 📏 If the total ICMPv4 message length is less than the length of its IP header plus 144 octets, the application correctly figures out that there are no extensions.
That 144-octet sum comes from 8 octets for the first two words of the ICMPv4 Time Exceeded message, 128 octets for the "original datagram" field, 4 octets for the ICMP Extension Header, and 4 octets for a single ICMP Object header. All of those octets would be required if extensions were present 🧩
If the ICMPv4 payload is 144 octets or more, the application must examine the 137th octet to see whether it's a valid ICMPv4 Extension Header 🔍 To count as a valid Extension Header, it has to contain a valid version number and checksum. If it doesn't, the application correctly figures out that there are no extensions.
Non-compliant applications assume the ICMPv4 Extension Structure begins on the 137th octet of the Time Exceeded message, right after the 128-octet field that holds the padded "original datagram" message 💜
A non-compliant application can parse an ICMPv4 message incorrectly under these conditions:
- the message does not contain extensions
- the original datagram field contains 144 octets or more
- selected octets of the original datagram field represent the correct values for an extension header version number and checksum
Although this is possible, it is very unlikely 🫣
A similar analysis can be done for ICMPv6. The numeric constants would just change as appropriate 🌈
5.3. Non-Compliant Application Receives ICMP Message with Compliant Extensions
When a non-compliant application gets a message with compliant ICMP extensions, it only parses those extensions correctly if the "original datagram" field contains exactly 128 octets 🎀 That's because non-compliant applications ignore the length attribute tied to the "original datagram" field. (They assume its value is 128.)
As long as the entire ICMP message doesn't exceed the minimum reassembly buffer size (576 octets for ICMPv4 or 1280 octets for ICMPv6), there's no upper limit on the length of the "original datagram" field 🙌 Each implementation decides how many octets to include, though. Anyone who wants to stay backward compatible with non-compliant TRACEROUTE implementations will include exactly 128 octets. Anyone who doesn't need that compatibility may include more 💅
5.4. Compliant Application Receives ICMP Message with No Extensions
When a compliant application gets an ICMP message, it checks the length attribute tied to the "original datagram" field 🔎 If the length attribute is zero, the compliant application MUST determine that the message contains no extensions 💖
5.5. Compliant Application Receives ICMP Message with Non-Compliant Extensions
When a compliant application gets an ICMP message, it checks the length attribute tied to the "original datagram" field 🔎 If the length attribute is zero, the compliant application MUST determine that the message contains no extensions. In this case that conclusion is technically correct, but it's not backwards compatible with the non-compliant implementation that sent the message 😬
So, to ease the transition while still encouraging compliant implementations 🫶 compliant TRACEROUTE implementations MUST include a non-default operation mode that also interprets non-compliant responses. Specifically, when a TRACEROUTE application in non-compliant mode receives a sufficiently long ICMP message that doesn't specify a length attribute, it parses for a valid extension header at a fixed location, assuming a 128-octet "original datagram" field. If the application detects a valid version and checksum, it treats the octets that follow as an extension structure ✨
6. Interaction with Network Address Translation 🦋
The ICMP extensions defined in this memo don't interfere with Network Address Translation 🌸 [RFC3022] allows traditional NAT devices to modify selected fields within ICMP messages. Those fields include the "original datagram" field mentioned above. However, if a NAT device modifies the "original datagram" field, it should modify only the leading octets of that field, which represent the outermost IP header. Because the outermost IP header is guaranteed to be contained within the first 128 octets of the "original datagram" field, ICMP extensions and NAT won't step on each other 🫶
It's conceivable that a NAT implementation might overstep the restrictions of RFC 3022 and overwrite the length attribute specified by this memo 😱 If a NAT implementation overwrote the length attribute with zeros, the resulting packet would be indistinguishable from a packet generated by a non-compliant ICMP implementation. See Section 5.5 for packet details and a discussion of backwards compatibility 💜
7. The ICMP Extension Structure ✨
okay bestie, this is where the extension structure shows up 🎀. It's an optional ICMP Extension Structure, and it can be tacked onto the ICMP messages we talked about in Section 4.6 of this document 💖
The Extension Structure has exactly one Extension Header, followed by one or more objects. When application software gets an ICMP message with extensions, it MAY process the selected objects and ignore the rest 🫶 Finding an object you don't recognize does NOT mean the ICMP message is malformed, so don't panic 😭
Quick reminder from earlier: the total length of the ICMP message, extensions included, MUST NOT exceed the minimum reassembly buffer size 🔥
Here's the ICMP Extension Header 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| (Reserved) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: ICMP Extension Header
The fields are:
Version: 4 bits. This is the ICMP extension version number, and it's version 2 🌸Reserved: 12 bits. Must be set to 0 🍓Checksum: 16 bits. This is the one's complement of the one's complement sum of the data structure, with the checksum field treated as zero while you compute it. An all-zero value means no checksum was sent. Check out Section 5.2 for how this field gets used 🧚
8. ICMP Extension Objects 💅
Every extension object holds one or more 32-bit words, made of an object header and payload. All object headers share the same format, so once you've got one, you've got them all 💜 Here's the object header and payload 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| // (Object payload) // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Object Header and Payload
An object header has these fields:
Length: 16 bits. This is the length of the object in octets, counting the object header and the object payload 🦄Class-Num: 8 bits. This identifies the object class ✨C-Type: 8 bits. This identifies the object sub-type 🎀
9. Security Considerations 🔥
⚠️ This section is serious business, bestie, so read it all 🙈
Once an ICMP message shows up, application software must check it for syntactic correctness. The extension checksum must be verified. Improperly specified length attributes and other syntax problems may result in buffer overruns. Yikes 💀
This memo does not define the conditions under which a router sends an ICMP message. So it does not expose routers to any new denial-of-service attacks, which is a relief 🫶 Routers may need to limit the rate at which ICMP messages are sent, though 👑
10. IANA Considerations 🌸
The ICMP Extension Object header has two 8-bit fields. Class-Num identifies the object class, and C-Type identifies the class sub-type. Sub-type values are defined relative to a specific object class value, and they're defined per class 🧚
IANA has set up a registry of ICMP extension object classes and class sub-types. This document doesn't assign any values to maintain 💅 Object classes 0xF7 - 0xFF are reserved for private use. Object class values are assignable on a first-come, first-serve basis. The policy for assigning sub-type values should be defined in the document that defines the new class values 🍓
11. Acknowledgments 💖
Thanks to Pekka Nikander, Mark Doll, Fernando Gont, Joe Touch, Christian Voiqt, and Sharon Chrisholm for their comments on this document 🫶
12. References 📚
12.1. Normative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD
5, RFC 792, September 1981.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
March 2006.12.2. Informative References
[UNNUMBERED] Atlas, A., Bonica, R., Rivers, JR., Shen, N., and E.
Chen, "ICMP Extensions for Unnumbered Interfaces",
Work in Progress, March 2007.
[MPLS-ICMP] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"ICMP Extensions for MultiProtocol Label Switching",
Work in Progress, January 2007.
[ATTACKS] Gont, F., "ICMP attacks against TCP", Work in
Progress, October 2006.
[ROUTING-INST] Shen, N. and E. Chen, "ICMP Extensions for Routing
Instances", Work in Progress, November 2006.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.Authors' Addresses 🧚
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
US
EMail: rbonica@juniper.net
Der-Hwa Gan
Consultant
EMail: derhwagan@yahoo.com
Daniel C. Tappan
Consultant
EMail: Dan.Tappan@gmail.com
Carlos Pignataro
Cisco Systems, Inc.
7025 Kit Creek Road
Research Triangle Park, NC 27709
US
EMail: cpignata@cisco.comFull Copyright Statement 🎀
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🌈
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶
📦 where this page comes from
- ietf: rfc4884 2007-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms