Enforcement of IPv6 Extension Headers Ordering and Occurrence at Destination Nodes

Operational experience has demonstrated that permitting multiple occurrences of the same IPv6 Extension Header can create parsing ambiguity, complicate packet processing, and increase potential security risks. This is particularly true for the Hop-by-Hop Options header and the Destination Options header, which may each carry multiple options. Although RFC 8200 recommends that senders follow a specific order of appearance and limit the occurrences of Extension Headers, receivers cannot assume that these recommendations have been followed. As a result, they may be exposed to denial-of-service attacks, where Extension Headers are used as the attack vector. This document specifies behavior that allows an IPv6 destination node, namely a host (i.e., the final destination of an IPv6 packet) or an intermediate destination node addressed by an entry in a Routing header list other than the final one, to enforce strict ordering and limits on the occurrence of Extension Headers. The specification applies only to IPv6 destination nodes and does not impose requirements on routers forwarding IPv6 packets not explicitly addressed to themselves.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

An IPv6 destination, i.e., a host or an intermediate destination node, MAY enforce the recommended ordering and limits on the occurrence of Extension Headers described in Section 4.1 of . Per the ordering recommendations, each Extension Header can occur at most once in a packet, with the exception of the Destination Options header which can occur twice. The recommended Extension Headers ordering per is: IPv6 header Hop-by-Hop Options header Destination Options header Routing header Fragment header Authentication header Encapsulating Security Payload header Destination Options header Upper-Layer header If a host or an intermediate destination node enforces the recommended ordering and a packet is received with out-of-order Extension Headers, or the occurrence of an Extension Header is greater than one (or two for the Destination Options header), then the receiving node MUST discard the packet. In the case of a host, it MAY send an ICMP Parameter Problem message with code 1 (Unrecognized Next Header type encountered) to the packet's source address. In the case of an intermediate destination node, it MAY send an ICMP Parameter Problem message with code 5 (Unrecognized Next Header type encountered by intermediate node) to the packet's source address.

Enforcing strict ordering and occurrence limits may cause packets whose Extension Headers do not follow the recommended order or appear more than suggested to be discarded. While such packets are not formally non-compliant with RFC 8200, they are unexpected and may lead to parsing ambiguities or interoperability issues. Operators should consider the potential impact on traffic when enabling enforcement at destination nodes, particularly at intermediate destination nodes.

This document mitigates a potential denial-of-service attack based on abusive use of Extension Headers in IPv6 packets. Hosts and intermediate destination nodes are now allowed to enforce strict ordering and limits on the occurrence of Extension Headers to reduce the attack vector. This document does not introduce any new security concerns.

This document does not require any action from IANA.

TBD