Skip to main content

Transmission and Processing of IPv6 Extension Headers

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7045.
Author Sheng Jiang
Last updated 2013-10-10 (Latest revision 2013-09-25)
Replaces draft-carpenter-6man-ext-transmit
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Bob Hinden
Shepherd write-up Show Last changed 2013-08-28
IESG IESG state Became RFC 7045 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Brian Haberman
Send notices to,,
IANA IANA review state IANA OK - Actions Needed
6man                                                        B. Carpenter
Internet-Draft                                         Univ. of Auckland
Updates: 2460, 2780 (if approved)                               S. Jiang
Intended status: Standards Track            Huawei Technologies Co., Ltd
Expires: March 30, 2014                               September 26, 2013

         Transmission and Processing of IPv6 Extension Headers


   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 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 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

   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 March 30, 2014.

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
   ( 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

Carpenter & Jiang        Expires March 30, 2014                 [Page 1]
Internet-Draft     IPv6 Extension Header Transmission     September 2013

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction and Problem Statement  . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Requirement to Transmit Extension Headers . . . . . . . . . .   5
     2.1.  All Extension Headers . . . . . . . . . . . . . . . . . .   5
     2.2.  Hop-by-Hop Options  . . . . . . . . . . . . . . . . . . .   6
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Change log [RFC Editor: Please remove]  . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction and Problem Statement

   In IPv6, an 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

   An initial set of IPv6 extension headers was defined by [RFC2460],
   which also described how they should be handled by intermediate
   nodes, with the exception of the hop-by-hop options header:

   "...extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header."

   This provision meant that forwarding nodes should be completely
   transparent to extension headers.  There was no provision for
   forwarding nodes to modify them, remove them, insert them, or use
   them to affect forwarding behaviour.  Thus, new extension headers
   could be introduced progressively, used only by hosts that have been
   updated to create and interpret them [RFC6564].  The extension header
   mechanism is an important part of the IPv6 architecture, and several
   new extension headers have been standardised since RFC 2460.

   Today, packets are often forwarded not only by straightforward IP
   routers, but also by a variety of intermediate nodes, often referred
   to as middleboxes, such as firewalls, load balancers, or packet

Carpenter & Jiang        Expires March 30, 2014                 [Page 2]
Internet-Draft     IPv6 Extension Header Transmission     September 2013

   classifiers.  However, experience has shown that as a result, the
   network is not transparent to IPv6 extension headers.  Contrary to
   Section 4 of RFC 2460, middleboxes sometimes examine and process 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

   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 RFC
   2460.  It has also been observed that certain firewalls do not even
   handle all the extension headers standardised in RFC 2460, including
   the fragment header [I-D.taylor-v6ops-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 middlebox, 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

Carpenter & Jiang        Expires March 30, 2014                 [Page 3]
Internet-Draft     IPv6 Extension Header Transmission     September 2013

   Internet, which is impossible until the middleboxes have been

   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
   [I-D.ietf-6man-oversized-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 IANA to 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",
   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.  "Experimental"
   extension headers are those defined by any Experimental RFC, and the
   experimental extension header values 253 and 254 defined by [RFC3692]
   and [RFC4727].  "Defined" extension headers are the "standard"
   extension headers plus the "experimental" ones.

Carpenter & Jiang        Expires March 30, 2014                 [Page 4]
Internet-Draft     IPv6 Extension Header Transmission     September 2013

2.  Requirement to Transmit Extension Headers

2.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 can parse all defined extension
   headers and deal with them appropriately, as specified in this

   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 [RFC5095].
   However, this does not mean that the IPv6 Routing Header can be
   unconditionally dropped by forwarding nodes.  Packets containing

Carpenter & Jiang        Expires March 30, 2014                 [Page 5]
Internet-Draft     IPv6 Extension Header Transmission     September 2013

   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 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 Section 1 and Section 2.1.

   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
   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

Carpenter & Jiang        Expires March 30, 2014                 [Page 6]
Internet-Draft     IPv6 Extension Header Transmission     September 2013

4.  IANA Considerations

   IANA is requested to clearly mark in the Assigned Internet Protocol
   Numbers registry those values which are also IPv6 Extension Header
   types defined by an IETF Standards Action or IESG Approval (see list
   below), for example by adding an extra column title "IPv6 Extension
   Header" to indicate this.  This will also apply to any IPv6 Extension
   Header types defined in the future.

   Additionally, IANA is requested to make the existing empty IPv6 Next
   Header Types registry redirect users to a new IPv6 Extension Header
   Types registry.  It will contain only those protocol numbers which
   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, Hop-by-Hop Options, [RFC2460]

   o  43, Routing, [RFC2460], [RFC5095]

   o  44, Fragment, [RFC2460]

   o  50, Encapsulating Security Payload, [RFC4303]

   o  51, Authentication, [RFC4302]

   o  60, Destination Options, [RFC2460]

   o  135, MIPv6, [RFC6275]

   o  139, experimental use, HIP, [RFC5201]

   o  140, shim6, [RFC5533]

   o  253, experimental use, [RFC3692], [RFC4727]

   o  254, experimental use, [RFC3692], [RFC4727]

   This list excludes type 59, No Next Header, [RFC2460], which is not
   an extension header as such.

   The references to the IPv6 Next Header field in [RFC2780] are to be
   interpreted as also applying to the IPv6 Extension Header field and
   the IPv6 Extension Header Types registry will be managed accordingly.

5.  Acknowledgements

Carpenter & Jiang        Expires March 30, 2014                 [Page 7]
Internet-Draft     IPv6 Extension Header Transmission     September 2013

   This document was triggered by mailing list discussions including
   John Leslie, Stefan Marksteiner and others.  Valuable comments and
   contributions were made by Dominique Barthel, Tim Chown, Lorenzo
   Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh
   Krishnan, Marc Lampo, Sandra Murphy, Michael Richardson, Dan
   Romascanu, Dave Thaler, Joe Touch, Bjoern Zeeb, and others.

   Brian Carpenter was a visitor at the Computer Laboratory, Cambridge
   University during part of this work.

   This document was produced using the xml2rfc tool [RFC2629].

6.  Change log [RFC Editor: Please remove]

   draft-ietf-6man-ext-transmit-04: updates following IETF Last Call,
   normative requirements clarified, IANA considerations clarified,
   security consuderations expanded, 2013-09-26.

   draft-ietf-6man-ext-transmit-03: added details for experimental
   values, various clarifications and minor corrections, 2013-08-22.

   draft-ietf-6man-ext-transmit-02: explicit mention of header types 253
   and 254, editorial fixes, 2013-08-06.

   draft-ietf-6man-ext-transmit-01: tuned use of normative language,
   clarified that only standardised extensions are covered (hence
   excluding HIP), 2013-05-29.

   draft-ietf-6man-ext-transmit-00: first WG version, more
   clarifications, 2013-03-26.

   draft-carpenter-6man-ext-transmit-02: clarifications following WG
   comments, recalibrated firewall requirements, 2013-02-22.

   draft-carpenter-6man-ext-transmit-01: feedback at IETF85: clarify
   scope and impact on firewalls, discuss line-speed processing and lack
   of uniform TLV format, added references, restructured IANA
   considerations, 2012-11-13.

   draft-carpenter-6man-ext-transmit-00: original version, 2012-08-14.

7.  References

Carpenter & Jiang        Expires March 30, 2014                 [Page 8]
Internet-Draft     IPv6 Extension Header Transmission     September 2013

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
              Values In the Internet Protocol and Related Headers", BCP
              37, RFC 2780, March 2000.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, January 2004.

   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.

   [RFC6564]  Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
              M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
              RFC 6564, April 2012.

7.2.  Informative References

   [Heller]   Heller, J., "Catch-22", Simon and Schuster , 1961.

              Gont, F., Manral, V., and R. Bonica, "Implications of
              Oversized IPv6 Header Chains", draft-ietf-6man-oversized-
              header-chain-07 (work in progress), September 2013.

              Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
              M., and T. Taylor, "Why Operators Filter Fragments and
              What It Implies", draft-taylor-v6ops-fragdrop-01 (work in
              progress), June 2013.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

Carpenter & Jiang        Expires March 30, 2014                 [Page 9]
Internet-Draft     IPv6 Extension Header Transmission     September 2013

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095, December

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, April 2008.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, June 2009.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with the Routing Protocol
              for Low-Power and Lossy Networks (RPL)", RFC 6554, March

Authors' Addresses

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland  1142
   New Zealand


   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus
   No.156 Beiqing Road
   Hai-Dian District, Beijing  100095
   P.R. China


Carpenter & Jiang        Expires March 30, 2014                [Page 10]