Transmission and Processing of IPv6 Extension Headers
updates
Extracted elements (20)
A 'Catch-22' situation exists for deploying new extension headers: they cannot be widely deployed because middleboxes will drop them, but middleboxes will not be updated until the header is proved safe and useful, which is impossible until middleboxes are updated. This document addresses the problem by clarifying forwarding requirements and establishing a registry.
Extension headers are numbered from the existing IP Protocol Number space, meaning there is no collected list of them. An implementor consulting only RFC 2460 will miss all extension headers defined subsequently. The new 'IPv6 Extension Header Types' registry is created specifically to address this discoverability problem.
The Hop-by-Hop Options header requirement is updated to reflect operational reality: high-performance routers often ignore it or process it on a slow path. Designers planning to use hop-by-hop options need to be aware that processing is not guaranteed at intermediate nodes.
Because IPv6 extension headers do not all follow a uniform TLV format, middleboxes that need to traverse the header chain require knowledge of each extension header's format. The header chain may also be fragmented, making stateless processing of the full chain unreliable.
IPv6 Routing Header Types 0 and 1 have been deprecated (Type 0 by RFC 5095). However, this does not mean the IPv6 Routing Header can be unconditionally dropped by forwarding nodes; only deprecated types are affected.
Any forwarding node that forwards an IPv6 packet for any reason SHOULD do so regardless of any extension headers present, as required by RFC 2460. This applies to all types of forwarding nodes including routers, firewalls, load balancers, and other middleboxes.
Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but the default configuration MAY drop such packets.
Forwarding nodes operating as firewalls MUST conform to the requirements in Section 2 in order to respect the IPv6 extension header architecture. Packets containing standard extension headers are only to be discarded as a result of an intentionally configured policy.
If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. The discard policy for each standard extension header type MUST be individually configurable.
If a forwarding node is designed to examine extension headers for any reason, it MUST recognise and deal appropriately with all standard IPv6 extension header types, and SHOULD recognise and deal appropriately with experimental IPv6 extension header types. Implementors are advised to check the IANA list regularly for updates.
Intermediate forwarding nodes SHOULD NOT discard packets containing unrecognised extension headers, since doing so might inadvertently block traffic using a recently standardised extension header not yet recognised by the intermediate node.
Packets containing standardised and undeprecated Routing Headers SHOULD be forwarded by default. At the time of writing, these include Type 2 (RFC 6275), Type 3 (RFC 6554), and the experimental Routing Header Types 253 and 254 (RFC 4727).
The default configuration of a forwarding node SHOULD allow all standard extension headers. Experimental IPv6 extension headers SHOULD be treated in the same way as standard extension headers, but the default configuration MAY drop experimental extension headers.
The Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in RFC 2460. However, high-performance routers may either ignore it or assign packets containing it to a slow processing path, and designers must be aware of this likely behaviour.
An IPv6 extension header is any header that follows the initial 40 bytes of the packet and precedes the upper-layer header (which might be a transport header, an ICMPv6 header, or a notional 'No Next Header'). The Hop-by-Hop Options header, if present, must be first.
IANA added an 'IPv6 Extension Header' column to the 'Assigned Internet Protocol Numbers' registry to mark values that are also IPv6 extension header types defined by an IETF Standards Action or IESG Approval. This also applies to future extension header types.
IANA closed the existing empty 'Next Header Types' registry and created a new 'IPv6 Extension Header Types' registry containing protocol numbers also marked as extension header types. Initial entries include: 0 (Hop-by-Hop Option), 43 (Routing), 44 (Fragment), 50 (ESP), 51 (AH), 60 (Destination Options), 135 (Mobility), 139 (HIP, experimental), 140 (Shim6), 253 and 254 (experimental).
Header types 253 and 254 may be used for either experimental extension headers or experimental payload types, and there is no generic algorithm by which a firewall can distinguish these two cases. This ambiguity should be considered when deciding the appropriate default action for those header types.
The default configuration allowing standard extension headers avoids connectivity failures while still permitting firewalls to be configured to filter unwanted or suspect extension headers. Firewalls must be capable of permitting any or all extension headers if configured to do so.
When new extension headers are standardised, they will exercise new code paths in hosts that recognise them, so caution may be required during deployment. The deployment process is expected to be slow and dependent on satisfactory operational experience, and new extensions will fail in some parts of the Internet until deployment is complete.