| Network Working Group | Z. Li |
| Internet-Draft | S. Peng |
| Intended status: Standards Track | Huawei Technologies |
| Expires: July 23, 2020 | C. Xie |
| China Telecom | |
| K. LEE | |
| LG U+ | |
| January 20, 2020 |
Enhancement of IPv6 Extension Header
draft-li-6man-enhanced-extension-header-01
As SRv6 and the new services such as 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.
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.
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 July 23, 2020.
Copyright (c) 2020 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.
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 the SRv6 IOAM [I-D.ali-spring-ioam-srv6], 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 Options header or Destination options header are proposed to encapsulate the IOAM data [I-D.ietf-ippm-ioam-ipv6-options].
As SRv6 and the new services such as 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.
According to the requirements of the new services, the following IPv6 extension headers are proposed.
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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
As path services, both IOAM and SFC need a Metadata field to record its metadata information.
The IOAM metadata can be carried in IPv6 packets as Hop-by-Hop or Destination options [I-D.ietf-ippm-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.
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 IOAM, SFC and other newly emerging path services in IPv6.
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. IOAM/SFC, 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
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.
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.
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 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.
When the IPv6 Metadata is presented, the processing of AH, ESP, and FH need to be specified.
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.
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, 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
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.
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.
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
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, 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
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.
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
Protocol Number Description Reference
---------------------------------------------------------------------
TBD_1 Enhanced Hop-by-Hop Options header [This draft]
TBD_2 IPv6 Metadata Header [This draft]
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.
| [I-D.ali-spring-ioam-srv6] | Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Kumar, N., Pignataro, C., Li, C., Chen, M. and G. Dawra, "Segment Routing Header encapsulation for In-situ OAM Data", Internet-Draft draft-ali-spring-ioam-srv6-02, November 2019. |
| [I-D.herbert-ipv6-srh-ah] | Herbert, T., "IPv6 Authentication Header with Segment Routing Header Processing", Internet-Draft draft-herbert-ipv6-srh-ah-00, May 2019. |
| [I-D.ietf-6man-segment-routing-header] | Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S. and D. Voyer, "IPv6 Segment Routing Header (SRH)", Internet-Draft draft-ietf-6man-segment-routing-header-26, October 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., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, d. and J. Lemon, "Data Fields for In-situ OAM", Internet-Draft draft-ietf-ippm-ioam-data-08, October 2019. |
| [I-D.ietf-ippm-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", Internet-Draft draft-ietf-ippm-ioam-ipv6-options-00, September 2019. |
| [I-D.ietf-spring-srv6-network-programming] | Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S. and Z. Li, "SRv6 Network Programming", Internet-Draft draft-ietf-spring-srv6-network-programming-08, January 2020. |
| [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. |
| [RFC8300] | Quinn, P., Elzur, U. and C. Pignataro, "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018. |