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
Abstract
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.
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 July 23, 2020.
Li, et al. Expires July 23, 2020 [Page 1]
Internet-Draft IPv6 Extension Header Enhancement January 2020
Copyright Notice
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.
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 . . . . . . . . . . . . . . . . . . . . . 11
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 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].
Li, et al. Expires July 23, 2020 [Page 2]
Internet-Draft IPv6 Extension Header Enhancement January 2020
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.
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, et al. Expires July 23, 2020 [Page 3]
Internet-Draft IPv6 Extension Header Enhancement January 2020
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
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.
Li, et al. Expires July 23, 2020 [Page 4]
Internet-Draft IPv6 Extension Header Enhancement January 2020
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.
Li, et al. Expires July 23, 2020 [Page 5]
Internet-Draft IPv6 Extension Header Enhancement January 2020
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.
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:
Li, et al. Expires July 23, 2020 [Page 6]
Internet-Draft IPv6 Extension Header Enhancement January 2020
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.
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.
Li, et al. Expires July 23, 2020 [Page 7]
Internet-Draft IPv6 Extension Header Enhancement January 2020
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,
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
Li, et al. Expires July 23, 2020 [Page 8]
Internet-Draft IPv6 Extension Header Enhancement January 2020
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.
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.
Li, et al. Expires July 23, 2020 [Page 9]
Internet-Draft IPv6 Extension Header Enhancement January 2020
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
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.
Li, et al. Expires July 23, 2020 [Page 10]
Internet-Draft IPv6 Extension Header Enhancement January 2020
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
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-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", draft-ali-spring-ioam-srv6-02 (work in progress),
November 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.
Li, et al. Expires July 23, 2020 [Page 11]
Internet-Draft IPv6 Extension Header Enhancement January 2020
[]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-26 (work in
progress), 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", draft-
ietf-ippm-ioam-data-08 (work in progress), 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", draft-ietf-ippm-ioam-
ipv6-options-00 (work in progress), 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",
draft-ietf-spring-srv6-network-programming-08 (work in
progress), 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,
<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>.
Li, et al. Expires July 23, 2020 [Page 12]
Internet-Draft IPv6 Extension Header Enhancement January 2020
[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>.
[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
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing
China
Email: xiechf.bri@huawei.com
Kihoon LEE
LG U+
71, Magokjungang 8-ro, Gangseo-gu
Seoul
Korea
Email: soho8416@guplus.co.kr
Li, et al. Expires July 23, 2020 [Page 13]