Transmission and Processing of IPv6 Extension Headers
RFC 7045

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05

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

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  . . . . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8

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
   Header").

   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 and 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
   was published.

   Today, IPv6 packets are not always forwarded by straightforward IP
   routing based on their first 40 bytes.  Some routers, and a variety
   of intermediate nodes often referred to as middleboxes, such as
   firewalls, load balancers, or packet classifiers, might inspect other
   parts of each packet.  Indeed, such middlebox functions are often
   embedded in routers.  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

Carpenter & Jiang            Standards Track                    [Page 2]