RFC 4443
Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
📜 RFC 4443: ICMPv6 for IPv6, the Spec 💖
okay bestie, this is RFC 4443, and it's the official spec for ICMPv6 (Internet Control Message Protocol for IPv6) 🦋 The title is Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.
It came out in March 2006 from the Network Working Group and is on the Standards Track 🎀 The authors are A. Conta (Transwitch), S. Deering (Cisco Systems), and M. Gupta, Ed. (Tropos Networks). The "Ed." just means Gupta was the editor 💅
This doc obsoletes RFC 2463 (so 2463 is retired now 🫶) and updates RFC 2780 🌸
Table of Contents ✨
1. Introduction ....................................................2
2. ICMPv6 (ICMP for IPv6) ..........................................3
2.1. Message General Format .....................................3
2.2. Message Source Address Determination .......................5
2.3. Message Checksum Calculation ...............................5
2.4. Message Processing Rules ...................................5
3. ICMPv6 Error Messages ...........................................8
3.1. Destination Unreachable Message ............................8
3.2. Packet Too Big Message ....................................10
3.3. Time Exceeded Message .....................................11
3.4. Parameter Problem Message .................................12
4. ICMPv6 Informational Messages ..................................13
4.1. Echo Request Message ......................................13
4.2. Echo Reply Message ........................................14
5. Security Considerations ........................................15
5.1. Authentication and Confidentiality of ICMP Messages .......15
5.2. ICMP Attacks ..............................................16
6. IANA Considerations ............................................17
6.1. Procedure for New ICMPV6 Type and Code Value Assignments ..17
6.2. Assignments for This Document .............................18
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................19
8. Acknowledgements ...............................................20
Appendix A - Changes since RFC 2463................................21Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 🌈
Copyright Notice 🔥
Copyright (C) The Internet Society (2006).
Abstract 💜
This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). It's the whole main-character energy of ICMP, but for IPv6 🧚
1. Introduction ✨
okay so IPv6 uses ICMP (as defined for IPv4 in [RFC-792]), but with a bunch of changes 🌸 The result is called ICMPv6, and its IPv6 Next Header value is 58. iconic 👑
This doc describes the format of a set of control messages used in ICMPv6. It does not describe the procedures for using these messages to do things like Path MTU discovery. Those procedures live in other documents (for example, [PMTU]). Other documents may also add extra ICMPv6 message types, like Neighbor Discovery messages [IPv6-DISC], but they still have to follow the general ICMPv6 rules from Section 2 of this document 🦋
Terminology from the IPv6 specification [IPv6] and the IPv6 Routing and Addressing specification [IPv6-ADDR] applies here too. Same vocab, no cap 💅
This document obsoletes RFC 2463 [RFC-2463] and updates RFC 2780 [RFC-2780]. 🎀
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]. These are the official BCP 14 requirement words, and they're the ones to watch for 👀
2. ICMPv6 (ICMP for IPv6) ✨
ICMPv6 is used by IPv6 nodes to report errors they run into while processing packets, and to do other internet-layer stuff like diagnostics (the ICMPv6 "ping") 🍓 ICMPv6 is an integral part of IPv6. The base protocol (all the messages and behavior this spec requires) MUST be fully implemented by every IPv6 node. No skipping, bestie 😭
2.1. Message General Format
Every ICMPv6 message is preceded by an IPv6 header and zero or more IPv6 extension headers. The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header. (This is different from the value used to identify ICMP for IPv4.) 🌈
The ICMPv6 messages have this general format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Message Body +
| |The type field tells you what kind of message it is. Its value decides the format of the rest of the data 🧚
The code field depends on the message type. It adds an extra level of granularity to the message 💅
The checksum field is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header 🫶
ICMPv6 messages are split into two classes: error messages and informational messages. Error messages are marked by a zero in the high-order bit of their message Type field values, so error messages have types from 0 to 127. Informational messages have types from 128 to 255. ✨
This document defines the message formats for these ICMPv6 messages:
ICMPv6 error messages:
1 Destination Unreachable (see Section 3.1)
2 Packet Too Big (see Section 3.2)
3 Time Exceeded (see Section 3.3)
4 Parameter Problem (see Section 3.4)
100 Private experimentation
101 Private experimentation
127 Reserved for expansion of ICMPv6 error messages
ICMPv6 informational messages:
128 Echo Request (see Section 4.1)
129 Echo Reply (see Section 4.2)
200 Private experimentation
201 Private experimentation
255 Reserved for expansion of ICMPv6 informational messagesType values 100, 101, 200, and 201 are reserved for private experimentation. They're not meant for general use 🧪 It's expected that multiple concurrent experiments will use the same type values. Any wide-scale and/or uncontrolled usage should get real allocations as defined in Section 6, so don't just freestyle it 🙈
Type values 127 and 255 are reserved for future expansion of the type value range, in case there's a shortage later. The details are left for future work. One possible way to do it that wouldn't cause problems with current implementations is this: if the type equals 127 or 255, the code field should be used for the new assignment. Existing implementations would ignore the new assignments as specified in Section 2.4, (b). The new messages using these expanded type values could assign fields in the message body for their code values. It's giving future-proof 🔮
Sections 3 and 4 describe the message formats for the ICMPv6 error message types 1 through 4, and the informational message types 128 and 129 💖
Including, at the very least, the start of the invoking packet is meant to let the originator of a packet that caused an ICMPv6 error message figure out which upper-layer protocol and process sent the packet. Tea 🍵
2.2. Message Source Address Determination
A node that originates an ICMPv6 message MUST figure out both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it MUST choose the Source Address of the message as follows: 🌸
(a) If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be that same address. Simple and slay ✨
(b) If the message is a response to a message sent to any other address, such as:
- a multicast group address,
- an anycast address implemented by the node, or
- a unicast address that does not belong to the node
then the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. The address SHOULD be chosen according to the rules that would be used to pick the source address for any other packet the node originates, given the destination address of the packet. However, it MAY be selected in an alternative way if that would lead to a more informative choice of address reachable from the destination of the ICMPv6 packet. 🦋 Okay this one has layers, but it's so worth it
2.3. Message Checksum Calculation
The checksum is the 16-bit one's complement of the one's complement sum of the entire ICMPv6 message, starting with the ICMPv6 message type field, and prepended with a "pseudo-header" of IPv6 header fields, as specified in [IPv6, Section 8.1]. The Next Header value used in the pseudo-header is 58. (Including a pseudo-header in the ICMPv6 checksum is a change from IPv4. See [IPv6] for the rationale behind that change.) 🎀
For computing the checksum, the checksum field is first set to zero. Reset the vibes first, then add everything up 🧮💜
(part 2 is next, bestie 🫶)
2.4. Message Processing Rules 🎀
okay bestie, listen up because these are the rules for processing ICMPv6 messages (from [RFC-1122]) 💅 Implementations MUST observe all of them:
- (a) If an ICMPv6 error message of unknown type lands at its destination, it MUST be passed up to the upper-layer process that originated the packet that caused the error, as long as that process can be identified (see Section 2.4, (d)). 🦋
- (b) If an ICMPv6 informational message of unknown type shows up, it MUST be silently discarded. 🙈
- (c) Every ICMPv6 error message (type < 128) MUST include as much of the IPv6 offending (invoking) packet (the packet that caused the error) as possible, without making the error message packet exceed the minimum IPv6 MTU [IPv6]. 🧚
- (d) When the internet-layer protocol is required to pass an ICMPv6 error message to the upper-layer process, the upper-layer protocol type is pulled out of the original packet (the one sitting in the body of the ICMPv6 error message) and used to pick the right upper-layer process to handle the error. 🔥
If it's NOT possible to retrieve the upper-layer protocol type from the ICMPv6 message, the ICMPv6 message is silently dropped after any IPv6-layer processing. One example is an ICMPv6 message with an unusually large amount of extension headers that doesn't have the upper-layer protocol type because the original packet got truncated to meet the minimum IPv6 MTU [IPv6] limit. Another example is an ICMPv6 message with an ESP extension header where it's not possible to decrypt the original packet, either because of truncation or because the state needed to decrypt it isn't available. 💀
- (e) An ICMPv6 error message MUST NOT be originated as a result of receiving any of the following:
- (e.1) An ICMPv6 error message. 🙅♀️
- (e.2) An ICMPv6 redirect message [IPv6-DISC]. 🙅♀️
- (e.3) A packet destined to an IPv6 multicast address. (There are two exceptions to this rule: (1) the Packet Too Big Message (Section 3.2), so Path MTU discovery can work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 (Section 3.4), reporting an unrecognized IPv6 option (see Section 4.2 of [IPv6]) whose Option Type has its highest-order two bits set to 10.) ✨
- (e.4) A packet sent as a link-layer multicast (the exceptions from e.3 apply here too). 🌸
- (e.5) A packet sent as a link-layer broadcast (the exceptions from e.3 apply here too). 🌸
- (e.6) A packet whose source address does not uniquely identify a single node, e.g., the IPv6 Unspecified Address, an IPv6 multicast address, or an address known by the ICMP message originator to be an IPv6 anycast address. 👑
- (f) Finally, to limit the bandwidth and forwarding costs that come with originating ICMPv6 error messages, an IPv6 node MUST limit the rate of ICMPv6 error messages it originates. This can happen when a source sending a stream of erroneous packets doesn't heed the ICMPv6 error messages it gets back. 🫶
Rate-limiting of forwarded ICMP messages is out of scope of this specification.
A recommended way to build the rate limiter is a token bucket, which limits the average rate of transmission to N. N can be either packets/second or a fraction of the attached link's bandwidth, but it lets you send up to B error messages in a burst, as long as the long-term average isn't exceeded. 🪣
Rate-limiting mechanisms that can't cope with bursty traffic (e.g., traceroute) are not recommended. For example, a simple timer-based approach that allows an error message every T milliseconds (even with low values for T) is not reasonable. 🙅♀️
The rate-limiting parameters SHOULD be configurable. With a token-bucket implementation, the best defaults depend on where the implementation is expected to be deployed (e.g., a high-end router vs. an embedded host). For example, in a small/mid-size device, the possible defaults could be B=10, N=10/s. 🍓
NOTE: THE RESTRICTIONS UNDER (e) AND (f) ABOVE TAKE PRECEDENCE OVER ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR ORIGINATING ICMP ERROR MESSAGES. 🚨
The next sections describe the message formats for the ICMPv6 messages above. 🌈
3. ICMPv6 Error Messages ✨
3.1. Destination Unreachable Message 💌
Here's the layout of a 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |The IPv6 and ICMPv6 fields look like this:
IPv6 Fields:
Destination Address
Copied from the Source Address field of the invoking
packet.
ICMPv6 Fields:
Type 1
Code 0 - No route to destination
1 - Communication with destination
administratively prohibited
2 - Beyond scope of source address
3 - Address unreachable
4 - Port unreachable
5 - Source address failed ingress/egress policy
6 - Reject route to destination
Unused This field is unused for all code values.
It must be initialized to zero by the originator
and ignored by the receiver.Description 🌷
A Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that can't be delivered to its destination address for reasons other than congestion. (An ICMPv6 message MUST NOT be generated if a packet is dropped due to congestion.) 🚫
If the reason for the failure to deliver is a lack of a matching entry in the forwarding node's routing table, the Code field is set to 0. 🗺️
(This error can occur only in nodes that do not hold a "default route" in their routing tables.)
If the reason for the failure to deliver is administrative prohibition (e.g., a "firewall filter"), the Code field is set to 1. 🚧
If the reason for the failure to deliver is that the destination is beyond the scope of the source address, the Code field is set to 2. This can only happen when the scope of the source address is smaller than the scope of the destination address (e.g., when a packet has a link-local source address and a global-scope destination address) and the packet can't be delivered to the destination without leaving the scope of the source address. 🔭
If the reason for the failure to deliver can't be mapped to any of the other codes, the Code field is set to 3. Examples are an inability to resolve the IPv6 destination address into a corresponding link address, or some link-specific problem. 🤷♀️
One specific case where a Destination Unreachable message is sent with code 3 is when a router receives a packet from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In that case, the packet MUST NOT be forwarded back onto the arrival link. 🔁
A destination node SHOULD originate a Destination Unreachable message with Code 4 in response to a packet for which the transport protocol (e.g., UDP) has no listener, if that transport protocol has no alternative means to inform the sender. 👂
If the reason for the failure to deliver is that the packet with this source address isn't allowed due to ingress or egress filtering policies, the Code field is set to 5. 🛂
If the reason for the failure to deliver is that the route to the destination is a reject route, the Code field is set to 6. This may happen if the router has been configured to reject all the traffic for a specific prefix. 🙅♀️
Codes 5 and 6 are more informative subsets of code 1. 💡
For security reasons, it is recommended that implementations SHOULD allow sending of ICMP destination unreachable messages to be disabled, preferably on a per-interface basis. 🔐
Upper Layer Notification 📬
A node receiving the ICMPv6 Destination Unreachable message MUST notify the upper-layer process if the relevant process can be identified (see Section 2.4, (d)). 🫶
3.2. Packet Too Big Message 📦
Here's the layout of a Packet Too Big 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |The IPv6 and ICMPv6 fields look like this:
IPv6 Fields:
Destination Address
Copied from the Source Address field of the invoking
packet.
ICMPv6 Fields:
Type 2
Code Set to 0 (zero) by the originator and ignored by the
receiver.
MTU The Maximum Transmission Unit of the next-hop link.Description 🚀
A Packet Too Big MUST be sent by a router in response to a packet that it can't forward because the packet is larger than the MTU of the outgoing link. The information in this message is used as part of the Path MTU Discovery process [PMTU]. 📏
Originating a Packet Too Big message makes an exception to one of the rules about when to originate an ICMPv6 error message. Unlike other messages, it is sent in response to a packet received with an IPv6 multicast destination address, or with a link-layer multicast or link-layer broadcast address. 🌟
Upper Layer Notification 📬
An incoming Packet Too Big message MUST be passed to the upper-layer process if the relevant process can be identified (see Section 2.4, (d)). 💖
3.3. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |IPv6 Fields:
- Destination Address: Copied from the Source Address field of the invoking packet.
ICMPv6 Fields:
- Type:
3 - Code:
0- Hop limit exceeded in transit1- Fragment reassembly time exceeded
- Unused:
This field is unused for all code values. It must be initialized to zero by the originator and ignored by the receiver.Basically, this one's a no-touch zone 🧸
Description
okay so if a router gets a packet with a Hop Limit of zero, or it drops the Hop Limit to zero itself, it MUST discard the packet and originate an ICMPv6 Time Exceeded message with Code 0 to the source of the packet 🚫 this basically tells the sender either there's a routing loop going on, or the starting Hop Limit was way too small, bestie 😭
Code 1 is the one for fragment reassembly timeout 🧩 it's used to report that, as specified in [IPv6, Section 4.5].
Upper Layer Notification
An incoming Time Exceeded message MUST be passed to the upper-layer process if the relevant process can be identified (see Section 2.4, (d)). the main character of this message is literally the upper layer that needs to hear about it 💜
3.4. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |IPv6 Fields:
- Destination Address: Copied from the Source Address field of the invoking packet.
ICMPv6 Fields:
- Type:
4 - Code:
0- Erroneous header field encountered1- Unrecognized Next Header type encountered2- Unrecognized IPv6 option encountered
- Pointer: Identifies the octet offset within the invoking packet where the error was detected. The pointer will point beyond the end of the ICMPv6 packet if the field in error is beyond what can fit in the maximum size of an ICMPv6 error message. 🔍
Description
so if an IPv6 node is processing a packet and finds a problem with a field in the IPv6 header or extension headers that means it can't finish processing the packet, it MUST discard the packet and SHOULD originate an ICMPv6 Parameter Problem message to the packet's source 🙅♀️ the message says what kind of problem it was and where it happened.
Codes 1 and 2 are just more specific versions of Code 0 🤓
The pointer tells you the octet of the original packet's header where things went wrong. For example, a message with a Type field of 4, a Code field of 1, and a Pointer field of 40 would mean the IPv6 extension header right after the original packet's IPv6 header has a Next Header field value nobody recognizes 💀
Upper Layer Notification
A node receiving this ICMPv6 message MUST notify the upper-layer process if the relevant process can be identified (see Section 2.4, (d)). the receiving node has to spill the tea to the right process, no excuses 🫶
4. ICMPv6 Informational Messages 🌸
4.1. Echo Request 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-IPv6 Fields:
- Destination Address: Any legal IPv6 address.
ICMPv6 Fields:
- Type:
128 - Code:
0 - Identifier: An identifier to aid in matching Echo Replies to this Echo Request. May be zero.
- Sequence Number: A sequence number to aid in matching Echo Replies to this Echo Request. May be zero.
- Data: Zero or more octets of arbitrary data.
Description
this is the ping 🏓 and every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and originates corresponding Echo Replies, no ghosting allowed 👻 A node SHOULD also implement an application-layer interface for originating Echo Requests and receiving Echo Replies, for diagnostic purposes 🔧
Upper Layer Notification
Echo Request messages MAY be passed to processes receiving ICMP messages. so the upper layers can peek at these if they want 👀
4.2. Echo Reply 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-IPv6 Fields:
- Destination Address: Copied from the Source Address field of the invoking Echo Request packet.
ICMPv6 Fields:
- Type:
129 - Code:
0 - Identifier: The identifier from the invoking Echo Request message.
- Sequence Number: The sequence number from the invoking Echo Request message.
- Data: The data from the invoking Echo Request message.
Description
the reply that echoes everything back 💅 every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and originates corresponding Echo Replies, and a node SHOULD also implement an application-layer interface for originating Echo Requests and receiving Echo Replies, for diagnostic purposes 🩺
The source address of an Echo Reply sent in response to a unicast Echo Request message MUST be the same as the destination address of that Echo Request message. it has to match, no switching identities mid-convo 🦋
An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address. In this case, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received. 📡
The data received in the ICMPv6 Echo Request message MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message. no editing the vibes, the whole payload comes back exactly as it arrived 🍓
Upper Layer Notification
Echo Reply messages MUST be passed to the process that originated an Echo Request message. An Echo Reply message MAY be passed to processes that did not originate the Echo Request message.
Note that there is no limitation on the amount of data that can be put in Echo Request and Echo Reply Messages. 🫧
5. Security Considerations 🔐
5.1. Authentication and Confidentiality of ICMP Messages 🕵️♀️
ICMP protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH] or IP Encapsulating Security Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol packet exchanges can be achieved using the IP Encapsulating Security Payload Header [IPv6-ESP]. This is the part where you lock the door 🔒
[SEC-ARCH] describes the IPsec handling of ICMP traffic in detail. 📚
5.2. ICMP Attacks
okay so ICMP messages can get attacked too 😭 The full tea lives in the IP Security Architecture [IPv6-SA], but here's the quick version bestie 🫶
- ICMP messages can be tampered with so the receiver thinks the message came from a different source than the one who actually sent it 🕵️♀️ The fix is applying the IPv6 Authentication mechanism [IPv6-AUTH] to the ICMP message 🔐
- ICMP messages can also be manipulated so the message, or the reply to it, ends up going to a destination the originator never intended 🙈 You can protect against this by using the Authentication Header [IPv6-AUTH] or the Encapsulating Security Payload Header [IPv6-ESP]. The Authentication Header protects against changes to the source and destination addresses of the IP packet, which is giving main character energy 👑 The Encapsulating Security Payload Header doesn't give you that same protection, but the ICMP checksum calculation includes the source and destination addresses, and the Encapsulating Security Payload Header protects the checksum. So the ICMP checksum plus the Encapsulating Security Payload Header together protect against this attack 💜 The protection from the Encapsulating Security Payload Header will not be as strong as the protection from the Authentication Header, so keep that in mind 🫠
- ICMP messages can have their message fields or payload changed 😤 The authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message protects against those actions 🔒
- ICMP messages can be used for denial-of-service attacks by sending back to back erroneous IP packets 💀 An implementation that correctly followed Section 2.4, paragraph (f), of this specification would be protected by the ICMP error rate limiting mechanism 🛡️
- The exception number 2 of rule e.3 in Section 2.4 gives a malicious node the chance to cause a denial-of-service attack against a multicast source 🚨 Here's how it goes: a malicious node sends a multicast packet with an unknown destination option marked as mandatory, using the IPv6 source address of a valid multicast source. A large number of destination nodes then send an ICMP Parameter Problem Message to the multicast source, which causes the denial-of-service attack. The way multicast traffic is forwarded by the multicast routers means the malicious node has to be part of the correct multicast path, so it has to be near the multicast source 📍 This attack can only be avoided by securing the multicast traffic 🔐 The multicast source should be careful when sending multicast traffic with destination options marked as mandatory, because those can cause a denial-of-service attack against the source itself if the destination option is unknown to a large number of destinations 🥲
- Once ICMP messages are passed up to the upper-layer processes, attacks on upper layer protocols (e.g., TCP) become possible with ICMP [TCP-attack] 😱 It is recommended that the upper layers perform some form of validation of ICMP messages, using the information in the payload of the ICMP message, before acting on them ✅ The actual validation checks are specific to the upper layers and are out of the scope of this specification. Protecting the upper layer with IPsec mitigates these attacks 🛡️
ICMP error messages signal network error conditions that were encountered while processing an internet datagram 📡 Depending on the scenario, the error conditions being reported might or might not get solved in the near term. So reacting to ICMP error messages may depend not only on the error type and code, but also on other factors, such as the time the error messages are received, previous knowledge of the network error conditions being reported, and knowledge of the network scenario the receiving host is operating in 🧠
6. IANA Considerations ✨
6.1. Procedure for New ICMPV6 Type and Code Value Assignments
okay so the IPv6 ICMP header defined in this document has two fields that carry values assigned from IANA-managed name spaces: Type and Code 📋 Code field values are defined relative to a specific Type value 💅
Values for the IPv6 ICMP Type fields are allocated using the following procedure 👇
- The IANA should allocate and permanently register new ICMPv6 type codes from IETF RFC publication. This covers all RFC types, including standards track, informational, and experimental status, that originate from the IETF and have been approved by the IESG for publication 🎀
- IETF working groups with working group consensus and area director approval can request reclaimable ICMPV6 type code assignments from the IANA 🌸 The IANA will tag the values as "reclaimable in future".
The "reclaimable in the future" tag will be removed when an RFC is published that documents the protocol as defined in 1. That makes the assignment permanent and updates the reference on the IANA web pages ✨
When the ICMPv6 type values are 85% assigned, the IETF will review the assignments tagged "reclaimable in the future" and tell the IANA which ones should be reclaimed and reassigned ♻️
- Requests for new ICMPv6 type value assignments from outside the IETF are only made through the publication of an IETF document, per 1 above 📚 Note also that documents published as "RFC Editor contributions" [RFC-3978] are not considered IETF documents 🙅♀️
The assignment of new Code values for the Type values defined in this document require standards action or IESG approval 🔑 The policy for assigning Code values for new IPv6 ICMP Types not defined in this document should be defined in the document defining the new Type values 🦋
6.2. Assignments for This Document
the updated assignments are located at 👀
The IANA reassigned ICMPv6 type 1 "Destination Unreachable" code 2, which was unassigned in [RFC-2463], to:
2 - Beyond scope of source addressThe IANA assigned the following two new code values for ICMPv6 type 1 "Destination Unreachable":
5 - Source address failed ingress/egress policy
6 - Reject route to destinationThe IANA assigned the following new type values 🧚
100 Private experimentation
101 Private experimentation
127 Reserved for expansion of ICMPv6 error messages
200 Private experimentation
201 Private experimentation
255 Reserved for expansion of ICMPv6 informational messages7. References 📖
7.1. Normative References
[IPv6]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.[IPv6-DISC]Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.[RFC-792]Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.[RFC-2463]Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.[RFC-1122]Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.[RFC-2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC-3978]Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
7.2. Informative References
[RFC-2780]Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.[IPv6-ADDR]Hinden, R. and S. Deering, "Intpernet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.[PMTU]McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.[IPv6-SA]Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.[IPv6-AUTH]Kent, S., "IP Authentication Header", RFC 4302, December 2005.[IPv6-ESP]Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4203, December 2005.[SEC-ARCH]Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.[TCP-attack]Gont, F., "ICMP attacks against TCP", Work in Progress.
8. Acknowledgements 🫶
The document is derived from previous ICMP documents of the SIPP and IPng working group 🌈
The IPng working group, and particularly Robert Elz, Jim Bound, Bill Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner, Dimitri Haskin, Bob Hinden, Jun-ichiro Itojun Hagino, Tatuya Jinmei, Brian Zill, Pekka Savola, Fred Templin, and Elwyn Davies (in chronological order) provided extensive review information and feedback 💖
Bob Hinden was the document editor for this document 👑
Appendix A - Changes since RFC 2463 ✨
Okay bestie, this is the changelog 📜 and it's giving glow-up. Here's everything that changed from RFC 2463 to this one 💅
- Glowed up the Abstract 💖 and made it a little more elaborate.
- Fixed some typos in Section 2.4 🎀 where references to sub-bullet
e.2were supposed to be references toe.3. - Yeeted the Timer-based and Bandwidth-based methods out of the example rate-limiting mechanism for ICMP error messages 🗑️ and added a Token-bucket based method ✨.
- Added specification that all ICMP error messages shall have exactly 32 bits of type-specific data 🦋, so receivers can reliably find the embedded invoking packet even when they don't recognize the ICMP message Type. Literally so important.
- In Destination Unreachable messages, Code 3, added a rule prohibiting forwarding packets back onto point-to-point links they were received from, if their destination addresses belong to that link itself (the "anti-ping-ponging" rule) 🏓🚫. No ping-pong allowed, periodt.
- Added a description of Time Exceeded Code 1 (fragment reassembly timeout) ⏳.
- Added "beyond scope of source address", "source address failed ingress/egress policy", and "reject route to destination" messages to the family of "unreachable destination" type ICMP error messages (Section 3.1) 🚧.
- Reserved some ICMP type values for experimentation 🧪🌈.
- Added a NOTE in Section 2.4 that specifies the precedence of ICMP message processing rules 👑.
- Added ICMP REDIRECT to the list in Section 2.4, (e) of cases where ICMP error messages are not to be generated 🙅♀️.
- Made minor editorial changes in Section 2.3 on checksum calculation 🧮, and in Section 5.2.
- Clarified in Section 4.2, regarding the Echo Reply Message 🏓: the source address of an Echo Reply to an anycast Echo Request should be a unicast address, just like in the multicast case.
- Revised the Security Considerations section 🔐. Added the use of the Encapsulating Security Payload Header for authentication 🛡️. Changed the requirement of an option of "not allowing unauthenticated ICMP messages" to MAY from SHOULD 🙈.
- Added a new attack to the list of possible ICMP attacks in Section 5.2 😭.
- Separated References into Normative and Informative 📚.
- Added a reference to RFC 2780 "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" 🧾. Also added a note that this document updates RFC 2780.
- Added a procedure for new ICMPv6 Type and Code value assignments in the IANA Considerations section 📋.
- Replaced the word "send" with "originate" 🎯, so it's crystal clear that ICMP packets being forwarded are out of scope for this spec.
- Changed the ESP and AH references to the updated ESP and AH documents 🔄.
- Added a reference to the updated IPsec Security Architecture document 📘.
- Added a SHOULD requirement for allowing the sending of ICMP destination unreachable messages to be disabled 🎛️.
- Simplified the source address selection of the ICMPv6 packet 💫.
- Reorganized the General Message Format (Section 2.1) 🗂️.
- Removed the general packet format from Section 2.1. It now refers to Sections 3 and 4 for packet formats 👉.
- Added text about attacks to the transport protocols that could potentially be caused by ICMP ⚠️.
Authors' Addresses
Alex Conta
Transwitch Corporation
3 Enterprise Drive
Shelton, CT 06484
USA
EMail: aconta@txc.com
Stephen Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Mukesh Gupta, Ed.
Tropos Networks
555 Del Rey Avenue
Sunnyvale, CA 94085
Phone: +1 408-331-6889
EMail: mukesh.gupta@tropos.comFull Copyright Statement
Copyright (C) The Internet Society (2006). 🌸
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 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
Okay, the legal bit, but make it cute 🎀. The IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope, and it doesn't say whether any license under those rights might be available. It also doesn't claim to have independently hunted for any such rights. If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79 📖.
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that are going to be made available, and the results of any attempt to get a general license or permission for implementers or users to use proprietary rights can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍.
The IETF invites any interested party to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🫶🌈
📦 where this page comes from
- ietf: rfc4443 2006-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms