draft-ietf-6man-segment-routing-header-17.txt   draft-ietf-6man-segment-routing-header-18.txt 
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Previdi Intended status: Standards Track S. Previdi
Expires: September 26, 2019 Huawei Expires: October 7, 2019 Huawei
J. Leddy J. Leddy
Individual Individual
S. Matsushima S. Matsushima
Softbank Softbank
D. Voyer, Ed. D. Voyer, Ed.
Bell Canada Bell Canada
March 25, 2019 April 5, 2019
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-17 draft-ietf-6man-segment-routing-header-18
Abstract Abstract
Segment Routing can be applied to the IPv6 data plane using a new Segment Routing can be applied to the IPv6 data plane using a new
type of Routing Extension Header. This document describes the type of Routing Extension Header. This document describes the
Segment Routing Extension Header and how it is used by Segment Segment Routing Extension Header and how it is used by Segment
Routing capable nodes. Routing capable nodes.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 26, 2019. This Internet-Draft will expire on October 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Segment Routing Extension Header . . . . . . . . . . . . . . 4 2. Segment Routing Extension Header . . . . . . . . . . . . . . 4
2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 7
2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8
3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11
3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11
3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 11 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 12
4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 13
4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 13
4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 13 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 13
4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 15 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 15
4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 16 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 16
4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 16 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 16
5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 16 5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 16
5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 16 5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 16
5.2. SR Domain as a single system with delegation among 5.2. SR Domain as a single system with delegation among
components . . . . . . . . . . . . . . . . . . . . . . . 17 components . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 17 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 18
5.4. AH ICV . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. ICMP Error Processing . . . . . . . . . . . . . . . . . . 18
5.5. ESP ICV . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.5. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 18
5.6. ICMP Error Processing . . . . . . . . . . . . . . . . . . 18 5.6. Other Deployments . . . . . . . . . . . . . . . . . . . . 19
5.7. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 18
5.8. Other Deployments . . . . . . . . . . . . . . . . . . . . 19
6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Abstract Representation of an SRH . . . . . . . . . . . . 19 6.1. Abstract Representation of an SRH . . . . . . . . . . . . 19
6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 20 6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 20
6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 21 6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 20
6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 21 6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 21
6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 21 6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 21
6.3.3. Inter SR Domain Packet - Internal to External . . . . 22 6.3.3. Inter SR Domain Packet - Internal to External . . . . 21
6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 22 6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 22
6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 22 6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 22
6.6. Delegation of Function with HMAC Verification . . . . . . 22 6.6. Delegation of Function with HMAC Verification . . . . . . 22
6.6.1. SID List Verification . . . . . . . . . . . . . . . . 22 6.6.1. SID List Verification . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 24 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 23
7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 24 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 24
7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 25 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 24
7.5. AH ICV computation . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8.1. Segment Routing Header Flags Register . . . . . . . . . . 26 8.1. Segment Routing Header Flags Register . . . . . . . . . . 26
8.2. Segment Routing Header TLVs Register . . . . . . . . . . 26 8.2. Segment Routing Header TLVs Register . . . . . . . . . . 26
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 26
9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 26 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 26
9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 27 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 27
9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 4, line 5 skipping to change at page 3, line 43
The Segment Routing Architecture [RFC8402] describes Segment Routing The Segment Routing Architecture [RFC8402] describes Segment Routing
and its instantiation in two data planes MPLS and IPv6. and its instantiation in two data planes MPLS and IPv6.
The encoding of IPv6 segments in the Segment Routing Extension Header The encoding of IPv6 segments in the Segment Routing Extension Header
is defined in this document. is defined in this document.
Terminology used within this document is defined in detail in Terminology used within this document is defined in detail in
[RFC8402]. Specifically, these terms: Segment Routing, SR Domain, [RFC8402]. Specifically, these terms: Segment Routing, SR Domain,
SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy. SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Segment Routing Extension Header 2. Segment Routing Extension Header
Routing Headers are defined in [RFC8200]. The Segment Routing Header Routing Headers are defined in [RFC8200]. The Segment Routing Header
has a new Routing Type (suggested value 4) to be assigned by IANA. has a new Routing Type (suggested value 4) to be assigned by IANA.
The Segment Routing Header (SRH) is defined as follows: The Segment Routing Header (SRH) is defined as follows:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 5 skipping to change at page 5, line 5
o Hdr Ext Len: Defined in [RFC8200] o Hdr Ext Len: Defined in [RFC8200]
o Routing Type: TBD, to be assigned by IANA (suggested value: 4). o Routing Type: TBD, to be assigned by IANA (suggested value: 4).
o Segments Left: Defined in [RFC8200] o Segments Left: Defined in [RFC8200]
o Last Entry: contains the index (zero based), in the Segment List, o Last Entry: contains the index (zero based), in the Segment List,
of the last element of the Segment List. of the last element of the Segment List.
o Flags: 8 bits of flags. Following flags are defined: o Flags: 8 bits of flags. Section 8.1 creates an IANA registry for
new flags to be deinfed. The following flags are defined:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|U U U U U U U U| |U U U U U U U U|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
U: Unused and for future use. MUST be 0 on transmission and U: Unused and for future use. MUST be 0 on transmission and
ignored on receipt. ignored on receipt.
o Tag: tag a packet as part of a class or group of packets, e.g., o Tag: tag a packet as part of a class or group of packets, e.g.,
packets sharing the same set of properties. When tag is not used packets sharing the same set of properties. When tag is not used
at source it MUST be set to zero on transmission. When tag is not at source it MUST be set to zero on transmission. When tag is not
used during SRH Processing it SHOULD be ignored. The allocation used during SRH Processing it SHOULD be ignored. Tag is not used
and use of tag is outside the scope of this document. when processing the SID defined in Section 4.3.1. It may be used
when processing other SID types which are not defined in this
document. The allocation and use of tag is outside the scope of
this document.
o Segment List[n]: 128 bit IPv6 addresses representing the nth o Segment List[n]: 128 bit IPv6 addresses representing the nth
segment in the Segment List. The Segment List is encoded starting segment in the Segment List. The Segment List is encoded starting
from the last segment of the SR Policy. I.e., the first element from the last segment of the SR Policy. I.e., the first element
of the segment list (Segment List [0]) contains the last segment of the segment list (Segment List [0]) contains the last segment
of the SR Policy, the second element contains the penultimate of the SR Policy, the second element contains the penultimate
segment of the SR Policy and so on. segment of the SR Policy and so on.
o Type Length Value (TLV) are described in Section 2.1. o Type Length Value (TLV) are described in Section 2.1.
2.1. SRH TLVs 2.1. SRH TLVs
This section defines TLVs of the Segment Routing Header. This section defines TLVs of the Segment Routing Header.
A TLV provides meta-data for segment processing. The only TLVs
defined in this document are the HMAC (Section 2.1.2) and PAD
(Section 2.1.1) TLVs. While processing the SID defined in
Section 4.3.1, all TLVs are ignored unless local configuration
indicates otherwise (Section 4.3.1.1.1). Thus, TLV and HMAC support
is optional for any implementation. Other documents may define
additional TLVs and processing rules for them.
TLVs are present when the Hdr Ext Len exceeds the Last Entry element TLVs are present when the Hdr Ext Len exceeds the Last Entry element
in the Segment List. in the Segment List.
While processing TLVs at a segment endpoint, TLVs MUST be fully While processing TLVs at a segment endpoint, TLVs MUST be fully
contained within the SRH as determined by the Hdr Ext Len. Detection contained within the SRH as determined by the Hdr Ext Len. Detection
of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an
ICMP Parameter Problem, Code 0, message to the Source Address, ICMP Parameter Problem, Code 0, message to the Source Address,
pointing to the Hdr Ext Len field of the SRH, and the packet being pointing to the Hdr Ext Len field of the SRH, and the packet being
discarded. discarded.
An implementation MAY limit the number and/or length of TLVs it
processes based on local configuration. It MAY:
o Limit the number of consecutive Pad0 (Section 2.1.1.1) options to
1, if padding of more than one byte is required then PadN
(Section 2.1.1.2) should be used.
o Limit the length in PadN to 5.
o Limit the maximum number of non-Pad TLVs to be processed.
o Limit the maximum length of all TLVs to be processed.
The implementation MAY stop processing additional TLVs in the SRH
when these configured limits are exceeded.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
| Type | Length | Variable length data | Type | Length | Variable length data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
Type: An 8 bit value. Unrecognized Types MUST be ignored on receipt. Type: An 8 bit value. Unrecognized Types MUST be ignored on receipt.
Length: The length of the Variable length data. It is RECOMMENDED Length: The length of the Variable length data.
that the total length of new TLVs be multiple of 8 bytes to avoid the
use of Padding TLVs.
Variable length data: Length bytes of data that is specific to the Variable length data: Length bytes of data that is specific to the
Type. Type.
Type Length Value (TLV) contain OPTIONAL information that may be used Type Length Value (TLV) contain OPTIONAL information that may be used
by the node identified in the Destination Address (DA) of the packet. by the node identified in the Destination Address (DA) of the packet.
Each TLV has its own length, format and semantic. The code-point Each TLV has its own length, format and semantic. The code-point
allocated (by IANA) to each TLV Type defines both the format and the allocated (by IANA) to each TLV Type defines both the format and the
semantic of the information carried in the TLV. Multiple TLVs may be semantic of the information carried in the TLV. Multiple TLVs may be
encoded in the same SRH. encoded in the same SRH.
TLVs may change en route at each segment. To identify when a TLV All TLVs specify their alignment requirements using an xn+y format.
type may change en route the most significant bit of the Type has the The xn+y format is defined as per [RFC8200]. The SR Source nodes use
following significance: the xn+y alignment requirements of TLVs and padding TLVs when
constructing an SRH.
0: TLV data does not change en route
1: TLV data does change en route
Identifying which TLVs change en route, without having to understand
the Type, is required for Authentication Header Integrity Check Value
(ICV) computation. Any TLV that changes en route is considered
mutable for the purpose of ICV computation, the Type Length and
Variable Length Data is ignored for the purpose of ICV Computation as
defined in [RFC4302].
The "Length" field of the TLV is used to skip the TLV while The "Length" field of the TLV is used to skip the TLV while
inspecting the SRH in case the node doesn't support or recognize the inspecting the SRH in case the node doesn't support or recognize the
Type. The "Length" defines the TLV length in octets, not including Type. The "Length" defines the TLV length in octets, not including
the "Type" and "Length" fields. the "Type" and "Length" fields.
The following TLVs are defined in this document: The following TLVs are defined in this document:
Padding TLV Padding TLVs
HMAC TLV HMAC TLV
Additional TLVs may be defined in the future. Additional TLVs may be defined in the future.
2.1.1. Padding TLVs 2.1.1. Padding TLVs
There are two types of padding TLVs, pad0 and padN, the following There are two types of padding TLVs, pad0 and padN, the following
applies to both: applies to both:
Padding TLVs are used to pad the TLVs to a multiple of 8 octets. Padding TLVs are used to pad the SRH to a multiple of 8 octets.
When present, a single Pad0 or PadN TLV MUST appear as the last Padding TLVs are used for alignment.
TLV. More than one Padding TLV MUST NOT appear in the SRH. The
Padding TLVs are used to align the SRH total length on the 8 octet
boundary.
Padding TLVs are ignored by a node processing the SRH TLV, even if Padding TLVs are ignored by a node processing the SRH TLV.
more than one is present.
Padding TLVs are ignored during ICV calculation. Multiple Padding TLVs MAY be used in one SRH
2.1.1.1. PAD0 2.1.1.1. PAD0
Alignment requirement: none
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type | | Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: to be assigned by IANA (Suggested value 128) Type: to be assigned by IANA (Suggested value 128)
A single Pad0 TLV MUST be used when a single byte of padding is A single Pad0 TLV MUST be used when a single byte of padding is
required. If more than one byte of padding is required a Pad0 TLV required. If more than one byte of padding is required a Pad0 TLV
MUST NOT be used, the PadN TLV MUST be used. MUST NOT be used, the PadN TLV MUST be used.
2.1.1.2. PADN 2.1.1.2. PADN
Alignment requirement: none
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Padding (variable) | | Type | Length | Padding (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Padding (variable) // // Padding (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: to be assigned by IANA (suggested value 129). Type: to be assigned by IANA (suggested value 129).
skipping to change at page 8, line 7 skipping to change at page 8, line 25
Padding: Length octets of padding. Padding bits have no Padding: Length octets of padding. Padding bits have no
semantics. They MUST be set to 0 on transmission and ignored on semantics. They MUST be set to 0 on transmission and ignored on
receipt. receipt.
The PadN TLV MUST be used when more than one byte of padding is The PadN TLV MUST be used when more than one byte of padding is
required. required.
2.1.2. HMAC TLV 2.1.2. HMAC TLV
Alignment requirement: 8n
The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL
and has the following format: and has the following format:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED | | Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Key ID (4 octets) | | HMAC Key ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 43 skipping to change at page 9, line 17
HMAC is not included. HMAC is not included.
o HMAC: 32 octets of keyed HMAC, not present if Key ID is 0. o HMAC: 32 octets of keyed HMAC, not present if Key ID is 0.
The HMAC TLV is used to verify the source of a packet is permitted to The HMAC TLV is used to verify the source of a packet is permitted to
use the current segment in the destination address of the packet, and use the current segment in the destination address of the packet, and
ensure the segment list is not modified in transit. ensure the segment list is not modified in transit.
2.1.2.1. HMAC Generation and Verification 2.1.2.1. HMAC Generation and Verification
Local policy determines when to check for an HMAC and potentially Local configuration determines when to check for an HMAC and
provides an alternate composition of Text, and a requirement on where potentially provides an alternate composition of Text, and a
the HMAC TLV must appear (e.g. first TLV), and whether or not to requirement on where the HMAC TLV must appear (e.g. first TLV), and
verify the destination address is equal to the current segment. This whether or not to verify the destination address is equal to the
local policy is outside the scope of this document. It may be based current segment. This local configuration is outside the scope of
on the active segment at an SR Segment endpoint node, the result of this document. It may be based on the active segment at an SR
an ACL that considers incoming interface, HMAC Key ID, or other Segment endpoint node, the result of an ACL that considers incoming
packet fields. interface, HMAC Key ID, or other packet fields.
An implementation that supports the generation and verification of An implementation that supports the generation and verification of
the HMAC SHOULD support the following default behavior as defined in the HMAC SHOULD support the following default behavior as defined in
the remainder of this section. the remainder of this section.
The HMAC verification begins by checking the current segment is equal The HMAC verification begins by checking the current segment is equal
to the destination address of the IPv6 header, i.e. destination to the destination address of the IPv6 header, i.e. destination
address is equal to Segment List [Segments Left] and Segments Left is address is equal to Segment List [Segments Left] and Segments Left is
less than or equal to Last Segment+1. less than or equal to Last Segment+1.
skipping to change at page 13, line 23 skipping to change at page 13, line 44
No Match No Match
4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID
This document, and section, defines a single SRv6 SID called END. This document, and section, defines a single SRv6 SID called END.
Future documents may define additional SRv6 SIDs. In which case, the Future documents may define additional SRv6 SIDs. In which case, the
entire content of this section will be defined in that document. entire content of this section will be defined in that document.
If the FIB entry represents a locally instantiated SRv6 SID, process If the FIB entry represents a locally instantiated SRv6 SID, process
the next header of the IPv6 header as defined in section 4 of the next header of the IPv6 header as defined in section 4 of
[RFC8200] [RFC8200]. Section 4.3.1.1 describes how to process an SRH,
Section 4.3.1.2 describes how to process an upper layer header or no
The following sections describe the actions to take while processing next header.
next header fields of the IPv6, and subsequent extension headers in
the order they are received.
4.3.1.1. SRH Processing 4.3.1.1. SRH Processing
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If Segments Left is equal to zero { S02. If Segments Left is equal to zero {
S03. Proceed to process the next header in the packet, S03. Proceed to process the next header in the packet,
whose type is identified by the Next Header field in whose type is identified by the Next Header field in
the Routing header. the Routing header.
S04. } S04. }
S05. Else { S05. Else {
S06. If local policy requires TLV processing { S06. If local configuration requires TLV processing {
S07. Perform TLV processing (see TLV Processing) S07. Perform TLV processing (see TLV Processing)
S08. } S08. }
S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1 S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1
S10. If ((Last Entry > max_last_entry) or S10. If ((Last Entry > max_last_entry) or
S11. (Segments Left is greater than (Last Entry+1)) { S11. (Segments Left is greater than (Last Entry+1)) {
S12. Send an ICMP Parameter Problem, Code 0, message to S12. Send an ICMP Parameter Problem, Code 0, message to
the Source Address, pointing to the Segments Left the Source Address, pointing to the Segments Left
field, and discard the packet. field, and discard the packet.
S13. } S13. }
S14. Else { S14. Else {
skipping to change at page 14, line 41 skipping to change at page 14, line 41
S21. Decrement the Hop Limit by 1 S21. Decrement the Hop Limit by 1
S22. Resubmit the packet to the IPv6 module for transmission S22. Resubmit the packet to the IPv6 module for transmission
to the new destination. to the new destination.
S23. } S23. }
S24. } S24. }
S25. } S25. }
S26. } S26. }
4.3.1.1.1. TLV Processing 4.3.1.1.1. TLV Processing
Local policy determines how TLV's are to be processed when the Active Local configuration determines how TLVs are to be processed when the
Segment is a local END SID. The definition of local policy is Active Segment is a local END SID. The definition of local
outside the scope of this document. configuration is outside the scope of this document.
For illustration purpose only, two example local policies that may be For illustration purpose only, two example local configurations that
associated with an END SID are provided below. may be associated with an END SID are provided below.
Example 1: Example 1:
For any packet received from interface I2 For any packet received from interface I2
Skip TLV processing Skip TLV processing
Example 2: Example 2:
For any packet received from interface I1 For any packet received from interface I1
If first TLV is HMAC { If first TLV is HMAC {
Process the HMAC TLV Process the HMAC TLV
} }
Else { Else {
Discard the packet Discard the packet
} }
4.3.1.2. Upper-layer Header or No Next Header 4.3.1.2. Upper-layer Header or No Next Header
When processing the Upper-layer header of a packet matching a FIB When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an SRv6 END SID. entry locally instantiated as an SRv6 END SID.
IF (Upper-layer Header is IPv4 or IPv6) and local policy permits { IF (Upper-layer Header is IPv4 or IPv6) and
local configuration permits {
Perform IPv6 decapsulation Perform IPv6 decapsulation
Resubmit the decapsulated packet to the IPv4 or IPv6 module Resubmit the decapsulated packet to the IPv4 or IPv6 module
} }
ELSE { ELSE {
Send an ICMP parameter problem message to the Source Address and Send an ICMP parameter problem message to the Source Address and
discard the packet. Error code (TBD by IANA) "SR Upper-layer discard the packet. Error code (TBD by IANA) "SR Upper-layer
Header Error", pointer set to the offset of the upper-layer Header Error", pointer set to the offset of the upper-layer
header. header.
} }
skipping to change at page 17, line 18 skipping to change at page 17, line 18
* at node k, all SIDs local to k are assigned from prefix Sk/sk * at node k, all SIDs local to k are assigned from prefix Sk/sk
* configure each internal interface of each SR node k in the SR * configure each internal interface of each SR node k in the SR
Domain with an inbound IACL which drops any incoming packet Domain with an inbound IACL which drops any incoming packet
with a destination address in Sk/sk if the source address is with a destination address in Sk/sk if the source address is
not in A/a. not in A/a.
5.2. SR Domain as a single system with delegation among components 5.2. SR Domain as a single system with delegation among components
All intra SR Domain packets are of the SR Domain. The IP v6 header All intra SR Domain packets are of the SR Domain. The IPv6 header is
is originated by a node of the SR Domain, and is destined to a node originated by a node of the SR Domain, and is destined to a node of
of the SR Domain. the SR Domain.
All inter domain packets are encapsulated for the part of the packet All inter domain packets are encapsulated for the part of the packet
journey that is within the SR Domain. The outer IPv6 header is journey that is within the SR Domain. The outer IPv6 header is
originated by a node of the SR Domain, and is destined to a node of originated by a node of the SR Domain, and is destined to a node of
the SR Domain. the SR Domain.
As a consequence, any packet within the SR Domain is of the SR As a consequence, any packet within the SR Domain is of the SR
Domain. Domain.
The SR Domain is a system in which the operator may want to The SR Domain is a system in which the operator may want to
skipping to change at page 17, line 46 skipping to change at page 17, line 46
SRH to a more trusted router or switch attached to the host. SRH to a more trusted router or switch attached to the host.
Consider a top of rack switch (T) connected to host (H) via interface Consider a top of rack switch (T) connected to host (H) via interface
(I). H receives an SRH (SRH1) with a computed HMAC via some SDN (I). H receives an SRH (SRH1) with a computed HMAC via some SDN
method outside the scope of this document. H classifies traffic it method outside the scope of this document. H classifies traffic it
sources and adds SRH1 to traffic requiring a specific SLA. T is sources and adds SRH1 to traffic requiring a specific SLA. T is
configured with an IACL on I requiring verification of the SRH for configured with an IACL on I requiring verification of the SRH for
any packet destined to the SID block of the SR Domain (S/s). T any packet destined to the SID block of the SR Domain (S/s). T
checks and verifies that SRH1 is valid, contains an HMAC TLV and checks and verifies that SRH1 is valid, contains an HMAC TLV and
verifies the HMAC. verifies the HMAC.
An operator of the SR Domain may choose to have all segments in the
SR Domain verify the HMAC. This mechanism would verify that the SRH
segment list is not modified while traversing the SR Domain.
5.3. MTU Considerations 5.3. MTU Considerations
Within the SR Domain, well known mitigation techniques are Within the SR Domain, well known mitigation techniques are
RECOMMENDED, such as deploying a greater MTU value within the SR RECOMMENDED, such as deploying a greater MTU value within the SR
Domain than at the ingress edges. Domain than at the ingress edges.
5.4. AH ICV 5.4. ICMP Error Processing
Within the domain, an SR source node which includes SRH and AH
extension headers can predict the content of the SRH and calculate
the ICV at the SR source node, ensuring it can be confirmed at the
destination.
5.5. ESP ICV
Within the domain, an SR source node may include SRH and ESP
extension headers. Only the data following the ESP header is
included in ICV computation. SRH precedes ESP.
5.6. ICMP Error Processing
ICMP error packets generated within the SR Domain are sent to source ICMP error packets generated within the SR Domain are sent to source
nodes within the SR Domain. The invoking packet in the ICMP error nodes within the SR Domain. The invoking packet in the ICMP error
message may contain an SRH. Since the destination address of a message may contain an SRH. Since the destination address of a
packet with an SRH changes as each segment is processed, it may not packet with an SRH changes as each segment is processed, it may not
be the destination used by the socket or application that generated be the destination used by the socket or application that generated
the invoking packet. the invoking packet.
For the source of an invoking packet to process the ICMP error For the source of an invoking packet to process the ICMP error
message, the correct destination address must be determined. The message, the correct destination address must be determined. The
skipping to change at page 18, line 46 skipping to change at page 18, line 39
+ Use the 0th segment in the segment list as the destination + Use the 0th segment in the segment list as the destination
address of the invoking packet. address of the invoking packet.
ICMP errors are then processed by upper layer transports as defined ICMP errors are then processed by upper layer transports as defined
in [RFC4443]. in [RFC4443].
For IP packets encapsulated in an outer IPv6 header, ICMP error For IP packets encapsulated in an outer IPv6 header, ICMP error
handling is as defined in [RFC2473]. handling is as defined in [RFC2473].
5.7. Load Balancing and ECMP 5.5. Load Balancing and ECMP
For any inter domain packet, the SR Source node MUST impose a flow For any inter domain packet, the SR Source node MUST impose a flow
label computed based on the inner packet. The computation of the label computed based on the inner packet. The computation of the
flow label is as recommended in [RFC6438] for the sending Tunnel End flow label is as recommended in [RFC6438] for the sending Tunnel End
Point. Point.
For any intra domain packet, the SR Source node SHOULD impose a flow For any intra domain packet, the SR Source node SHOULD impose a flow
label computed as described in [RFC6437] to assist ECMP load label computed as described in [RFC6437] to assist ECMP load
balancing at transit nodes incapable of computing a 5-tuple beyond balancing at transit nodes incapable of computing a 5-tuple beyond
the SRH. the SRH.
skipping to change at page 19, line 20 skipping to change at page 19, line 12
At any transit node within an SR domain, the flow label MUST be used At any transit node within an SR domain, the flow label MUST be used
as defined in [RFC6438] to calculate the ECMP hash toward the as defined in [RFC6438] to calculate the ECMP hash toward the
destination address. If flow label is not used, the transit node destination address. If flow label is not used, the transit node
would likely hash all packets between a pair of SR Edge nodes to the would likely hash all packets between a pair of SR Edge nodes to the
same link. same link.
At an SR segment endpoint node, the flow label MUST be used as At an SR segment endpoint node, the flow label MUST be used as
defined in [RFC6438] to calculate any ECMP hash used to forward the defined in [RFC6438] to calculate any ECMP hash used to forward the
processed packet to the next segment. processed packet to the next segment.
5.8. Other Deployments 5.6. Other Deployments
Other deployment models and their implications on security, MTU, Other deployment models and their implications on security, MTU,
HMAC, ICMP error processing and interaction with other extension HMAC, ICMP error processing and interaction with other extension
headers are outside the scope of this document. headers are outside the scope of this document.
6. Illustrations 6. Illustrations
This section provides illustrations of SRv6 packet processing at SR This section provides illustrations of SRv6 packet processing at SR
source, transit and SR segment endpoint nodes. source, transit and SR segment endpoint nodes.
skipping to change at page 22, line 12 skipping to change at page 22, line 4
P6: (A3, S7)(S4; SL=1)(A1, A2) P6: (A3, S7)(S4; SL=1)(A1, A2)
6.3.3. Inter SR Domain Packet - Internal to External 6.3.3. Inter SR Domain Packet - Internal to External
When host 8 sends a packet to host 1, the packet is encapsulated for When host 8 sends a packet to host 1, the packet is encapsulated for
the portion of its journey within the SR Domain. From 8 to 3 the the portion of its journey within the SR Domain. From 8 to 3 the
packet is packet is
P7: (A8,S3)(A8,A1) P7: (A8,S3)(A8,A1)
In the opposite direction, the packet generated from 1 to 8 is In the opposite direction, the packet generated from 1 to 8 is
P8: (A1,A8) P8: (A1,A8)
At node 3 P8 is encapsulated for the portion of its journey within At node 3 P8 is encapsulated for the portion of its journey within
the SR domain. Resulting in the SR domain, with the outer header destined to segment S8.
Resulting in
P9: (A3,S8)(A1,A8) P9: (A3,S8)(A1,A8)
At node 9 the outer IPv6 header is removed by S6 processing then At node 8 the outer IPv6 header is removed by S8 processing, then
processed again when received by A8. processed again when received by A8.
6.4. Transit Node 6.4. Transit Node
Nodes 5 acts as transit nodes for packet P1, and sends packet Nodes 5 acts as transit nodes for packet P1, and sends packet
P1: (A8,S7)(A9,S7;SL=1) P1: (A8,S7)(A9,S7;SL=1)
on the interface toward node 7. on the interface toward node 7.
skipping to change at page 23, line 38 skipping to change at page 23, line 31
This use of an HMAC is particularly valuable within an enterprise This use of an HMAC is particularly valuable within an enterprise
based SR Domain [SRN]. based SR Domain [SRN].
7. Security Considerations 7. Security Considerations
This section reviews security considerations related to the SRH, This section reviews security considerations related to the SRH,
given the SRH processing and deployment models discussed in this given the SRH processing and deployment models discussed in this
document. document.
As describe in Section 5, it is necessary to filter packets ingress As described in Section 5, it is necessary to filter packets ingress
to the SR Domain destined to segments within the SR Domain. This to the SR Domain, destined to SIDs within the SR Domain (i.e.,
ingress filtering is via an IACL at SR Domain ingress border nodes. bearing a SID in the destination address). This ingress filtering is
Additional protection is applied via an IACL at each SR Segment via an IACL at SR Domain ingress border nodes. Additional protection
Endpoint node, filtering packets not from within the SR Domain, is applied via an IACL at each SR Segment Endpoint node, filtering
destined to SIDs in the SR Domain. ACLs are easily supported for packets not from within the SR Domain, destined to SIDs in the SR
small numbers of prefixes, making summarization important, and when Domain. ACLs are easily supported for small numbers of prefixes,
the prefixes requiring filtering is kept to a seldom changing set. making summarization important, and when the prefixes requiring
filtering is kept to a seldom changing set.
Additionally, ingress filtering of IPv6 source addresses as Additionally, ingress filtering of IPv6 source addresses as
recommended in BCP38 SHOULD be used. recommended in BCP38 SHOULD be used.
7.1. Source Routing Attacks 7.1. Source Routing Attacks
[RFC5095] deprecates the Type 0 Routing header due to a number of [RFC5095] deprecates the Type 0 Routing header due to a number of
significant attacks that are referenced in that document. Such significant attacks that are referenced in that document. Such
attacks include bypassing filtering devices, reaching otherwise attacks include bypassing filtering devices, reaching otherwise
unreachable Internet systems, network topology discovery, bandwidth unreachable Internet systems, network topology discovery, bandwidth
skipping to change at page 24, line 42 skipping to change at page 24, line 34
Domain by a node not authorized to use the service. Domain by a node not authorized to use the service.
Service theft is not a concern within the SR Domain as all SR Source Service theft is not a concern within the SR Domain as all SR Source
nodes and SR segment endpoint nodes within the domain are able to nodes and SR segment endpoint nodes within the domain are able to
utilize the services of the Domain. If a node outside the SR Domain utilize the services of the Domain. If a node outside the SR Domain
learns of segments or a topological service within the SR domain, learns of segments or a topological service within the SR domain,
IACL filtering denies access to those segments. IACL filtering denies access to those segments.
7.3. Topology Disclosure 7.3. Topology Disclosure
The SRH may contains SIDs of some intermediate SR-nodes in the path The SRH is unencrypted and may contain SIDs of some intermediate SR-
towards the destination, this reveals those addresses to attackers if nodes in the path towards the destination within the SR Domain. If
they are able to intercept packets containing SRH. packets can be sooped within the SR Domain, the SRH may reveal
toplogy, traffic flows, and service usage.
This is applicable within an SR Domain but the disclosure is less This is applicable within an SR Domain but the disclosure is less
relevant as an attacker has other means of learning topology. relevant as an attacker has other means of learning topology, flows,
and service usage.
7.4. ICMP Generation 7.4. ICMP Generation
The generation of ICMPv6 error messages may be used to attempt The generation of ICMPv6 error messages may be used to attempt
denial-of-service attacks by sending an error-causing destination denial-of-service attacks by sending an error-causing destination
address or SRH in back-to-back packets. An implementation that address or SRH in back-to-back packets. An implementation that
correctly follows Section 2.4 of [RFC4443] would be protected by the correctly follows Section 2.4 of [RFC4443] would be protected by the
ICMPv6 rate-limiting mechanism. ICMPv6 rate-limiting mechanism.
7.5. AH ICV computation
For the purpose of AH ICV calculation the SRH is considered mutable,
with the exception of Next Header, Hdr Ext Len, Routing Type which
are considered immutable.
8. IANA Considerations 8. IANA Considerations
This document makes the following registrations in the Internet This document makes the following registrations in the Internet
Protocol Version 6 (IPv6) Parameters "Routing Type" registry Protocol Version 6 (IPv6) Parameters "Routing Type" registry
maintained by IANA: maintained by IANA:
Suggested Description Reference Suggested Description Reference
Value Value
---------------------------------------------------------- ----------------------------------------------------------
4 Segment Routing Header (SRH) This document 4 Segment Routing Header (SRH) This document
skipping to change at page 26, line 18 skipping to change at page 26, line 18
identify SRH Flags Bits. The registration procedure is "Expert identify SRH Flags Bits. The registration procedure is "Expert
Review" as defined in [RFC8126]. Suggested registry name is "Segment Review" as defined in [RFC8126]. Suggested registry name is "Segment
Routing Header Flags". Flags is 8 bits. Routing Header Flags". Flags is 8 bits.
8.2. Segment Routing Header TLVs Register 8.2. Segment Routing Header TLVs Register
This document requests the creation of a new IANA managed registry to This document requests the creation of a new IANA managed registry to
identify SRH TLVs. The registration procedure is "Expert Review" as identify SRH TLVs. The registration procedure is "Expert Review" as
defined in [RFC8126]. Suggested registry name is "Segment Routing defined in [RFC8126]. Suggested registry name is "Segment Routing
Header TLVs". A TLV is identified through an unsigned 8 bit Header TLVs". A TLV is identified through an unsigned 8 bit
codepoint value. The following codepoints are defined in this codepoint value, with assigned values 0-255. The following
document: codepoints are defined in this document:
Suggested Description Reference Assigned Description Reference
Value Value
----------------------------------------------------- -----------------------------------------------------
0 Pad0 TLV This document
1 PadN TLV This document
5 HMAC TLV This document 5 HMAC TLV This document
128 Pad0 TLV This document
129 PadN TLV This document
9. Implementation Status 9. Implementation Status
This section is to be removed prior to publishing as an RFC. This section is to be removed prior to publishing as an RFC.
See [I-D.matsushima-spring-srv6-deployment-status] for updated
deployment and interoperability reports.
9.1. Linux 9.1. Linux
Name: Linux Kernel v4.14 Name: Linux Kernel v4.14
Status: Production Status: Production
Implementation: adds SRH, performs END processing, supports HMAC TLV Implementation: adds SRH, performs END processing, supports HMAC TLV
Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and
[I-D.filsfils-spring-srv6-interop] [I-D.filsfils-spring-srv6-interop]
9.2. Cisco Systems 9.2. Cisco Systems
Name: IOS XR and IOS XE Name: IOS XR and IOS XE
Status: Production (IOS XR), Pre-protuction (IOS XE) Status: Production (IOS XR), Pre-production (IOS XE)
Implementation: adds SRH, performs END processing, no TLV processing Implementation: adds SRH, performs END processing, no TLV processing
Details: [I-D.filsfils-spring-srv6-interop] Details: [I-D.filsfils-spring-srv6-interop]
9.3. FD.io 9.3. FD.io
Name: VPP/Segment Routing for IPv6 Name: VPP/Segment Routing for IPv6
Status: Production Status: Production
Implementation: adds SRH, performs END processing, no TLV processing Implementation: adds SRH, performs END processing, no TLV processing
skipping to change at page 29, line 13 skipping to change at page 29, line 13
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
12.2. Informative References 12.2. Informative References
[I-D.filsfils-spring-srv6-interop] [I-D.filsfils-spring-srv6-interop]
Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A.,
Salsano, S., Bonaventure, O., Horn, J., and J. Liste, Salsano, S., Bonaventure, O., Horn, J., and J. Liste,
"SRv6 interoperability report", draft-filsfils-spring- "SRv6 interoperability report", draft-filsfils-spring-
srv6-interop-02 (work in progress), March 2019. srv6-interop-02 (work in progress), March 2019.
[I-D.matsushima-spring-srv6-deployment-status]
Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6
Implementation and Deployment Status", draft-matsushima-
spring-srv6-deployment-status-00 (work in progress), March
2019.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008, DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>. <https://www.rfc-editor.org/info/rfc5308>.
 End of changes. 57 change blocks. 
122 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/