Internet DRAFT - draft-gont-6man-ipv6-universal-extension-header

draft-gont-6man-ipv6-universal-extension-header







IPv6 maintenance Working Group (6man)                            F. Gont
Internet-Draft                                    SI6 Networks / UTN-FRH
Obsoletes: 6564 (if approved)                                     W. Liu
Intended status: Standards Track                     Huawei Technologies
Expires: March 19, 2016                                      S. Krishnan
                                                                Ericsson
                                                              H. Pfeifer
                                                         Rohde & Schwarz
                                                      September 16, 2015


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

Abstract

   In IPv6, optional internet-layer information is encoded in separate
   headers that may be placed between the IPv6 header and the transport-
   layer header.  There are a small number of such extension headers
   currently defined.  This document describes the issues that can arise
   when defining new extension headers and specifies a new IPv6
   Extension Header - the Universal Extension Header - that overcomes
   the aforementioned problem, while enabling the extensibility of IPv6.
   Finally, this document formally obsoletes 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 March 19, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Gont, et al.             Expires March 19, 2016                 [Page 1]

Internet-Draft         Universal Extension Header         September 2015


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  A Problem with RFC 6564 . . . . . . . . . . . . . . . . . . .   3
   4.  Implications  . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  UEH Specification . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Forbidding New IPv6 Extension Headers . . . . . . . . . . . .   5
   7.  Operation of the UEH  . . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     12.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   There has recently been a lot of work in the area of IPv6 Extension
   Headers.  Firstly, there has been research about the extent to which
   IPv6 packets employing Extension Headers are dropped in the public
   Internet [GONT-IEPG-Nov13] [GONT-IEPG-Mar14], and debate about the
   motivation behind such policy [I-D.gont-v6ops-ipv6-ehs-packet-drops].
   Secondly, there has been a fair share of work to improve some
   technicalities of IPv6 Extension Headers (see e.g.  [RFC7112]
   [RFC7045]) in the hopes that they can be reliably used in the public
   Internet.

   A key challenge for IPv6 Extension Headers to be "deployable" in the
   public Internet is that they should not impair any nodes's ability to
   process the entire IPv6 header chain.  One of the steps meant in that
   direction has been the specification of a Uniform Format for IPv6
   Extension Headers [RFC6564], which was 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 new
   new extension headers were specified.  However, a problem in the



Gont, et al.             Expires March 19, 2016                 [Page 2]

Internet-Draft         Universal Extension Header         September 2015


   aforementioned specification prevents such uniform format from being
   of use.

   Section 3 discusses the aforementioned flaw in the Uniform Format for
   Extension Headers specified in [RFC6564].  Section 4 explicitly
   describes the implications of the aforementioned flaw.  Section 5
   specifies the new Universal Extension Header (UEH).  Section 7
   explains how new IPv6 extensions would be specified with the UEH.
   Section 6 formally forbids the specification of new IPv6 Extension
   Headers (with new Next Header values), and mandates that any new IPv6
   extensions be conveyed/encoded in the UEH specified in this document.

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.  A Problem with RFC 6564

   A key problem with the Uniform Format for IPv6 Extension Headers
   [RFC6564] lies in that both IPv6 Extension Headers and Transport
   Protocols share the same "Next Header" registry/namespace.  Thus,
   given an "unknown Next Header value", it is impossible to tell
   whether the aforementioned value refers to an IPv6 Extension Header
   that employs the aforementioned uniform format, or an "unknown"
   upper-layer protocol (e.g. an "unknown" transport protocol).  That
   is, while [RFC6564] specifies the syntax for a Uniform Format for
   IPv6 Extension Headers, it does not provide a mechanism for a node to
   identify whether the aforementioned format is being employed in the
   first place.

4.  Implications

   The current impossibility to parse an IPv6 header chain that includes
   unknown Next Header values results in concrete implications for the
   extensibility of the IPv6 protocol, and the deployability of new
   transport protocols.  Namely,

   o  New IPv6 extension headers cannot be incrementally deployed.

   o  New transport protocols cannot be incrementally deployed.

   Since there is no way for a node to process IPv6 extension headers
   that employ unknown next header values, an IPv6 host that receives a
   packet that employs a new IPv6 extension header will not be able to
   parse the IPv6 header chain past that unknown extension header, and
   hence it will drop the aforementioned packet



Gont, et al.             Expires March 19, 2016                 [Page 3]

Internet-Draft         Universal Extension Header         September 2015


   [I-D.gont-v6ops-ipv6-ehs-packet-drops].  In a similar way, a
   middlebox that needs to process the transport-protocol header will be
   faced with the dilemma of what to do with packets that employ unknown
   Next Header values.  Since they will not be able to parse the IPv6
   header chain past the unknown Next Header, it is very likely that
   they will drop such packets.

   Unfortunately, since transport protocols share the same namespace as
   IPv6 Extension Headers, new transport protocols will pose the same
   challenge to middle-boxes, and hence they will be likely dropped in
   the network.

   We believe that the current situation has implications that are
   generally overlooked, and that, whatever the outcome, it should be
   the result of an explicit decision by our community, rather than
   simply "omission".

5.  UEH Specification

   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:

       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.




Gont, et al.             Expires March 19, 2016                 [Page 4]

Internet-Draft         Universal Extension Header         September 2015


   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.

6.  Forbidding New IPv6 Extension Headers

   Since the specification of any new IPv6 Extension Headers (i.e., with
   new Next Header values) would hamper (among other things) the
   incremental deployment of extensions and new transport protocols, and
   basic operational practices suchas as the enforcement of simple ACLs,
   new IPv6 Extension Headers MUST NOT be specified in any future
   specifications.  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 need to parse the entire IPv6 header chain.

7.  Operation of the UEH

   This section describes the operation of the Universal Extension
   Header.

   The goal of the UEH is to provide 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 the "common syntax" required to process "unrecognized
   extensions", and the Subtype field identifies the specific extension
   being encoded in the UEH.  Any "future extension headers" would
   actually be new Subtypes (assigned by IANA) of the UEH.

   As a result, unrecognized Next Header values should be interpreted to
   identify an upper-layer protocol, rather than an IPv6 extension
   header.

8.  IANA Considerations

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






Gont, et al.             Expires March 19, 2016                 [Page 5]

Internet-Draft         Universal Extension Header         September 2015


9.  Security Considerations

   Enabling nodes to parse an entire IPv6 header chain even in the
   presence of unrecognized extensions allows for security mechanisms to
   be implemented and deployed.

10.  Acknowledgements

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

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

12.  References

12.1.  Normative References

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6564]  Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
              M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
              RFC 6564, DOI 10.17487/RFC6564, April 2012,
              <http://www.rfc-editor.org/info/rfc6564>.

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045,
              DOI 10.17487/RFC7045, December 2013,
              <http://www.rfc-editor.org/info/rfc7045>.

12.2.  Informative References

   [RFC7112]  Gont, F., Manral, V., and R. Bonica, "Implications of
              Oversized IPv6 Header Chains", RFC 7112,
              DOI 10.17487/RFC7112, January 2014,
              <http://www.rfc-editor.org/info/rfc7112>.





Gont, et al.             Expires March 19, 2016                 [Page 6]

Internet-Draft         Universal Extension Header         September 2015


   [I-D.gont-v6ops-ipv6-ehs-packet-drops]
              Gont, F., Hilliard, N., Doering, G., LIU, S., and W.
              Kumari, "Operational Implications of IPv6 Packets with
              Extension Headers", draft-gont-v6ops-ipv6-ehs-packet-
              drops-00 (work in progress), July 2015.

   [GONT-IEPG-Nov13]
              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>.

   [GONT-IEPG-Mar14]
              Gont, F. and T. Chown, "More results from measurements of
              IPv6 Extension Header probing",  IEPG 89, March 2, 2014.
              London, U.K., 2014, <http://www.iepg.org/2014-03-02-
              ietf89/fgont-iepg-ietf89-eh-update.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, et al.             Expires March 19, 2016                 [Page 7]

Internet-Draft         Universal Extension Header         September 2015


   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com


   Hagen Paul Pfeifer
   Rohde & Schwarz
   Muehldorfstrasse 15
   Munich  81671
   Germany

   Phone: +49 89 4129 15515
   Email: hagen.pfeifer@rohde-schwarz.com
   URI:   http://www.rohde-schwarz.com/
































Gont, et al.             Expires March 19, 2016                 [Page 8]