draft-ietf-6man-segment-routing-header-18.txt   draft-ietf-6man-segment-routing-header-19.txt 
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft D. Dukes, Ed.
Intended status: Standards Track S. Previdi Intended status: Standards Track Cisco Systems, Inc.
Expires: October 7, 2019 Huawei Expires: November 22, 2019 S. Previdi
Huawei
J. Leddy J. Leddy
Individual Individual
S. Matsushima S. Matsushima
Softbank Softbank
D. Voyer, Ed. D. Voyer, Ed.
Bell Canada Bell Canada
April 5, 2019 May 21, 2019
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-18 draft-ietf-6man-segment-routing-header-19
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.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 41
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 October 7, 2019. This Internet-Draft will expire on November 22, 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
skipping to change at page 2, line 21 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 7
2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8
3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . 12
3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 12 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 13
4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 13
4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 13 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 SID . . . . . 14
4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 15 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 16
4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 16 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 17
4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 16 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 17
5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 16 5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 17
5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 16 5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 18 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 19
5.4. ICMP Error Processing . . . . . . . . . . . . . . . . . . 18 5.4. ICMP Error Processing . . . . . . . . . . . . . . . . . . 19
5.5. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 18 5.5. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 19
5.6. Other Deployments . . . . . . . . . . . . . . . . . . . . 19 5.6. Other Deployments . . . . . . . . . . . . . . . . . . . . 20
6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Abstract Representation of an SRH . . . . . . . . . . . . 19 6.1. Abstract Representation of an SRH . . . . . . . . . . . . 20
6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 20 6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 21
6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 20 6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 21
6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 21 6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 22
6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 21 6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 22
6.3.3. Inter SR Domain Packet - Internal to External . . . . 21 6.3.3. Inter SR Domain Packet - Internal to External . . . . 22
6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 22 6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 23
6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 22 6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 23
6.6. Delegation of Function with HMAC Verification . . . . . . 22 6.6. Delegation of Function with HMAC Verification . . . . . . 23
6.6.1. SID List Verification . . . . . . . . . . . . . . . . 22 6.6.1. SID List Verification . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 24
7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 24 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 25
7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 24 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 25
7.5. AH ICV computation . . . . . . . . . . . . . . . . . . . 25 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7.5. Applicability of AH . . . . . . . . . . . . . . . . . . . 26
8.1. Segment Routing Header Flags Register . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8.2. Segment Routing Header TLVs Register . . . . . . . . . . 26 8.1. Segment Routing Header Flags Register . . . . . . . . . . 27
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 8.2. Segment Routing Header TLVs Register . . . . . . . . . . 27
9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 27
9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 28
9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 27 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 28
9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
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 (SRH). This document describes the type of Routing Extension Header (SRH). 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.
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.
skipping to change at page 4, line 42 skipping to change at page 4, line 42
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
// Optional Type Length Value objects (variable) // // Optional Type Length Value objects (variable) //
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Next Header: Defined in [RFC8200] o Next Header: Defined in [RFC8200] Section 4.4
o Hdr Ext Len: Defined in [RFC8200] o Hdr Ext Len: Defined in [RFC8200] Section 4.4
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] Section 4.4
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. Section 8.1 creates an IANA registry for o Flags: 8 bits of flags. Section 8.1 creates an IANA registry for
new flags to be deinfed. The following flags are defined: new flags to be defined. 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.,
skipping to change at page 5, line 34 skipping to change at page 5, line 34
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.
In the SRH, the Next Header, Hdr Ext Len, and Routing Type fields are
defined in Section 4.4 of [RFC8200] as not mutable. The Segments
Left field is defined as mutable in Section 4.4 of [RFC8200].
Some of the other fields of the SRH change en route (i.e. they are
mutable). The SRH is processed as defined in Section 4.3 of this
document, and uniquely per SID type. The mutability of the remaining
fields in the SRH (Flags, Tag, Segment List, Optional TLVs) are
defined in that section, in the context of segment processing.
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 A TLV provides meta-data for segment processing. The only TLVs
defined in this document are the HMAC (Section 2.1.2) and PAD 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 2.1.1) TLVs. While processing the SID defined in
Section 4.3.1, all TLVs are ignored unless local configuration Section 4.3.1, all TLVs are ignored unless local configuration
indicates otherwise (Section 4.3.1.1.1). Thus, TLV and HMAC support indicates otherwise (Section 4.3.1.1.1). Thus, TLV and HMAC support
is optional for any implementation. Other documents may define is optional for any implementation, however an implementation adding
or parsing TLVs MUST support PAD TLVs. Other documents may define
additional TLVs and processing rules for them. 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
skipping to change at page 6, line 45 skipping to change at page 7, line 10
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
type may change en route the most significant bit of the Type has the
following significance:
0: TLV data does not change en route
1: TLV data does change en route
All TLVs specify their alignment requirements using an xn+y format. All TLVs specify their alignment requirements using an xn+y format.
The xn+y format is defined as per [RFC8200]. The SR Source nodes use The xn+y format is defined as per [RFC8200]. The SR Source nodes use
the xn+y alignment requirements of TLVs and padding TLVs when the xn+y alignment requirements of TLVs and padding TLVs when
constructing an SRH. constructing an SRH.
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.
skipping to change at page 7, line 37 skipping to change at page 8, line 14
2.1.1.1. PAD0 2.1.1.1. PAD0
Alignment requirement: none 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 0)
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 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 1).
Length: 0 to 5 Length: 0 to 5
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.
skipping to change at page 13, line 36 skipping to change at page 14, line 5
When an SRv6-capable node receives an IPv6 packet, it performs a When an SRv6-capable node receives an IPv6 packet, it performs a
longest-prefix-match lookup on the packets destination address. This longest-prefix-match lookup on the packets destination address. This
lookup can return any of the following: lookup can return any of the following:
A FIB entry that represents a locally instantiated SRv6 SID A FIB entry that represents a locally instantiated SRv6 SID
A FIB entry that represents a local interface, not locally A FIB entry that represents a local interface, not locally
instantiated as an SRv6 SID instantiated as an SRv6 SID
A FIB entry that represents a non-local route A FIB entry that represents a non-local route
No Match No Match
4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID
This document, and section, defines a single SRv6 SID called END. This document, and section, defines a single SRv6 SID. Future
Future documents may define additional SRv6 SIDs. In which case, the documents may define additional SRv6 SIDs. In which case, the entire
entire content of this section will be defined in that document. 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 chain of the IPv6 header as defined in section 4 of
[RFC8200]. Section 4.3.1.1 describes how to process an SRH, [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 Section 4.3.1.2 describes how to process an upper layer header or no
next header. next header.
Processing this SID type modifies the Segments Left and, if
configured to process TLVs, it may modify the "variable length data"
of TLV types that change en route. Therefore Segments Left is
mutable and TLVs that change en route are mutable. The remainder of
the SRH (Flags, Tag, Segment List, and TLVs that do not change en
route) are immutable while processing this SID type.
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 configuration requires TLV processing { S06. If local configuration requires TLV processing {
S07. Perform TLV processing (see TLV Processing) S07. Perform TLV processing (see TLV Processing)
skipping to change at page 14, line 42 skipping to change at page 15, line 42
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 configuration determines how TLVs are to be processed when the Local configuration determines how TLVs are to be processed when the
Active Segment is a local END SID. The definition of local Active Segment is a local SID type defined in this document. The
configuration is outside the scope of this document. definition of local configuration is outside the scope of this
document.
For illustration purpose only, two example local configurations that For illustration purpose only, two example local configurations that
may be associated with an END SID are provided below. may be associated with a 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 SID type defined in this
document.
IF (Upper-layer Header is IPv4 or IPv6) and IF (Upper-layer Header is IPv4 or IPv6) and
local configuration permits { 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
skipping to change at page 24, line 36 skipping to change at page 25, line 36
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 is unencrypted and may contain SIDs of some intermediate SR- The SRH is unencrypted and may contain SIDs of some intermediate SR-
nodes in the path towards the destination within the SR Domain. If nodes in the path towards the destination within the SR Domain. If
packets can be sooped within the SR Domain, the SRH may reveal packets can be snooped within the SR Domain, the SRH may reveal
toplogy, traffic flows, and service usage. topology, 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, flows, relevant as an attacker has other means of learning topology, flows,
and service usage. 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 7.5. Applicability of AH
For the purpose of AH ICV calculation the SRH is considered mutable, The SR Domain is a trusted domain, as defined in [RFC8402] Section 2
with the exception of Next Header, Hdr Ext Len, Routing Type which and Section 8.2. The SR Source is trusted to add an SRH (optionally
are considered immutable. verified via the HMAC TLV in this document), and segments advertised
within the domain are trusted to be accurate and advertised by
trusted sources via a secure control plane. As such the SR Domain
does not rely on the Authentication Header (AH) as defined in
[RFC4302] to secure the SRH.
The use of SRH with AH by an SR source node, and processing at a SR
segment endpoint node, is not defined in this document. Future
documents may define use of SRH with AH and its processing.
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
---------------------------------------------------------- ----------------------------------------------------------
skipping to change at page 26, line 18 skipping to change at page 27, line 22
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, with assigned values 0-255. The following codepoint value, with assigned values 0-127 for TLVs that do not
codepoints are defined in this document: change en route, and 128-255 for TLVs that may change en route. The
following codepoints are defined in this document:
Assigned Description Reference Assigned Description Reference
Value Value
----------------------------------------------------- -----------------------------------------------------
0 Pad0 TLV This document 0 Pad0 TLV This document
1 PadN TLV This document 1 PadN TLV This document
5 HMAC TLV This document 5 HMAC TLV This document
9. Implementation Status 9. Implementation Status
skipping to change at page 27, line 46 skipping to change at page 29, line 7
9.6. Huawei 9.6. Huawei
Name: Huawei Systems VRP Platform Name: Huawei Systems VRP Platform
Status: Production Status: Production
Implementation: adds SRH, performs END processing, no TLV processing Implementation: adds SRH, performs END processing, no TLV processing
10. Contributors 10. Contributors
Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung, Kamran Raza, Zafar Ali, Brian Field, Daniel Bernier, Ida Leung, Jen
Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk
Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre
Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta
Maglione, James Connolly, Aloys Augustin contributed to the content Maglione, James Connolly, Aloys Augustin contributed to the content
of this document. of this document.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica,
Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal,
and David Lebrun for their comments to this document. and David Lebrun for their comments to this document.
skipping to change at page 28, line 30 skipping to change at page 29, line 39
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007, DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/info/rfc5095>. <https://www.rfc-editor.org/info/rfc5095>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407, of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <https://www.rfc-editor.org/info/rfc6407>. October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 29, line 16 skipping to change at page 30, line 30
[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] [I-D.matsushima-spring-srv6-deployment-status]
Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6
Implementation and Deployment Status", draft-matsushima- Implementation and Deployment Status", draft-matsushima-
spring-srv6-deployment-status-00 (work in progress), March spring-srv6-deployment-status-01 (work in progress), May
2019. 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>.
[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,
skipping to change at page 30, line 20 skipping to change at page 31, line 35
Authors' Addresses Authors' Addresses
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Darren Dukes (editor)
Cisco Systems, Inc.
Ottawa
CA
Email: ddukes@cisco.com
Stefano Previdi Stefano Previdi
Huawei Huawei
Italy Italy
Email: stefano@previdi.net Email: stefano@previdi.net
John Leddy John Leddy
Individual Individual
US US
Email: john@leddy.net Email: john@leddy.net
Satoru Matsushima Satoru Matsushima
Softbank Softbank
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
 End of changes. 34 change blocks. 
82 lines changed or deleted 132 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/