Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
obsoletes
- rfc-2463 — Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
updated by
- rfc-4884 — Extended ICMP to Support Multi-Part Messages
updates
- rfc-2780 — IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers
also
- std-89
Extracted elements (31)
A simple timer-based rate-limiting implementation (one error every T milliseconds) is explicitly not recommended because it cannot cope with bursty traffic such as traceroute. Token-bucket is the preferred approach, capable of handling legitimate bursts while enforcing a long-term average.
ICMPv6 includes a pseudo-header derived from IPv6 fields in the checksum calculation, which is a change from IPv4. This provides additional integrity coverage over the IP source and destination addresses.
ICMPv6 error messages are required to contain exactly 32 bits of type-specific data (the Unused/MTU/Pointer field) so that receivers can reliably locate the embedded invoking packet even when they do not recognize the ICMP message Type. This is a structural constraint added relative to RFC 2463.
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.
A Packet Too Big MUST be sent by a router in response to a packet it cannot forward because the packet is larger than the MTU of the outgoing link. As an exception to normal rules, it is sent even in response to packets with multicast, link-layer multicast, or link-layer broadcast destination addresses.
An Echo Reply SHOULD be sent in response to an Echo Request 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 was received.
An ICMPv6 error message MUST NOT be originated in response to: another ICMPv6 error message, an ICMPv6 redirect message, a packet destined to an IPv6 multicast address (with two exceptions), a link-layer multicast or broadcast, or a packet whose source address does not uniquely identify a single node.
An IPv6 node MUST limit the rate of ICMPv6 error messages it originates. A token-bucket mechanism is recommended, limiting average rate to N packets/second or a fraction of link bandwidth while allowing bursts up to B messages. Rate-limiting parameters SHOULD be configurable.
Every ICMPv6 error message (Type < 128) MUST include as much of the IPv6 offending packet as possible without making the error message exceed the minimum IPv6 MTU.
Every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and originates corresponding Echo Replies. A node SHOULD also implement an application-layer interface for originating Echo Requests and receiving Echo Replies, for diagnostic purposes.
ICMPv6 is an integral part of IPv6, and the base protocol — all messages and behavior required by this specification — MUST be fully implemented by every IPv6 node.
If a router receives a packet with a Hop Limit of zero, or decrements a packet's Hop Limit to zero, it MUST discard the packet and originate an ICMPv6 Time Exceeded message with Code 0 to the source of the packet.
If an ICMPv6 error message of unknown type is received, it MUST be passed to the upper-layer process that originated the invoking packet. If an ICMPv6 informational message of unknown type is received, it MUST be silently discarded.
If an IPv6 node finds a problem with a field in the IPv6 header or extension headers such that it cannot complete processing, it MUST discard the packet and SHOULD originate an ICMPv6 Parameter Problem message to the packet's source indicating the type and location of the problem.
The data received in an ICMPv6 Echo Request message MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message. The source address of an Echo Reply to a unicast Echo Request MUST be the same as the destination address of that Echo Request.
When a node originating an ICMPv6 message has more than one unicast address, it MUST choose the source address as follows: if the message is a response to a packet sent to one of the node's unicast addresses, the source address of the reply MUST be that same address; otherwise it MUST be a unicast address belonging to the node.
Destination Unreachable codes: 0=No route, 1=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. Codes 5 and 6 are more informative subsets of code 1.
ICMPv6 is identified by a Next Header value of 58 in the immediately preceding IPv6 header. This value differs from the value used to identify ICMP for IPv4, making ICMPv6 a distinct protocol.
New ICMPv6 type codes from IETF RFC publication require permanent IANA registration. Working groups may request reclaimable type code assignments with WG consensus and AD approval; at 85% assignment saturation, reclaimable values are reviewed. External requests require an IETF document; RFC Editor contributions do not qualify.
The IANA ICMPv6 parameters registry (icmpv6-parameters) is updated by this document. New assignments include: Type 1 Code 2 (Beyond scope of source address), Type 1 Codes 5 and 6, Type values 100, 101 (private experimentation), 127 (reserved for error message expansion), 200, 201 (private experimentation), and 255 (reserved for informational message expansion).
ICMP messages may be used to attempt denial-of-service attacks by sending back-to-back erroneous IP packets. Correct implementation of the rate-limiting mechanism in Section 2.4(f) provides the primary defense against this attack.
ICMP messages passed to upper-layer processes can be used to attack upper-layer protocols such as TCP. It is recommended that upper layers perform validation of ICMP messages (using payload content) before acting upon them; protecting upper layers with IPsec mitigates these attacks.
ICMPv6 messages can be authenticated using the IP Authentication Header (AH) or protected for confidentiality using the Encapsulating Security Payload (ESP). AH protects source and destination addresses; the combination of ICMPv6 checksum and ESP also provides protection against redirection attacks.
The Parameter Problem exception for multicast traffic (rule e.3 exception 2) can be exploited: a malicious node near a multicast source can spoof multicast packets with unknown mandatory destination options, causing many destination nodes to flood ICMP error messages back to the multicast source. Securing multicast traffic is the only mitigation.
Destination Unreachable (Type 1) message: 8-bit Type, 8-bit Code, 16-bit Checksum, 32-bit Unused (initialized to zero), followed by as much of the invoking packet as possible without exceeding the minimum IPv6 MTU. Codes 0–6 indicate specific unreachability reasons.
Echo Request (Type 128) and Echo Reply (Type 129) messages share a format: 8-bit Type, 8-bit Code (0), 16-bit Checksum, 16-bit Identifier, 16-bit Sequence Number, and zero or more octets of arbitrary Data. There is no limitation on the amount of data.
Every ICMPv6 message begins with a fixed 32-bit header: Type (8 bits), Code (8 bits), and Checksum (16 bits), followed by a variable-length Message Body. Error messages have Type values 0–127 (high-order bit zero); informational messages have Type values 128–255.
Packet Too Big (Type 2) message: 8-bit Type, 8-bit Code (set to 0), 16-bit Checksum, 32-bit MTU field containing the Maximum Transmission Unit of the next-hop link, followed by as much of the invoking packet as possible without exceeding the minimum IPv6 MTU.
Parameter Problem (Type 4) message: 8-bit Type, 8-bit Code (0=Erroneous header field, 1=Unrecognized Next Header type, 2=Unrecognized IPv6 option), 16-bit Checksum, 32-bit Pointer identifying the octet offset within the invoking packet where the error was detected.
The ICMPv6 checksum is the 16-bit one's complement of the one's complement sum of the entire ICMPv6 message, prepended with a pseudo-header of IPv6 fields (Next Header value 58). The checksum field is set to zero before computation.
Time Exceeded (Type 3) message: 8-bit Type, 8-bit Code (0=Hop limit exceeded in transit, 1=Fragment reassembly time exceeded), 16-bit Checksum, 32-bit Unused (zero), followed by as much of the invoking packet as possible without exceeding the minimum IPv6 MTU.