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, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [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, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 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, . 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]