Implications of Oversized IPv6 Header Chains
updates
- rfc-2460 — Internet Protocol, Version 6 (IPv6) Specification
Extracted elements (18)
Stateless firewalls must glean information from both IPv6 and upper-layer headers to enforce forwarding policy. If the header chain spans multiple fragments, the First Fragment alone is insufficient for policy enforcement, causing the firewall to either forward or drop the packet without correctly applying its policy. Requiring the entire header chain in the First Fragment resolves this ambiguity.
Unlike IPv4, which had a fixed maximum length for all IPv4 options in a single packet, IPv6 originally imposed no equivalent limit on the combined size of Extension Headers and options. This document closes that gap by requiring all headers to fit within the First Fragment, implicitly bounding header chain length to at most the Path MTU (or 1280 bytes when Path MTU is unknown).
The requirement to include the entire IPv6 Header Chain in the First Fragment does not preclude the use of large payloads; only the headers (IPv6 base header through Upper-Layer Header) must fit in the First Fragment. The payload data may still be fragmented across subsequent fragments.
A host that receives a First Fragment that does not contain the entire IPv6 Header Chain SHOULD discard the packet and SHOULD send an ICMPv6 error message to the source address of the offending packet, subject to RFC 4443 rules for ICMPv6 errors.
An intermediate system (e.g., router or firewall) that receives a non-compliant IPv6 First Fragment MAY discard that packet and MAY send an ICMPv6 error message to the source. Intermediate systems with this capability SHOULD support configuration of whether such packets are dropped.
For backwards compatibility, implementations MAY include a configuration option that allows non-compliant First Fragments (those lacking the entire IPv6 Header Chain) to be accepted rather than discarded.
Hosts that do not discover the Path MTU MUST limit the IPv6 Header Chain length to 1280 bytes, ensuring the header chain does not exceed the IPv6 minimum MTU defined in RFC 2460.
When a host fragments an IPv6 datagram, it MUST include the entire IPv6 Header Chain in the First Fragment. This ensures that all headers from the IPv6 base header through the Upper-Layer Header are present in the fragment with Fragment Offset equal to 0.
When discarding a non-compliant First Fragment and sending an ICMPv6 error, the error message MUST be Type 4 ("Parameter Problem") with Code 3 ("First Fragment has incomplete IPv6 Header Chain"). The Pointer field MUST be set to zero.
A First Fragment is defined as an IPv6 fragment with Fragment Offset equal to 0. This definition is used to determine which fragment must contain the entire IPv6 Header Chain.
Extension Headers are defined in Section 4 of RFC 2460. As a result of RFC 7045, the IANA Protocol Numbers registry designates which protocol numbers also represent Extension Headers, providing an authoritative list.
The IPv6 Header Chain contains an initial IPv6 header, zero or more IPv6 Extension Headers, and optionally a single Upper-Layer Header. It is terminated by the Upper-Layer Header or by the 'No Next Header' value (Next Header = 59). A second IPv6 header or an ESP header encountered in the chain is treated as an Upper-Layer Header and terminates the chain.
The Upper-Layer Header is the first member of the header chain that is neither an IPv6 header nor an IPv6 Extension Header. An ESP header or a second IPv6 header (e.g., in IPv6-over-IPv6 tunneling) are also treated as Upper-Layer Headers, terminating the chain. The upper-layer payload is not part of the IPv6 Header Chain.
IANA added Code 3 ('IPv6 First Fragment has incomplete IPv6 Header Chain') to the Type 4 - Parameter Problem entry in the 'Internet Control Message Protocol version 6 (ICMPv6) Parameters' registry.
A firewall that performs stateless deep packet inspection (examining application payload content) may still be unable to correctly process fragmented packets even when the IPv6 Header Chain is fully contained in the First Fragment, because the payload may still be split across fragments.
Fragmented packets whose header chain spans multiple fragments can be used to evade stateless packet filtering, because the First Fragment alone does not carry enough information for the firewall to enforce its forwarding policy. This document forbids such packets to close this security vulnerability.
ICMPv6 error messages generated in response to non-compliant First Fragments can be leveraged in reflection attacks if the attacker forges the source IPv6 address of the offending packet. Deploying Source Address Forgery Prevention filters (per RFC 2827 and RFC 3704) mitigates this risk.
The ICMPv6 error message for a non-compliant First Fragment uses Type 4 ("Parameter Problem"), Code 3 ("First Fragment has incomplete IPv6 Header Chain"), with the Pointer field set to zero. This format is the same whether originated by a host or an intermediate system.