| Internet-Draft | IPv6 EH Enforcement for Destinations | March 2026 |
| Iurman & Herbert | Expires 17 September 2026 | [Page] |
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. 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. 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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC2119] [RFC8174] 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 [RFC8200]. 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 [RFC8200] 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) [RFC4443] 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) [RFC8883] 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¶