ICMPv6 Errors for Discarding Packets Due to Processing Limits
Extracted elements (25)
The aggregate header limit error uses the Destination Unreachable type (not Parameter Problem) because it may apply to protocol headers beyond IPv6 and IPv6 extension headers—such as encapsulating UDP headers—and the multi-part ICMPv6 format (RFC 4884) accommodates a Pointer extension without being constrained to IPv6-only header errors.
The 'Headers too long' Destination Unreachable error is assigned the lowest reporting priority because it is a coarse-grained error applicable to aggregate header size, whereas the Parameter Problem codes identify specific extension header or option violations that are more actionable for a sender.
The specification acknowledges nonconformant packet discard (e.g., intermediate nodes dropping packets they cannot parse for transport-layer filtering) and deliberately provides ICMP error codes for these cases, taking the position that visibility into packet loss is more valuable than withholding error reporting for nonconformant behavior.
Code 5 (Unrecognized Next Header by intermediate node) is distinct from RFC 8200's existing code 1 (Unrecognized Next Header by final destination). Final destinations encountering an unrecognized Next Header SHOULD use code 1, not code 5, to preserve semantic distinction between intermediate and destination processing.
ICMP is fundamentally unreliable and may fail over some paths. No protocol should be implemented that relies on reliable delivery of the ICMP errors defined in this document; alternative mechanisms such as PLPMTUD (RFC 4821) or Happy Eyeballs (RFC 8305) may be correlated to augment diagnosis.
A host MAY modify its usage of protocol headers in subsequent packets to avoid repeated occurrences of the same processing-limit error. A host system SHOULD take appropriate action if it is creating packets with extension headers on behalf of the application.
An ICMPv6 Destination Unreachable with Code 8 ('Headers too long') SHOULD be sent when a node discards a packet because the aggregate length of all headers (including encapsulation headers like UDP) exceeds its processing limits.
Before using the Pointer field as an offset into the invoking packet data, a node MUST first validate that the pointer value is less than the length of the invoking packet data. This applies to both the Parameter Problem and Destination Unreachable error formats.
Code 10 ('Option too big') is sent when either the length of an individual Hop-by-Hop or Destination Option exceeds a limit, or when the length/number of consecutive padding options (PAD1 or PADN) exceeds a limit, with the Pointer set to the first octet of the offending option.
Code 5 (Unrecognized Next Header type) SHOULD be sent by an intermediate node that discards a packet due to an unknown Next Header type, with the Pointer set to the offset of the unrecognized value. This code SHOULD NOT be sent by a final destination, which SHOULD instead use RFC 8200's code 1.
Codes 6 ('Extension header too big'), 7 ('Extension header chain too long'), 8 ('Too many extension headers'), and 9 ('Too many options in extension header') SHOULD each be sent when the corresponding limit is exceeded, with the Pointer set to the first octet at or beyond the limit.
Nodes that send or receive ICMPv6 errors due to header processing limits MUST comply with ICMPv6 processing as specified in RFC 4443.
Only one ICMPv6 error SHOULD be sent per discarded packet. The RECOMMENDED priority order (highest to lowest) is: existing RFC 4443 errors, then codes 5, 6, 10 (padding), 10 (length), 9, 7, 8, and finally 'Headers too long' (Destination Unreachable code 8) with lowest precedence.
Sending of ICMP errors is RECOMMENDED even in cases where a node is discarding packets per nonconformant behavior (e.g., dropping packets to extract transport-layer info for filtering). The rationale is that providing some reason is better than a silent drop.
The invoking packet data in the aggregate header limit error MUST be zero padded to the nearest 64-bit boundary per RFC 4884. If the original invoking packet did not contain 128 octets, the invoking packet data MUST be zero padded to 128 octets.
When a source host receives an ICMPv6 error for a processing limit, it SHOULD validate the error (including matching the packet in the ICMP data to the originating connection), log it with sufficient detail, and report it to the application if the application enabled extension headers.
A new ICMPv6 Destination Unreachable code 8 ('Headers too long') is defined for aggregate header limit errors. A multi-part ICMPv6 message format (per RFC 4884) is used, with a new 'Extended Information' extension object containing a Pointer sub-type to identify the exceeding octet offset.
Six new ICMPv6 Parameter Problem codes (5–10) are defined for extension header processing limit errors: Code 5 (Unrecognized Next Header by intermediate node), Code 6 (Extension header too big), Code 7 (Extension header chain too long), Code 8 (Too many extension headers), Code 9 (Too many options in extension header), Code 10 (Option too big).
IANA has assigned Class Value 4 ('Extended Information') in the 'ICMP Extension Object Classes and Class Sub-types' registry, with a new sub-type registry (Standards Action procedure). Sub-type 0 is reserved; sub-type 1 ('Pointer') has been assigned to carry a 32-bit pointer identifying the octet offset of the limit violation.
IANA has assigned code 8 ('Headers too long') in the 'Type 1 - Destination Unreachable' registry within the ICMPv6 Parameters registry.
IANA has assigned six new codes (5–10) in the 'Type 4 - Parameter Problem' registry within the ICMPv6 Parameters registry: 5=Unrecognized Next Header type encountered by intermediate node, 6=Extension header too big, 7=Extension header chain too long, 8=Too many extension headers, 9=Too many options in extension header, 10=Option too big.
ICMPv6 errors defined in this document MAY be filtered by firewalls per RFC 4890. Implementations SHOULD allow a configurable policy to withhold sending these ICMP errors, because sending them could be exploited to covertly deduce the processing capabilities (parsing buffer sizes, header limits) of network nodes.
The general ICMPv6 security considerations of RFC 4443 are applicable. Hosts receiving these errors SHOULD validate that the packet in the ICMP data matches the upper-layer process or connection that generated the original packet before acting on the error.
The aggregate header limit ICMPv6 error uses Destination Unreachable (Type 1, Code 8) with a multi-part format: an 8-bit Length field (invoking packet length in 64-bit words), followed by the padded invoking packet, then an ICMP extension with Version=2, Class-Num=4 (Extended Information), C-Type=1 (Pointer), and a 32-bit Pointer field. Length field in extension object is 8.
The ICMPv6 Parameter Problem message for extension header limit errors uses Type=4, one of Codes 5–10, a 32-bit Checksum, and a 32-bit Pointer field identifying the octet offset within the invoking packet where the limit was exceeded. The invoking packet is included up to the minimum IPv6 MTU.