Skip to main content

IPv6 Universal Extension Header
draft-gont-6man-ipv6-universal-extension-header-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Fernando Gont , Will (Shucheng) LIU
Last updated 2014-01-30
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-gont-6man-ipv6-universal-extension-header-00
IPv6 maintenance Working Group (6man)                            F. Gont
Internet-Draft                                    SI6 Networks / UTN-FRH
Updates: 6564 (if approved)                                       W. Liu
Intended status: Standards Track                     Huawei Technologies
Expires: August 4, 2014                                 January 31, 2014

                    IPv6 Universal Extension Header
           draft-gont-6man-ipv6-universal-extension-header-00

Abstract

   This document analyzes a problem in the Uniform Format for IPv6
   Extension Headers specified in RFC 6564, which results in forwarding
   nodes and middle-boxes not being able to process an IPv6 Header Chain
   if it contains an unrecognized IPv6 Extension Header that follows the
   aforementioned Uniform Format.  Additionally, it specifies a new IPv6
   Extension Header - the Universal Extension Header - that overcomes
   the aforementioned problem, and enables the extensibility of IPv6
   without impairing middleboxes that need to process the entire IPv6
   Header Chain.  Finally, this document formally updates RFC 6564

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 http://datatracker.ietf.org/drafts/current/.

   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 August 4, 2014.

Copyright Notice

   Copyright (c) 2014 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

Gont & Liu               Expires August 4, 2014                 [Page 1]
Internet-Draft         Universal Extension Header           January 2014

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Updating RFC 6564 . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Operation of the Universal Extension Header . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   5
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   5
     10.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   There has recently been a lot of work about IPv6 Extension Headers.
   Firstly, there has been research about the extent to which IPv6
   Extension Headers are dropped in the public Internet [GONT-IEPG], and
   debate about the motivation behind such policy
   [I-D.taylor-v6ops-fragdrop].  Secondly, there has been a fair share
   of work to improve some technicalities of IPv6 Extension Headers
   [I-D.ietf-6man-oversized-header-chain] [RFC7045], in the hopes that
   they can be reliably used in the public Internet.

   A key challenge for IPv6 Extension Headers to be "usable" in the
   public Internet is that they should not impair any middle-box's
   ability to inspect the upper layer header (e.g., TCP source and
   destination ports, etc.).  One of the steps in that direction has
   been the specification of a Uniform Format for IPv6 Extension Headers
   [RFC6564], which is meant to be employed by any IPv6 Extension
   Headers that might be defined in the future, such that middle-boxes
   can still process the entire IPv6 header chain if the new extension
   headers employ the Uniform Format.

   Section 3 discusses a flaw in the Uniform Format for Extension
   Headers specified in [RFC6564].  Section 4 formally updates
   [RFC6564], specifying the new Universal Extension Header (UEH).
   Section 5 explains how new IPv6 would be developed with the UEH.

Gont & Liu               Expires August 4, 2014                 [Page 2]
Internet-Draft         Universal Extension Header           January 2014

2.  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 RFC 2119 [RFC2119].

3.  Problem Statement

   A key problem with the Uniform Format for IPv6 Extension Headers lies
   on the fat that both IPv6 Extension Headers and Transport Protocols
   share the same namespace ("Next Header" registry/namespace).  Thus,
   there is now way to distinguish between an unrecognized IPv6
   Extension Header and an unrecognized transport protocol.  For
   example, if a node were to receive an IPv6 packet that employs an
   unsupported "Next Header" value, there is no way to tell whether the
   next header corresponds to an Extension Header employing the Uniform
   Format for IPv6 Extension Headers, or a new upper-layer protocol
   (such as a transport protocol).

   Clearly, employing the Uniform Format for IPv6 Extension Headers
   "enables" the future extension of IPv6 and the processing of entire
   IPv6 header chains containing unrecognized extension headers, at the
   expense of preventing the deployment of new transport protocols or
   other upper layer protocols.

4.  Updating RFC 6564

   The entire Section 4 of [RFC6564] is hereby replaced as follows:

   New IPv6 Extension Headers MUST NOT be specified.  Any IPv6
   extensions that would require a new IPv6 Extension Header MUST be
   implemented with the Universal Extension Header specified in this
   document.  This minimizes breakage in intermediate nodes that examine
   these extension headers.

   This document specifies a new IPv6 Extension Header: Universal
   Extension Header.  This Extension Header is identified by the value
   [TBD] of [IANA-IP-PROTO].  The syntax of the Universal Extension
   Header is:

Gont & Liu               Expires August 4, 2014                 [Page 3]
Internet-Draft         Universal Extension Header           January 2014

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |  Hdr Ext Len  |    Subtype    |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
      |                                                               |
      .                                                               .
      .                   Subtype Specific Data                        .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   Next Header
      8-bit selector.  Identifies the type of header immediately
      following the extension header.  Uses the same values as the IPv4
      Protocol field [IANA-IP-PROTO].

   Hdr Ext Len
      8-bit unsigned integer.  Length of the extension header in 8-octet
      units, not including the first 8 octets.

   Subtype
      8-bit unsigned integer.  Specifies the subtype for this extension
      header.  It uses a new namespace managed by IANA [IANA-UEH].

   Subtype Specific Data
      Variable length.  Fields specific to this extension header/
      Subtype.

   The Universal Extension Header specified in this document MAY appear
   multiple times in the same IPv6 packet.

5.  Operation of the Universal Extension Header

   This section discusses de operation of the Universal Extension
   Header.

   The goal of the UEH is to provide for a common syntax for all future
   IPv6 extensions.  Any future extension headers will be encoded in a
   UEH, and will be identified by a specific UEH Subtype assigned by
   IANA at the time the corresponding specification is published.  The
   UEH thus provides for the "common syntax" required to process
   "unrecognized extensions", and the Subtype field identifies the
   specific extension being encoded in the UEH.  Any "future extension

Gont & Liu               Expires August 4, 2014                 [Page 4]
Internet-Draft         Universal Extension Header           January 2014

   headers" would actually be new Subtypes (assigned by IANA) of the
   UEH.

   As a result, in the event an unrecognized Next Header value is
   encountered by a node, the node will be able to assume that such Next
   Header value identifies an upper-layer protocol, rather than an
   extension header.

6.  IANA Considerations

   IANA is requested to create a new registry to maintain the Universal
   Extension Header Subtypes [IANA-UEH].

7.  Security Considerations

   Enabling middle-boxes such as firewalls to inspect the entire IPv6
   header chain even in the presence of unrecognized extensions allows
   for security mechanisms to be implemented, and for proper functioning
   of of other middle-boxes such as load-balancers.

8.  Acknowledgements

   The authors would like to thank [TBD] for providing valuable input on
   earlier versions of this document.

9.  Contributors

   C.M. Heard identified the problems related with the Uniform Format
   for IPv6 Extension Headers specified in [RFC6564], and participated
   in the brainstorming that led to this document.

10.  References

10.1.  Normative References

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

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

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

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045, December 2013.

Gont & Liu               Expires August 4, 2014                 [Page 5]
Internet-Draft         Universal Extension Header           January 2014

10.2.  Informative References

   [I-D.ietf-6man-oversized-header-chain]
              Gont, F., Manral, V., and R. Bonica, "Implications of
              Oversized IPv6 Header Chains", draft-ietf-6man-oversized-
              header-chain-09 (work in progress), November 2013.

   [I-D.taylor-v6ops-fragdrop]
              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-02 (work in
              progress), December 2013.

   [GONT-IEPG]
              Gont, F., "Fragmentation and Extension Header Support in
              the IPv6 Internet", IEPG 88, November 3, 2013. Vancouver,
              BC, Canada, 2013, <http://www.iepg.org/2013-11-ietf88/
              fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>.

   [IANA-IP-PROTO]
              Internet Assigned Numbers Authority, "Assigned Internet
              Protocol Numbers", April 2011, <http://www.iana.org/
              assignments/protocol-numbers/protocol-numbers.xhtml>.

   [IANA-UEH]
              Internet Assigned Numbers Authority, "Universal Extension
              Header Subtypes", 2014.

Authors' Addresses

   Fernando Gont
   SI6 Networks / UTN-FRH
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com

   Will (Shucheng) Liu
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: liushucheng@huawei.com

Gont & Liu               Expires August 4, 2014                 [Page 6]