Enhancement of IPv6 Extension Header
draft-li-6man-enhanced-extension-header-00

Document Type Active Internet-Draft (individual)
Last updated 2019-07-08
Stream (None)
Intended RFC status (None)
Formats plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                              Z. Li
Internet-Draft                                                   S. Peng
Intended status: Standards Track                     Huawei Technologies
Expires: January 9, 2020                                    July 8, 2019

                  Enhancement of IPv6 Extension Header
               draft-li-6man-enhanced-extension-header-00

Abstract

   As SRv6 and the new services such as SFC and IOAM are progressing,
   more and more new requirements are imposed upon the IPv6 extension
   headers, i.e.. Hop-by-hop Options Header, Destination Options Header
   and Routing Header.

   This document defines new IPv6 extension headers and corresponding
   processing procedures considering the interactions among the existing
   IPv6 extension headers, SRH and the newly introduced IPv6 extension
   headers.

Requirements Language

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

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 https://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 January 9, 2020.

Li & Peng                Expires January 9, 2020                [Page 1]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

Copyright Notice

   Copyright (c) 2019 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
   (https://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.  New Extension Headers . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Enhanced Hop-by-Hop Options Header  . . . . . . . . . . .   3
     2.2.  IPv6 Metadata Header  . . . . . . . . . . . . . . . . . .   4
   3.  Processing Procedures for Handling IPv6 Metadata Header . . .   6
     3.1.  Processing of IPv6 Metadata Header  . . . . . . . . . . .   6
     3.2.  Interactions between IPv6 Metadata Header and Existing
           IPv6 Extension Headers  . . . . . . . . . . . . . . . . .   7
       3.2.1.  Interactions between IPv6 Metadata Header and
               Authentication Header . . . . . . . . . . . . . . . .   7
       3.2.2.  Interactions between IPv6 Metadata Header and ESP
               header  . . . . . . . . . . . . . . . . . . . . . . .   9
       3.2.3.  Interactions between IPv6 Metadata Header and
               Fragment header . . . . . . . . . . . . . . . . . . .  10
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The basic IPv6 header and the initially defined IPv6 extension
   headers and options are specified in [RFC8200].  SRv6
   [I-D.ietf-spring-srv6-network-programming] introduces a new type of
   Routing Header for IPv6, i.e. SRH
   [I-D.ietf-6man-segment-routing-header].  For supporting the SRv6
   service programming SFC [I-D.xuclad-spring-sr-service-programming],
   SRH TLV is used to carry the Service Metadata [RFC8300].  For the
   SRv6 IOAM [I-D.ali-6man-spring-srv6-oam], the IOAM data fields are
   carried in a pre-allocated SRH TLV, while for the IPv6 IOAM, two
   types of extension headers in IPv6 packets - either Hop-by-Hop

Li & Peng                Expires January 9, 2020                [Page 2]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

   Options header or Destination options header are proposed to
   encapsulate the IOAM data [I-D.ioametal-ippm-6man-ioam-ipv6-options].

   As SRv6 and the new services such as SFC and iOAM are progressing,
   more and more new requirements are imposed upon the IPv6 extension
   headers.  The existing IPv6 extension headers may not be able to
   satisfy some of the new requirements.  New procedures will be
   required to specify the processing of the new and existing IPv6
   extension headers and their interactions.

   This document defines new IPv6 extension headers and corresponding
   processing procedures considering the interactions among the existing
   IPv6 extension headers, SRH and the newly introduced extension
   headers.

2.  New Extension Headers

   According to the requirements of the new services, the following IPv6
   extension headers are proposed.

2.1.  Enhanced Hop-by-Hop Options Header

   As stated in [RFC8200] together with more additional background
   information in [RFC6564], nodes may be configured to ignore the Hop-
   by-Hop Options header, and the packets containing a Hop-by-Hop
   Options header may be dropped or assigned to a slow processing path.
   In this case, the forwarding performance will be greatly reduced when
   supporting the new services such as IOAM.

   Nowadays the processing capability of the hardware chipset has been
   greatly improved and kept evolving.  Therefore, it becomes possible
   to process the packets containing the Hop-by-Hop Options header at
   wire speed, and only assign it to the slow processing path when it is
   needed.  However, currently there is still no such specification for
   defining the above-mentioned processing procedures.

   In order to take advantages of the advanced chipset capabilities and
   also guarantee the compatibility with the existing IPv6 deployments,
   a new Hop-by-Hop Options header is introduced, named Enhanced Hop-by-
   Hop Options Header.  It shares the same structure of the Hop-by-Hop
   Options header as the one defined in [RFC8200], as shown in Figure 1.
   A different Next Header value (TBD_1) for identifying the Enhanced
   Hop-by-Hop Options header is required.  The Options can be shared
   with the original Hop-by-Hop Options Header.

Li & Peng                Expires January 9, 2020                [Page 3]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  Hdr Ext Len  |  Option Type  | Opt Data Len  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          Option Data                          /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure. 1 Enhanced Hop-by-Hop Options Header

      Next Header         8-bit selector.  Identifies the type of header
                          immediately following the Hop-by-Hop Options
                          header.  Uses the same values as the IPv4
                          Protocol field [IANA-PN].

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

      Option Type         8-bit identifier of the type of option.

      Opt Data Len        8-bit unsigned integer.  Length of the Option
                          Data field of this option, in octets.

      Option Data         Variable-length field.  Option-Type-specific
                          data.

2.2.  IPv6 Metadata Header

   The IOAM metadata can be carried in IPv6 packets as Hop-by-Hop or
   Destination options [I-D.ioametal-ippm-6man-ioam-ipv6-options] or
   SRv6 SRH TLV to enhance diagnostics of IPv6/SRv6 networks.

   The SFC metadata or context information can be shared between
   Classifiers and SFs, and among SFs, which allows summarizing a
   classification result in the packet itself, avoiding subsequent re-
   classifications.  Examples of metadata include classification
   information used for policy enforcement and network context for
   forwarding after service delivery.  The SFC metadata can be carried
   in the NSH Context Header [RFC8300] or SRv6 SRH TLV,

   As described above, both SFC and IOAM need a Metadata field to record
   its metadata information.  Currently these metadata have to be
   recorded separately which may generate redundant metadata information
   or increase the cost of process.

   A unified metadata header, named IPv6 Metadata Header (MH), is
   defined to be used as a container to record the metadata of SFC, IOAM
   and other newly emerging path services in IPv6.

Li & Peng                Expires January 9, 2020                [Page 4]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

   The IPv6 Metadata Header is defined as a new type of IPv6 extension
   header shown in Figure 2, which is identified by a Next Header value
   (TBD_2).  The metadata is the information recorded by each hop for
   specific path services.  The length of the metadata is variable.

    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  |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                     Metadata Stack (Variable)                 .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 2. Metadata Header

      Next Header         8-bit selector. Identifies the type of header
                          immediately following the IPv6 metadata
                          header.

      Hdr Ext Len         8-bit unsigned integer. Length of the
                          IPv6 metadata header in octets.

      Metadata Stack      Variable-length field, of length such that the
                          complete IPv6 metadata header is an
                          integer multiple of 8 octets long. Contains
                          one or more type of path Service Metadata .

   For each specific path service, i.e. SFC/IOAM, the corresponding
   metadata is defined as shown in Figure 3.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Service Type  |     Length    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   |                     Service Metadata (variable)               |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 3. Service Metadata

Li & Peng                Expires January 9, 2020                [Page 5]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

      Service Type        8-bit identifier of the type of
                          Metadata.

      Length              8-bit unsigned integer. Length of the
                          Service Metadata field, in octets.

      Metadata            Variable-length field. Service-Type-specific data.

3.  Processing Procedures for Handling IPv6 Metadata Header

   With the introduction of the IPv6 Metadata Header, the processing of
   the IPv6 Authentication Header (AH), Encapsulating Security Payload
   header (ESP), and Fragment header (FH) need to be specified.

   The processing of the IPv6 AH when the SRH is present in the same
   packet is described in[I-D.herbert-ipv6-srh-ah].  The processing
   procedures also need to be specified when the SRH is present in the
   case of SRv6.

3.1.  Processing of IPv6 Metadata Header

   As specified in [RFC8200], when more than one extension header is
   used in the same packet, it is recommended that those headers appear
   in the following order:

                IPv6 header
                Hop-by-Hop Options header
                Destination Options header
                Routing header
   Option 1---->
                Fragment header
                Authentication header
                Encapsulating Security Payload header
                Destination Options header
   Option 2---->
                Upper-Layer header

   In the incremental tracing mode of IOAM, as the number of nodes
   traversed by the IPv6 packets increases, the recorded IOAM
   information will increase accordingly, which will increase the length
   of the Metadata field.

   If the IPv6 MH is placed before RH (SRH for SRv6), it will cause
   increasing difficulties in reading the following SRH and thereby
   reduce the forwarding performance of the data plane greatly.
   Therefore, two options in the IPv6 extension headers are recommended
   for inserting the IPv6 MH.  The different locations for inserting the

Li & Peng                Expires January 9, 2020                [Page 6]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

   IPv6 MH will also impact the processing of the AH, ESP, and FH, which
   will be discussed in the following section.

   Option 1: The IPv6 Metadata Header is inserted after the RH but
   before FH.

   Option 2: The IPv6 Metadata Header is placed as the last IPv6
   extension header, i.e. after the second Destination Options header
   but before the Upper-Layer header.

3.2.  Interactions between IPv6 Metadata Header and Existing IPv6
      Extension Headers

   When the IPv6 Metadata is presented, the processing of AH, ESP, and
   FH need to be specified.

3.2.1.  Interactions between IPv6 Metadata Header and Authentication
        Header

   AH [RFC4302] is used to authenticate the preceding IPv6 header and
   extension headers in a packet.  Authentication is performed by
   computing an Integrity Check Value (ICV) over the covered headers and
   comparing the computed value to that contained in the ICV field of
   the AH header.  Both the sender and receiver (the final destination
   in the case that a routing header is present) MUST independently and
   deterministically perform the same computation over the same data.

   When the IPv6 Metadata Header is presented, the processing of AH
   needs to be specified.  As specified in [RFC4302], AH may be employed
   in two ways: transport mode or tunnel mode.  See the Security
   Architecture document [RFC4301] for a description of when each should
   be used.

3.2.1.1.  Transport Mode Processing

   In transport mode, AH is inserted after the IP header and before a
   next layer protocol (e.g., TCP, UDP, ICMP, etc.) or before any other
   IPsec headers that have already been inserted.

   In the IPv6 context, AH is viewed as an end-to-end payload, and thus
   should appear after hop-by-hop, routing, and fragmentation extension
   headers.  The destination options extension header(s) could appear
   before or after or both before and after the AH header depending on
   the semantics desired.

   Since the IPv6 MH will be modified during transit (i.e. it is
   mutable) and its value at the (IPsec) receiver is not predictable,

Li & Peng                Expires January 9, 2020                [Page 7]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

   the value of the field is set to zero for purposes of the AH ICV
   computation according to [RFC4302].

   When the IPv6 MH is introduced, the following diagram illustrates the
   positioning of the IPv6 Metadata Header as well as the SRH in the AH
   transport mode.

   ------------------------------------------------------------
   |             |hop-by-hop, dest*, |    | dest |     |      |
   |orig IP hdr  |routing(SRH),MH,FH | AH | opt* | TCP | Data |
   ------------------------------------------------------------
   |<--- mutable field processing -->|<-- immutable fields -->|
   |<---- authenticated except for mutable fields ----------->|

         * = if present, could be before AH, after AH, or both

3.2.1.2.  Tunnel Mode Processing

   In tunnel mode, the "inner" IP header carries the ultimate (IP)
   source and destination addresses, while an "outer" IP header contains
   the addresses of the IPsec "peers," e.g., addresses of security
   gateways.  Mixed inner and outer IP versions are allowed, i.e., IPv6
   over IPv4 and IPv4 over IPv6.

   In tunnel mode, AH protects the entire inner IP packet, including the
   entire inner IP header.  The position of AH in tunnel mode, relative
   to the outer IP header, is the same as for AH in transport mode.  The
   following diagram illustrates the positioning of the IPv6 Metadata
   Header as well as the SRH in the AH tunnel mode.

   --------------------------------------------------------------
   |           | ext hdrs*|    |            | ext hdrs*|   |    |
   |new IP hdr*|(SRH, MH) | AH |orig IP hdr*|if present|TCP|Data|
   --------------------------------------------------------------
   |<--- mutable field -->|<--------- immutable fields -------->|
   |       processing     |
   |<-- authenticated except for mutable fields in new IP hdr ->|

     * = if present, construction of outer IP hdr/extensions and
         modification of inner IP hdr/extensions is discussed in
         the Security Architecture document.

Li & Peng                Expires January 9, 2020                [Page 8]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

3.2.2.  Interactions between IPv6 Metadata Header and ESP header

   When the IPv6 Metadata Header is presented, the processing of ESP
   needs to be specified.  As specified in [RFC4303], ESP may be
   employed in two ways: transport mode or tunnel mode.

3.2.2.1.  Transport Mode Processing

   In transport mode, ESP is inserted after the IP header and before a
   next layer protocol, e.g., TCP, UDP, ICMP, etc.

   In the IPv6 context, ESP is viewed as an end-to-end payload, and
   thus, as specified in [RFC4303], should appear after hop-by-hop,
   routing, and fragmentation extension headers.  Because ESP protects
   only fields after the ESP header, it recommends that the destination
   options header(s) is placed after the ESP header.

   When the IPv6 MH is introduced, with option 2 in Section 3.1, the
   IPv6 MH will be placed after the second DOH thereby encrypted, while
   with option1, it will not be encrypted.

   The following diagram illustrates the positioning of the IPv6
   Metadata Header as well as the SRH in the ESP transport mode.

                           Option 1
-----------------------------------------------------------
| orig |hop-by-hop,dest*,  |   |dest|   |    | ESP   | ESP|
|IP hdr|routing(SRH),MH,FH |ESP|opt*|TCP|Data|Trailer| ICV|
-----------------------------------------------------------
                               |<--- encryption ---->|
                           |<------ integrity ------>|

                           Option 2
---------------------------------------------------------------
| orig |hop-by-hop,dest*,|   |dest|    |    |    | ESP   | ESP|
|IP hdr|routing(SRH),FH. |ESP|opt*| MH | TCP|Data|Trailer| ICV|
---------------------------------------------------------------
                              |<------ encryption ------->|
                         |<---------- integrity -------->|

                 * = if present, could be before ESP, after ESP, or both

3.2.2.2.  Tunnel Mode Processing

   In tunnel mode, the "inner" IP header carries the ultimate (IP)
   source and destination addresses, while an "outer" IP header contains
   the addresses of the IPsec "peers", e.g., addresses of security

Li & Peng                Expires January 9, 2020                [Page 9]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

   gateways.  Mixed inner and outer IP versions are allowed, i.e., IPv6
   over IPv4 and IPv4 over IPv6.

   In tunnel mode, ESP protects the entire inner IP packet, including
   the entire inner IP header.  The position of ESP in tunnel mode,
   relative to the outer IP header, is the same as for ESP in transport
   mode.  The following diagram illustrates the positioning of the IPv6
   Metadata Header as well as the SRH in the ESP tunnel mode.

------------------------------------------------------------------------
| new* | new ext hdrs |   | orig*| orig ext hdrs |   |    | ESP   | ESP|
|IP hdr| (SRH, MH)*   |ESP|IP hdr| (SRH,MH) *    |TCP|Data|Trailer| ICV|
------------------------------------------------------------------------
                          |<------------ encryption ------------->|
                       |<--------------- integrity --------------->|

            * = if present, construction of outer IP hdr/extensions and
                modification of inner IP hdr/extensions is discussed in
                the Security Architecture document

3.2.3.  Interactions between IPv6 Metadata Header and Fragment header

   When the IPv6 Metadata is presented, the processing of FH needs to be
   specified.

   Note that in AH/ESP transport mode, for "bump-in-the-stack" or "bump-
   in- the-wire" implementations, as defined in the Security
   Architecture document, inbound and outbound IP fragments may require
   an IPsec implementation to perform extra IP reassembly/fragmentation
   in order to both conform to this specification and provide
   transparent IPsec support.  Special care is required to perform such
   operations within these implementations when multiple interfaces are
   in use.

4.  IANA Considerations

   This draft requests the following IPv6 Extension Header Type
   assignments in the Assigned Internet Protocol Numbers registry.

   https://www.iana.org/assignments/protocol-numbers/protocol-
   numbers.xhtml

   https://www.iana.org/assignments/ipv6-parameters/ipv6-
   parameters.xhtml#extension-header

Li & Peng                Expires January 9, 2020               [Page 10]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

   Protocol Number       Description                         Reference
   ---------------------------------------------------------------------
       TBD_1         Enhanced Hop-by-Hop Options header     [This draft]
       TBD_2         IPv6 Metadata Header                   [This draft]

5.  Security Considerations

   As this document describes new extension headers for IPv6, these are
   similar to the security considerations of [RFC8200].

   This document describes the encapsulation of IOAM and SFC metadata
   fields in IPv6.  Security considerations of the specific IOAM and SFC
   metadata fields are described in [I-D.ietf-ippm-ioam-data] and
   [RFC8300], respectively.

6.  Normative References

   [I-D.ali-6man-spring-srv6-oam]
              Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., Gandhi,
              R., Brockners, F., Leddy, J., Matsushima, S., Raszuk, R.,
              daniel.voyer@bell.ca, d., Dawra, G., Peirens, B., Chen,
              M., Li, C., and F. Iqbal, "Operations, Administration, and
              Maintenance (OAM) in Segment Routing Networks with IPv6
              Data plane (SRv6)", draft-ali-6man-spring-srv6-oam-01
              (work in progress), March 2019.

   [I-D.herbert-ipv6-srh-ah]
              Herbert, T., "IPv6 Authentication Header with Segment
              Routing Header Processing", draft-herbert-ipv6-srh-ah-00
              (work in progress), May 2019.

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
              Routing Header (SRH)", draft-ietf-6man-segment-routing-
              header-21 (work in progress), June 2019.

   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
              P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
              "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
              data-06 (work in progress), July 2019.

Li & Peng                Expires January 9, 2020               [Page 11]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J.,
              daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
              Network Programming", draft-ietf-spring-srv6-network-
              programming-01 (work in progress), July 2019.

   [I-D.ioametal-ippm-6man-ioam-ipv6-options]
              Bhandari, S., Brockners, F., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B.,
              Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati,
              "In-situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam-
              ipv6-options-02 (work in progress), March 2019.

   [I-D.xuclad-spring-sr-service-programming]
              Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
              d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
              Henderickx, W., and S. Salsano, "Service Programming with
              Segment Routing", draft-xuclad-spring-sr-service-
              programming-02 (work in progress), April 2019.

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              DOI 10.17487/RFC4302, December 2005,
              <https://www.rfc-editor.org/info/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [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,
              <https://www.rfc-editor.org/info/rfc6564>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

Li & Peng                Expires January 9, 2020               [Page 12]
Internet-Draft      IPv6 Extension Header Enhancement          July 2019

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com

   Shuping Peng
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: pengshuping@huawei.com

Li & Peng                Expires January 9, 2020               [Page 13]