Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 7045 Univ. of Auckland
Updates: 2460, 2780 S. Jiang
Category: Standards Track Huawei Technologies Co., Ltd.
ISSN: 2070-1721 December 2013
Transmission and Processing of IPv6 Extension Headers
Abstract
Various IPv6 extension headers have been standardised since the IPv6
standard was first published. This document updates RFC 2460 to
clarify how intermediate nodes should deal with such extension
headers and with any that are defined in the future. It also
specifies how extension headers should be registered by IANA, with a
corresponding minor update to RFC 2780.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7045.
Copyright Notice
Copyright (c) 2013 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Carpenter & Jiang Standards Track [Page 1]

RFC 7045 IPv6 Extension Header Transmission December 2013
the entire IPv6 packet before making a decision to either forward or
discard the packet. This means that they need to traverse the chain
of extension headers, if present, until they find the transport
header (or an encrypted payload). Unfortunately, because not all
IPv6 extension headers follow a uniform TLV format, this process is
clumsy and requires knowledge of each extension header's format. A
separate problem is that the header chain may even be fragmented
[HEADER-CHAIN].
The process is potentially slow as well as clumsy, possibly
precluding its use in nodes attempting to process packets at line
speed. The present document does not intend to solve this problem,
which is caused by the fundamental architecture of IPv6 extension
headers. This document focuses on clarifying how the header chain
should be handled in the current IPv6 architecture.
If they encounter an unrecognised extension header type, some
firewalls treat the packet as suspect and drop it. Unfortunately, it
is an established fact that several widely used firewalls do not
recognise some or all of the extension headers standardised since RFC2460 was published. It has also been observed that certain firewalls
do not even handle all the extension headers standardised in RFC2460, including the fragment header [FRAGDROP], causing fundamental
problems of end-to-end connectivity. This applies in particular to
firewalls that attempt to inspect packets at very high speed, since
they cannot take the time to reassemble fragmented packets,
especially when under a denial-of-service attack.
Other types of middleboxes, such as load balancers or packet
classifiers, might also fail in the presence of extension headers
that they do not recognise.
A contributory factor to this problem is that because extension
headers are numbered out of the existing IP Protocol Number space,
there is no collected list of them. For this reason, it is hard for
an implementor to quickly identify the full set of standard extension
headers. An implementor who consults only RFC 2460 will miss all
extension headers defined subsequently.
This combination of circumstances creates a "Catch-22" situation
[Heller] for the deployment of any newly standardised extension
header except for local use. It cannot be widely deployed because
existing middleboxes will drop it on many paths through the Internet.
However, most middleboxes will not be updated to allow the new header
to pass until it has been proved safe and useful on the open
Internet, which is impossible until the middleboxes have been
updated.
Carpenter & Jiang Standards Track [Page 3]

RFC 7045 IPv6 Extension Header Transmission December 2013
The uniform TLV format now defined for extension headers [RFC6564]
will improve the situation, but only for future extensions. Some
tricky and potentially malicious cases will be avoided by forbidding
very long chains of extension headers that need to be fragmented
[HEADER-CHAIN]. This will alleviate concerns that stateless
firewalls cannot locate a complete header chain as required by the
present document.
However, these changes are insufficient to correct the underlying
problem. The present document clarifies that the above requirement
from RFC 2460 applies to all types of nodes that forward IPv6 packets
and to all extension headers standardised now and in the future. It
also requests that IANA create a subsidiary registry that clearly
identifies extension header types and updates RFC 2780 accordingly.
Fundamental changes to the IPv6 extension header architecture are out
of scope for this document.
Also, hop-by-hop options are not handled by many high-speed routers
or are processed only on a slow path. This document also updates the
requirements for processing the Hop-by-Hop Options header to make
them more realistic.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In the remainder of this document, the term "forwarding node" refers
to any router, firewall, load balancer, prefix translator, or any
other device or middlebox that forwards IPv6 packets with or without
examining the packet in any way.
In this document, "standard" IPv6 extension headers are those
specified in detail by IETF Standards Actions [RFC5226].
"Experimental" extension headers include those defined by any
Experimental RFC and the header values 253 and 254 defined by
[RFC3692] and [RFC4727] when used as experimental extension headers.
"Defined" extension headers are the "standard" extension headers plus
the "experimental" ones.
Carpenter & Jiang Standards Track [Page 4]

RFC 7045 IPv6 Extension Header Transmission December 20132. Requirement to Transmit Extension Headers2.1. All Extension Headers
As mentioned above, forwarding nodes that discard packets containing
extension headers are known to cause connectivity failures and
deployment problems. Therefore, it is important that forwarding
nodes that inspect IPv6 headers be able to parse all defined
extension headers and deal with them appropriately, as specified in
this section.
Any forwarding node along an IPv6 packet's path, which forwards the
packet for any reason, SHOULD do so regardless of any extension
headers that are present, as required by RFC 2460. Exceptionally, if
a forwarding node is designed to examine extension headers for any
reason, such as firewalling, 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.
The list of standard and experimental extension header types is
maintained by IANA (see Section 4), and implementors are advised to
check this list regularly for updates.
RFC 2460 requires destination hosts to discard packets containing
unrecognised extension headers. However, intermediate forwarding
nodes SHOULD NOT do this, since that might cause them to
inadvertently discard traffic using a recently standardised extension
header not yet recognised by the intermediate node. The exceptions
to this rule are discussed next.
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. This
means that the discard policy for each standard type of extension
header MUST be individually configurable. The default configuration
SHOULD allow all standard extension headers.
Experimental IPv6 extension headers SHOULD be treated in the same way
as standard extension headers, including an individually configurable
discard policy. However, the default configuration MAY drop
experimental extension headers.
Forwarding nodes MUST be configurable to allow packets containing
unrecognised extension headers, but the default configuration MAY
drop such packets.
The IPv6 Routing Header Types 0 and 1 have been deprecated. Note
that Type 0 was deprecated by [RFC5095]. However, this does not mean
that the IPv6 Routing Header can be unconditionally dropped by
Carpenter & Jiang Standards Track [Page 5]

RFC 7045 IPv6 Extension Header Transmission December 2013
forwarding nodes. Packets containing standardised and undeprecated
Routing Headers SHOULD be forwarded by default. At the time of
writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the
experimental Routing Header Types 253 and 254 [RFC4727]. Others may
be defined in the future.
2.2. Hop-by-Hop Options
The IPv6 Hop-by-Hop Options header SHOULD be processed by
intermediate forwarding nodes as described in [RFC2460]. However, it
is to be expected that high-performance routers will either ignore it
or assign packets containing it to a slow processing path. Designers
planning to use a hop-by-hop option need to be aware of this likely
behaviour.
As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options
header, if present, must be first.
3. Security Considerations
Forwarding nodes that operate as firewalls MUST conform to the
requirements in the previous section in order to respect the IPv6
extension header architecture. In particular, packets containing
standard extension headers are only to be discarded as a result of an
intentionally configured policy.
These changes do not affect a firewall's ability to filter out
traffic containing unwanted or suspect extension headers, if
configured to do so. However, the changes do require firewalls to be
capable of permitting any or all extension headers, if configured to
do so. The default configurations are intended to allow normal use
of any standard extension header, avoiding the connectivity issues
described in Sections 1 and 2.1.
As noted above, the default configuration might drop packets
containing experimental extension headers. There is no header length
field in an IPv6 header, and header types 253 and 254 might be used
either for experimental extension headers or for experimental payload
types. Therefore, there is no generic algorithm by which a firewall
can distinguish these two cases and analyze the remainder of the
packet. This should be considered when deciding on the appropriate
default action for header types 253 and 254.
When new extension headers are standardised in the future, those
implementing and configuring forwarding nodes, including firewalls,
will need to take them into account. A newly defined header will
exercise new code paths in a host that does recognise it, so caution
may be required. Additional security issues with experimental values
Carpenter & Jiang Standards Track [Page 6]

RFC 7045 IPv6 Extension Header Transmission December 2013
or new extension headers are to be found in [RFC4727] and [RFC6564].
As a result, it is to be expected that the deployment process will be
slow and will depend on satisfactory operational experience. Until
deployment is complete, the new extension will fail in some parts of
the Internet. This aspect needs to be considered when deciding to
standardise a new extension. Specific security considerations for
each new extension should be documented in the document that defines
it.
4. IANA Considerations
IANA has added an extra column titled "IPv6 Extension Header" to the
"Assigned Internet Protocol Numbers" registry to clearly mark those
values that are also IPv6 extension header types defined by an IETF
Standards Action or IESG Approval (see list below). This also
applies to IPv6 extension header types defined in the future.
Additionally, IANA has closed the existing empty "Next Header Types"
registry to new entries and is redirecting its users to a new "IPv6
Extension Header Types" registry. This registry contains only those
protocol numbers that are also marked as IPv6 Extension Header types
in the "Assigned Internet Protocol Numbers" registry. Experimental
values will be marked as such. The initial list will be as follows:
o 0, IPv6 Hop-by-Hop Option, [RFC2460]
o 43, Routing Header for IPv6, [RFC2460], [RFC5095]
o 44, Fragment Header for IPv6, [RFC2460]
o 50, Encapsulating Security Payload, [RFC4303]
o 51, Authentication Header, [RFC4302]
o 60, Destination Options for IPv6, [RFC2460]
o 135, Mobility Header, [RFC6275]
o 139, Experimental use, Host Identity Protocol [RFC5201]
o 140, Shim6 Protocol, [RFC5533]
o 253, Use for experimentation and testing, [RFC3692], [RFC4727]
o 254, Use for experimentation and testing, [RFC3692], [RFC4727]
This list excludes type 59, No Next Header, [RFC2460], which is not
an extension header as such.
Carpenter & Jiang Standards Track [Page 7]