Enhancement of IPv6
Extension HeaderHuawei TechnologiesHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comHuawei TechnologiesHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinapengshuping@huawei.comChina TelecomBeiqijia Town, Changping DistrictBeijingChinaxiechf.bri@huawei.comLG U+71, Magokjungang 8-ro, Gangseo-guSeoulKoreasoho8416@guplus.co.krAs 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.The basic IPv6 header and the initially defined IPv6 extension
headers and options are specified in . SRv6
introduces a
new type of Routing Header for IPv6, i.e. SRH . For the SRv6 IOAM
, 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
.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 together with more additional
background information in , 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 , 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.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 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.For each specific path service, i.e. IOAM/SFC, the corresponding
metadata is defined as shown in Figure 3.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.
The processing procedures also need to be specified when the SRH is
present in the case of SRv6.As specified in , when more than one
extension header is used in the same packet, it is recommended that
those headers appear in the following order: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 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 , AH
may be employed in two ways: transport mode or tunnel mode. See the
Security Architecture document 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 .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.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.When the IPv6 Metadata Header is presented, the processing of ESP
needs to be specified. As specified in , 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 , 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.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.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.xhtmlhttps://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-headerAs 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 and ,
respectively.