IPv6 Hop-by-Hop Options Processing Procedures
updates
- rfc-8200 — Internet Protocol, Version 6 (IPv6) Specification
Extracted elements (26)
High-speed routers cannot process Hop-by-Hop options at Full Forwarding Rate, so they are sent to the Slow Path or Control Plane, creating DoS vulnerability and packet reordering within flows. These problems motivate relaxing the mandatory processing requirement.
New Hop-by-Hop options should set action bits to '00' so that routers that do not recognize the option can skip it rather than discard the packet, enabling incremental deployability where early adopters gain benefit even when some paths do not support the option.
RFC 8200's text allowing routers to skip Hop-by-Hop processing was not intended to change processing semantics but documented existing Internet behavior as a constraint on standardization. This document now formalizes practical procedures that make Hop-by-Hop options deployable.
The 'racing' technique—sending a test packet with required Hop-by-Hop options first, then waiting for acknowledgment before sending data packets with the option—enables path discovery for option support without requiring all routers to implement the option.
The Router Alert Option is kept as the single Control Plane exception rather than deprecated because it could support future functions requiring Control Plane processing, representing a reasonable compromise for future flexibility while applying strict protections per RFC 6398.
Measurements from 2015 (RFC 7872) and 2023 confirm that IPv6 packets containing Hop-by-Hop Options headers are dropped by many Internet paths and transit ASes. Packets with Extension Headers totaling less than 40 bytes have higher probability of successful transmission.
Routers configured to drop packets with Hop-by-Hop Options headers (per RFC 9288) to protect downstream devices are an explicit exception to the SHOULD-process rule, maintaining backward compatibility with networks that filter Extension Headers.
The Hop-by-Hop Options header is intended to be processed by all destinations including hosts, but constrained hosts are an acceptable exception; any destination that does not process the header MUST still process the remainder of the packet normally.
A node configured to process a Router Alert Option MUST protect itself from an infrastructure attack that could result from processing in the Control Plane, using some combination of access control lists, rate limiting, or other methods per RFC 6398.
A router MUST NOT drop a packet solely because it contains an Extension Header carrying Hop-by-Hop options. Even if a router does not process the Hop-by-Hop Options header, it MUST forward the packet normally based on the remaining Extension Header(s).
A router SHOULD NOT be configured to process the first Hop-by-Hop option if doing so adversely impacts the aggregate forwarding rate. A router SHOULD process additional Hop-by-Hop options, if configured, providing they also do not adversely impact the aggregate forwarding rate.
A Source creating packets with a Hop-by-Hop Options header SHOULD use a method that is robust to network nodes selectively processing only some options. Sources are motivated to order Hop-by-Hop options in decreasing order of importance for path processing.
An implementation that recognizes the Router Alert Option SHOULD verify that the option contains a protocol configured as of interest before sending the packet to the Control Plane; otherwise, the router SHOULD forward the packet subject to normal policies.
Hosts SHOULD process the Hop-by-Hop Options header in received packets. If a destination does not process the Hop-by-Hop Options header, it MUST process the remainder of the packet normally.
If a router is unable to process a specific Hop-by-Hop option, it SHOULD behave as specified for an unrecognized Option Type with action bits set to '00' and SHOULD skip remaining options using the 'Hdr Ext Len' field.
Routers that process the Hop-by-Hop Options header SHOULD do so using the method defined in this document. Exceptions include routers configured to drop such packets to protect downstream devices that do not comply with this specification.
The set of Hop-by-Hop options enabled for processing SHOULD be configurable by the operator of the router.
A lookup table approach is suggested for router implementation: maintain a table of Option Types processable at Full Forwarding Rate, enabling quick determination of whether an option is supported and allowing operator configuration of actions.
Option Type identifiers encode their highest-order 2 bits as action bits: '00' = skip and continue; '01' = discard; '10' = discard and MAY send ICMPv6 Parameter Problem Code 2 (multicast or not); '11' = discard and MAY send ICMPv6 Parameter Problem Code 2 (unicast only).
The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 header, must appear immediately after the IPv6 header, and may appear at most once in a packet. It can contain one or more Hop-by-Hop options.
The Router Alert Option (RFC 2711) includes a two-octet Value field identifying the carried protocol; its Option Type top bits are always '00', meaning nodes that do not recognize it skip over it and continue header processing.
This document modifies the behavior for action bits '01', '10', and '11': a router that cannot or is not configured to process the option MAY discard the packet rather than MUST, and for '10'/'11' the ICMPv6 Parameter Problem message is MAY rather than mandatory.
IANA added RFC 9673 as an additional reference for the 'Destination Options and Hop-by-Hop Options' registry in the 'Internet Protocol Version 6 (IPv6) Parameters' registry group, updating the processing procedures reference for that registry.
Any mechanism that forces packets into the router's Control Plane or Slow Path—including the Router Alert Option—can be exploited as a DoS attack by saturating router management resources (routing protocols, network management), potentially causing router failure.
Malformed or malicious Hop-by-Hop options (e.g., excessive number of options, oversized Extension Headers) can exhaust router resources or prevent hardware optimizations for later header processing such as ECMP or port filtering. Implementations must fail gracefully.
Nodes providing DoS mitigation, firewalls, or traffic normalization may be configured to drop packets when they cannot access all Extension Headers or locate higher-layer information; this document provides guidance on minimum Hop-by-Hop processing requirements for such nodes.