< draft-ietf-6man-segment-routing-header-12.txt   draft-ietf-6man-segment-routing-header-13.txt >
Network Working Group S. Previdi Network Working Group S. Previdi
Internet-Draft Individual Internet-Draft Individual
Intended status: Standards Track C. Filsfils, Ed. Intended status: Standards Track C. Filsfils, Ed.
Expires: October 21, 2018 Cisco Systems, Inc. Expires: November 24, 2018 Cisco Systems, Inc.
J. Leddy J. Leddy
Comcast Comcast
S. Matsushima S. Matsushima
Softbank Softbank
D. Voyer, Ed. D. Voyer, Ed.
Bell Canada Bell Canada
April 19, 2018 May 23, 2018
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-12 draft-ietf-6man-segment-routing-header-13
Abstract Abstract
Segment Routing (SR) allows a node to steer a packet through a Segment Routing can be applied to the IPv6 data plane using a new
controlled set of instructions, called segments, by prepending an SR type of Routing Extension Header. This document describes the
header to the packet. A segment can represent any instruction, Segment Routing Extension Header and how it is used by Segment
topological or service-based. SR allows a node to steer a flow Routing capable nodes.
through any path (topological, or application/service based) while
maintaining per-flow state only at the ingress node to the SR domain.
Segment Routing can be applied to the IPv6 data plane with the
addition of a new type of Routing Extension Header. This document
describes the Segment Routing Extension Header Type and how it is
used by SR capable nodes.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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
skipping to change at page 2, line 7 skipping to change at page 1, line 46
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 21, 2018. This Internet-Draft will expire on November 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Segment Routing Extension Header . . . . . . . . . . . . . . 4
2.1. Data Planes supporting Segment Routing . . . . . . . . . 4 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 7
2.3. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 5 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8
3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 5 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 8 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 10 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 10
3.2. SRH Processing . . . . . . . . . . . . . . . . . . . . . 11 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 10
4. SRH Functions . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 10
4.1. Endpoint Function (End) . . . . . . . . . . . . . . . . . 11 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 10
4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 12 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11
5. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Segment Endpoint Node . . . . . . . . . . . . . . . . . . 11
5.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 11
5.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 14 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 12
5.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 14 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 13
5.4. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 14 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4.4. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 13
6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 15 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Source routing threats . . . . . . . . . . . . . . . 15 5.1. Abstract Representation of an SRH . . . . . . . . . . . . 13
6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 16 5.2. Example Topology . . . . . . . . . . . . . . . . . . . . 14
6.1.3. Service stealing threat . . . . . . . . . . . . . . . 17 5.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 15
6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 17 5.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 15
6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 17 5.3.2. Transit Packet Through SR Domain . . . . . . . . . . 15
6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 18 5.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 15
6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 19 5.5. SR End Node . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.2.3. Pre-shared key management . . . . . . . . . . . . . . 20 6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 20 6.1.1. Source routing threats . . . . . . . . . . . . . . . 17
6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 20 6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 17
6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 21 6.1.3. Service stealing threat . . . . . . . . . . . . . . . 18
6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 21 6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 18
6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 22 6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 19
7.1. Segment Routing Header Flags Register . . . . . . . . . . 22 6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 20
7.2. Segment Routing Header TLVs Register . . . . . . . . . . 23 6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 20
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 6.2.3. Pre-shared key management . . . . . . . . . . . . . . 21
8.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 22
8.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 23 6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 22
8.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 22
8.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 23
8.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Segment Routing Header Flags Register . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Segment Routing Header TLVs Register . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 26 8.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 25
8.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 25
8.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Segment Routing Documents 1. Introduction
Segment Routing terminology is defined in
[I-D.ietf-spring-segment-routing].
The network programming paradigm
[I-D.filsfils-spring-srv6-network-programming] defines additional
functions associated to a Segment Routing for IPv6 (SRv6) Segment ID
(SID).
Segment Routing use cases are described in [RFC7855] and [RFC8354].
Segment Routing protocol extensions are defined in
[I-D.ietf-isis-segment-routing-extensions], and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
2. Introduction
Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing],
allows a node to steer a packet through a controlled set of
instructions, called segments, by prepending an SR header to the
packet. A segment can represent any instruction, topological or
service-based. SR allows a node to steer a flow through any path
(topological or service/application based) while maintaining per-flow
state only at the ingress node to the SR domain. Segments can be
derived from different components: IGP, BGP, Services, Contexts,
Locators, etc. The list of segment forming the path is called the
Segment List and is encoded in the packet header.
SR allows the use of strict and loose source based routing paradigms
without requiring any additional signaling protocols in the
infrastructure hence delivering an excellent scalability property.
The source based routing model described in
[I-D.ietf-spring-segment-routing] inherits from the ones proposed by
[RFC1940] and [RFC8200]. The source based routing model offers the
support for explicit routing capability.
2.1. Data Planes supporting Segment Routing
Segment Routing (SR), can be instantiated over MPLS
(SRMPLS)([I-D.ietf-spring-segment-routing-mpls]) and IPv6 (SRv6).
This document defines its instantiation over the IPv6 data-plane
based on the use-cases defined in [RFC8354].
This document defines a new type of Routing Header (originally
defined in [RFC8200]) called the Segment Routing Header (SRH) in
order to convey the Segment List in the packet header as defined in
[I-D.ietf-spring-segment-routing]. Mechanisms through which segments
are known and advertised are outside the scope of this document.
2.2. SRv6 Segment
An SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are
often used as a shorter reference for "SRv6 Segment".
An SRv6-capable node N maintains a "My Local SID Table". This table
contains all the local SRv6 segments explicitly instantiated at node
N. N is the parent node for these SIDs.
A local SID of N could be an IPv6 address of a local interface of N
but it does not have to be. Most often, a local SID is not an
address of a local interface of N. The My Local SID Table is thus
not populated by default with all the addresses of a node.
Every SRv6 local SID instantiated has a specific instruction bounded
to it.
This information is stored in the My Local SID Table. The My Local
SID Table has three main purposes:
o Define which local SIDs are explicitly instantiated.
o Specify which instruction is bound to each of the instantiated
SIDs.
o Store the parameters associated to such instruction (i.e. OIF,
NextHop,...).
A Segment ID (SID) in the destination address of an IPv6 header, is Segment Routing can be applied to the IPv6 data plane using a new
routed through an IPv6 network as an IPv6 address. SIDs, or the type of Routing Extension Header (SRH). This document describes the
prefix(es) covering SIDs in the My Local SID Table, and their Segment Routing Extension Header and how it is used by Segment
reachability may be distributed by means outside the scope of this Routing capable nodes.
document. For example, [RFC5308] or [RFC5340] may be used to
advertise a prefix covering the My Local SID Table.
A node may receive a packet with an SRv6 SID in the DA without an The Segment Routing Architecture [I-D.ietf-spring-segment-routing]
SRH. In such case the packet should still be processed by the describes Segment Routing and its instantiation in two data planes
Segment Routing engine. MPLS and IPv6.
2.3. Segment Routing (SR) Domain SR with the MPLS data plane is defined in
[I-D.ietf-spring-segment-routing-mpls].
The Segment Routing Domain (SR Domain) is defined as the set of nodes SR with the IPv6 data plane is defined in
participating in the source based routing model. These nodes may be [I-D.filsfils-spring-srv6-network-programming].
connected to the same physical infrastructure (e.g.: a Service
Provider's network).
The SRH is added to the packet by its source, consistent with the The encoding of MPLS labels and label stacking are defined in
source routing model defined in [RFC8200]. For example: [RFC3032].
o At the node originating the packet (host, server). The encoding of IPv6 segments in the Segment Routing Extension header
is defined in this document.
o At the ingress node of an SR domain where the ingress node Terminology used within this document is defined in detail in
receives a packet and encapsulates it in an outer IPv6 header [I-D.ietf-spring-segment-routing]. Specifically, these terms:
followed by a Segment Routing header. Segment Routing, SR Domain, SRv6, Segment ID (SID), SRv6 SID, Active
Segment, and SR Policy.
3. Segment Routing Extension Header (SRH) 2. Segment Routing Extension Header
A new type of the Routing Header (originally defined in [RFC8200]) is Routing Headers are defined in [RFC8200]. The Segment Routing Header
defined: the Segment Routing Header (SRH) which has a new Routing has a new Routing Type (suggested value 4) to be assigned by IANA.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left | | Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag | | Last Entry | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 36 skipping to change at page 5, line 4
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
// 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]
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]. See Section 3.2 for detailed o Segments Left: Defined in [RFC8200]
usage during SRH processing.
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. Following flags are defined:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| U |H| U | | U |H| U |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
U: Unused and for future use. SHOULD be 0 on transmission and U: Unused and for future use. SHOULD be 0 on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
H-flag: HMAC flag. If set, the HMAC TLV is present and is H-flag: HMAC flag. If set, the HMAC TLV is present and is
encoded as the last TLV of the SRH. In other words, the last encoded as the last TLV of the SRH. In other words, the last
36 octets of the SRH represent the HMAC information. See 36 octets of the SRH represent the HMAC information. See
Section 3.1.2 for details on the HMAC TLV. Section 2.1.2 for details on the HMAC TLV.
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 SHOULD be set to zero on transmission. When tag is at source it SHOULD be set to zero on transmission. When tag is
not used during SRH Processing it MUST be ignored. The allocation not used during SRH Processing it MUST be ignored. The allocation
and use of tag is outside the scope of this document. 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 path. I.e., the first element of the from the last segment of the SR Policy. I.e., the first element
segment list (Segment List [0]) contains the last segment of the of the segment list (Segment List [0]) contains the last segment
path, the second element contains the penultimate segment of the of the SR Policy, the second element contains the penultimate
path and so on. segment of the SR Policy and so on.
o Type Length Value (TLV) are described in Section 3.1. o Type Length Value (TLV) are described in Section 2.1.
3.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.
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. It is RECOMMENDED
that the total length of new TLVs be multiple of 8 bytes to avoid the that the total length of new TLVs be multiple of 8 bytes to avoid the
use of Padding TLVs. 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 DA of the packet. The information by the node identified in the Destination Address (DA) of the packet.
carried in the TLVs is not intended to be used by the routing layer. The information carried in the TLVs is not intended to be used by the
Typically, TLVs carry information that is consumed by other routing layer. Typically, TLVs carry information that is consumed by
components (e.g.: OAM) than the routing function. other components (e.g.: OAM) than the routing function.
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 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 type may change en route the most significant bit of the Type has the
following significance: following significance:
skipping to change at page 8, line 44 skipping to change at page 7, line 11
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 TLV
HMAC TLV HMAC TLV
Additional TLVs may be defined in the future. Additional TLVs may be defined in the future.
3.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 optional and more than one Padding TLV MUST NOT Padding TLVs are optional and more than one Padding TLV MUST NOT
appear in the SRH. appear in the SRH.
The Padding TLVs are used to align the SRH total length on the 8 The Padding TLVs are used to align the SRH total length on the 8
octet boundary. octet boundary.
skipping to change at page 9, line 19 skipping to change at page 7, line 33
TLV before the HMAC TLV (if HMAC TLV is present). TLV before the HMAC TLV (if HMAC TLV is present).
When present, a PadN TLV MUST have a length from 0 to 5 in order When present, a PadN TLV MUST have a length from 0 to 5 in order
to align the SRH total length on a 8-octet boundary. to align the SRH total length on a 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, even if
more than one is present. more than one is present.
Padding TLVs are ignored during ICV calculation. Padding TLVs are ignored during ICV calculation.
3.1.1.1. PAD0 2.1.1.1. PAD0
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.
3.1.1.2. PADN 2.1.1.2. PADN
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).
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 SHOULD be set to 0 on transmission and MUST be semantics. They SHOULD be set to 0 on transmission and MUST be
ignored on receipt. ignored on 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.
3.1.2. HMAC TLV 2.1.2. HMAC TLV
HMAC TLV is optional and contains the HMAC information. The HMAC TLV HMAC TLV is optional and contains the HMAC information. The HMAC TLV
has the following format: 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 11, line 5 skipping to change at page 9, line 19
o When present, the HMAC TLV MUST be encoded as the last TLV of the o When present, the HMAC TLV MUST be encoded as the last TLV of the
SRH. SRH.
o If the HMAC TLV is present, the SRH H-Flag (Figure 2) MUST be set. o If the HMAC TLV is present, the SRH H-Flag (Figure 2) MUST be set.
Nodes processing SRH SHOULD process the HMAC TLV only when the Nodes processing SRH SHOULD process the HMAC TLV only when the
H-Flag is set, and local policy. H-Flag is set, and local policy.
o When the H-flag is set in the SRH, the router inspecting the SRH o When the H-flag is set in the SRH, the router inspecting the SRH
MUST find the HMAC TLV in the last 38 octets of the SRH. MUST find the HMAC TLV in the last 38 octets of the SRH.
3.2. SRH Processing 3. SR Nodes
Extension header processing is as defined in RFC8200 for packets
destined to a local IPv6 address. If SRH is present, it is processed
as follows (DA represents the destination address in the IPv6
header):
1. IF the DA is in My Local SID Table
2. The function associated with the DA is processed.
(Examples are as described in section 4).
3. ELSE
4. Treat the extension header as unrecognized
and process as defined in RFC8200 section 4.4.
4. SRH Functions
Segment Routing architecture, as defined in
[I-D.ietf-spring-segment-routing] defines a segment as an instruction
or, more generally, a set of instructions (function).
In this section we review two functions that may be associated to a
segment:
o End: the endpoint (End) function is the base of the source routing
paradigm. It consists of updating the DA with the next segment
and forward the packet accordingly.
o End.X: The endpoint layer-3 cross-connect function.
Other functions may be defined in other documents. There are different types of nodes that may be involved in segment
routing networks: source SR nodes originate packets with a segment in
the destination address of the IPv6 header, transit nodes that
forward packets destined to a remote segment, and segment endpoint
nodes that process a local segment in the destination address of an
IPv6 header.
4.1. Endpoint Function (End) 3.1. Source SR Node
The Endpoint function (End) is the most basic function. A Source SR Node is any node that originates an IPv6 packet with a
segment (i.e. SRv6 SID) in the destination address of the IPv6
header. The packet leaving the source SR Node may or may not contain
an SRH. This includes either:
When the endpoint node receives a packet destined to DA "S" and S is A host originating an IPv6 packet.
an entry in the My Local SID Table and the function associated with S
in that entry is "End" then the endpoint does:
1. IF SegmentsLeft > 0 THEN An SR domain ingress router encapsulating a received packet in an
2. decrement SL outer IPv6 header, followed by an optional SRH.
3. update the IPv6 DA with SRH[SL]
4. FIB lookup on updated DA
5. forward accordingly to the matched entry
6. ELSE IF SID is assigned to an interface
7. proceed to process the next header
8. ELSE
9. drop the packet
It has to be noted that:
o The End function performs the FIB lookup in the forwarding table The mechanism through which a segment in the destination address of
of the ingress interface. the IPv6 header and the Segment List in the SRH, is derived is
outside the scope of this document. For example, the Segment List
may be obtained through local SR Policy computation, local
configuration, interaction with a controller instantiating an SR
Policy, or any other mechanism.
o An SRv6-capable node MUST include the FlowLabel of the IPv6 header 3.2. Transit Node
in its hash computation for ECMP load-balancing as described in
Section 5.4.
4.2. End.X: Endpoint with Layer-3 cross-connect A transit node is any node forwarding an IPv6 packet where the
destination address of that packet is not locally configured as a
segment nor a local interface. A transit node is not required to be
capable of processing a segment nor SRH.
When the endpoint node receives a packet destined to DA "S" and S is 3.3. SR Segment Endpoint Node
an entry in the My Local SID Table and the function associated with S
in that entry is "End.X" then the endpoint does:
1. IF SegmentsLeft > 0 THEN A SR segment endpoint node is any node receiving an IPv6 packet where
2. decrement SL the destination address of that packet is locally configured as a
3. update the IPv6 DA with SRH[SL] segment or local interface.
4. forward to layer-3 adjacency bound to the SID "S"
5. ELSE
6. drop the packet
It has to be noted that: 4. Packet Processing
o If an array of layer-3 adjacencies is bound to the End.X SID, one This section describes SRv6 packet processing at the Source, Transit
entry of the array is selected based on a hash of the packet's and Segment Endpoint nodes.
header as described in Section 5.4
o An End.X function does not allow decaps. An End.X SID cannot be 4.1. Source SR Node
the last SID of an SRH and cannot be the DA of a packet without
SRH.
o The End.X function is required to express an explicit path through A Source node steers a packet into an SR Policy and the SRH is
an IP network. created as follows:
o The End.X function is the SRv6 instantiation of a Adjacency SID as Next Header and Hdr Ext Len fields are set as specified in
defined in [I-D.ietf-spring-segment-routing]. [RFC8200].
o Note that with SR-MPLS ([I-D.ietf-spring-segment-routing-mpls]), Routing Type field is set as TBD (to be allocated by IANA,
an AdjSID is typically preceded by a PrefixSID. This is unlikely suggested value 4).
in SRv6, most likely an End.X SID is globally routed address of N.
o If a node N has 30 outgoing interfaces to 30 neighbors, usually The DA of the packet is set with the value of the first segment.
the operator would explicitly instantiate 30 End.X SIDs at N: one
per layer-3 adjacency to a neighbor. Potentially, more End.X
could be explicitly defined (groups of layer-3 adjacencies to the
same neighbor or to different neighbors).
o If node N has a bundle outgoing interface I to a neighbor Q made The first element of the SRH Segment List is the ultimate segment.
of 10 member links, N may allocate up to 11 End.X local SIDs for The second element is the penultimate segment and so on.
that bundle: one for the bundle itself and then up to one for each
member link. This is the equivalent of the L2-Link Adj SID in SR-
MPLS ([I-D.ietf-isis-l2bundles]).
5. SR Nodes The Segments Left field is set to n-1 where n is the number of
elements in the SR Policy.
There are different types of nodes that may be involved in segment The Last Entry field is set to n-1 where n is the number of
routing networks: source nodes that originate packets with an SRH, elements in the SR Policy.
transit nodes that forward packets having an SRH and segment endpoint
nodes that MUST process the SRH.
5.1. Source SR Node HMAC TLV may be set according to Section 6.
A Source SR Node can be any node originating an IPv6 packet with its If the segment list contains a single segment and there is no need
IPv6 and Segment Routing Headers. This include either: for information in flag or TLV, then the SRH MAY be omitted.
A host originating an IPv6 packet. The packet is forwarded toward the packet's Destination Address
(the first segment).
An SR domain ingress router encapsulating a received packet in an 4.1.1. Reduced SRH
outer IPv6 header followed by an SRH.
The mechanism through which a Segment List is derived is outside the When a source does not require the entire SID list to be preserved in
scope of this document. As an example, the Segment List may be the SRH, a reduced SRH may be used.
obtained through:
Local path computation. A reduced SRH does not contain the first segment of the related SR
Policy (the first segment is the one already in the DA of the IPv6
header), and the Last Entry field is set to n-2 where n is the number
of elements in the SR Policy.
Local configuration. 4.2. Transit Node
Interaction with a centralized controller delivering the path. As specified in [RFC8200], the only node allowed to inspect the
Routing Extension Header (and therefore the SRH), is the node
corresponding to the DA of the packet. Any other transit node MUST
NOT inspect the underneath routing header and MUST forward the packet
toward the DA according to its IPv6 routing table.
Any other mechanism. When a SID is in the destination address of an IPv6 header of a
packet, it's routed through an IPv6 network as an IPv6 address.
SIDs, or the prefix(es) covering SIDs, and their reachability may be
distributed by means outside the scope of this document. For
example, [RFC5308] or [RFC5340] may be used to advertise a prefix
covering the SIDs on a node.
The following are the steps of the creation of the SRH: 4.3. Segment Endpoint Node
Next Header and Hdr Ext Len fields are set as specified in Without constraining the details of an implementation, the Segment
[RFC8200]. Endpoint Node creates Forwarding Information Base (FIB) entries for
its local SIDs.
Routing Type field is set as TBD (to be allocated by IANA, When an SRv6-capable node receives an IPv6 packet, it performs a
suggested value 4). longest-prefix-match lookup on the packets destination address. This
lookup can return any of the following:
The DA of the packet is set with the value of the first segment. A FIB entry that represents a locally instantiated SRv6 SID
A FIB entry that represents a local interface, not locally
instantiated as an SRv6 SID
A FIB entry that represents a non-local route
No Match
The first element of the segment list is the last segment (the 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID
final DA of the packet). The second element is the penultimate
segment and so on.
In other words, the Segment List is encoded in the reverse order This document, and section, defines a single SRv6 SID called END.
of the path. Future documents may define additional SRv6 SIDs. In which case, the
entire content of this section will be defined in that document.
The Segments Left field is set to n-1 where n is the number of If the FIB entry represents a locally instantiated SRv6 SID, process
elements in the Segment List. the next header of the IPv6 header as defined in section 4 of
[RFC8200] until the upper-layer header, or "No Next Header" is
reached.
The Last_Entry field is set to n-1 where n is the number of When an SRH is processed {
elements in the Segment List. If Segments Left is equal to zero {
Skip SRH Processing
}
Else {
If Segments Left is greater than (Last Entry+1) {
Send an ICMP Parameter Problem, Code 0, message to the
Source Address, pointing to the Segments Left field, and
discard the packet.
}
Else {
Decrement Segments Left by 1.
Copy Segment List[Segments Left] from the SRH to the
destination address of the IPv6 header.
If the IPv6 Hop Limit is less than or equal to 1 {
Send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard
the packet.
}
Else {
Decrement the Hop Limit by 1
Resubmit the packet to the IPv6 module for transmission
to the new destination.
}
}
}
}
HMAC TLV may be set according to Section 6. If the upper-layer header or No Next Header is reached {
Send an ICMP destination unreachable to
the Source Address and discard the packet.
}
If the segment list contains a single segment and there is no need 4.3.2. FIB Entry is a Local Interface
for information in flag or TLV, then the SRH MAY be omitted.
The packet is sent towards the packet's DA (the first segment). If the FIB entry represents a local interface, not locally
instantiated as an SRv6 SID, the SRH is processed as follows:
5.2. Transit Node If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet, whose type
is identified by the Next Header field in the Routing header.
As specified in [RFC8200], the only node who is allowed to inspect If Segments Left is non-zero, the node must discard the packet and
the Routing Extension Header (and therefore the SRH), is the node send an ICMP Parameter Problem, Code 0, message to the packet's
corresponding to the DA of the packet. Any other transit node MUST Source Address, pointing to the unrecognized Routing Type.
NOT inspect the underneath routing header and MUST forward the packet
towards the DA and according to the IPv6 routing table.
As a generic security measure, any service provider will block any 4.3.3. FIB Entry Is A Non-Local Route
packet destined to one of its internal routers, especially if these
packets have an extension header in it.
5.3. SR Segment Endpoint Node Processing is not changed by this document.
The SR segment endpoint node is the node whose My Local SID 4.3.4. FIB Entry Is A No Match
Table contains an entry for the DA of the packet.
The segment endpoint node executes the function bound to the SID as Processing is not changed by this document.
per the matched My Local SID entry (Section 4).
5.4. Load Balancing and ECMP 4.4. Load Balancing and ECMP
Within an SR domain, an SR source node encapsulates a packet in an Within an SR domain, an SR source node encapsulates a packet in an
outer IPv6 header for transport to an endpoint. The SR source node outer IPv6 header for transport to an endpoint. The SR source node
MUST impose a Flow Label computed based on the inner packet. The MUST impose a flow label computed based on the inner packet. The
computation of the flow label is as recommended in [RFC6438] for the computation of the flow label is as recommended in [RFC6438] for the
sending TEP. sending Tunnel End Point.
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. destination address. If flow label is not used, the transit node may
hash all packets between a pair of SR Edge nodes to the 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. Illustrations
This section provides illustrations of SRv6 packet processing at
source, transit and endpoint nodes.
5.1. Abstract Representation of an SRH
For a node k, its IPv6 address is represented as Ak, its SRv6 SID is
represented as Sk.
IPv6 headers are represented as the tuple of (source, destination).
For example, a packet with source address A1 and destination address
A2 is represented as (A1,A2). The payload of the packet is omitted.
An SR Policy is a list of segments. A list of segments is
represented as <S1,S2,S3> where S1 is the first SID to visit, S2 is
the second SID to visit and S3 is the last SID to visit.
(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
o Source Address is SA, Destination Addresses is DA, and next-header
is SRH.
o SRH with SID list <S1, S2, S3> with SegmentsLeft = SL.
o Note the difference between the <> and () symbols. <S1, S2, S3>
represents a SID list where the leftmost segment is the first
segment. Whereas, (S3, S2, S1; SL) represents the same SID list
but encoded in the SRH Segment List format where the leftmost
segment is the last segment. When referring to an SR policy in a
high-level use-case, it is simpler to use the <S1, S2, S3>
notation. When referring to an illustration of detailed behavior,
the (S3, S2, S1; SL) notation is more convenient.
At its SR Policy headend, the Segment List <S1,S2,S3> results in SRH
(S3,S2,S1; SL=2) represented fully as:
Segments Left=2
Last Entry=2
Flags=0
Tag=0
Segment List[0]=S3
Segment List[1]=S2
Segment List[2]=S1
5.2. Example Topology
The following topology is used in examples below:
+ * * * * * * * * * * * * * * * * * * * * +
* [8] [9] *
| |
* | | *
[1]----[3]--------[5]----------------[6]---------[4]---[2]
* | | *
| |
* | | *
+--------[7]-------+
* *
+ * * * * * * * SR Domain * * * * * * * +
o 3 and 4 are SR Domain edge routers
o 5, 6, and 7 are all SR Domain routers
o 8 and 9 are hosts within the SR Domain
o 1 and 2 are hosts outside the SR Domain
5.3. Source SR Node
5.3.1. Intra SR Domain Packet
When host 8 sends a packet to host 9 via an SR Policy <S7,A9> the
packet is
P1: (A8,S7)(A9,S7; SL=1)
5.3.1.1. Reduced Variant
When host 8 sends a packet to host 9 via an SR Policy <S7,A9> and it
wants to use a reduced SRH, the packet is
P2: (A8,S7)(A9; SL=1)
5.3.2. Transit Packet Through SR Domain
When host 1 sends a packet to host 2, the packet is
P3: (A1,A2)
The SR Domain ingress router 3 receives P3 and steers it to SR Domain
egress router 4 via an SR Policy <S7, S4>. Router 3 encapsulates the
received packet P3 in an outer header with an SRH. The packet is
P4: (A3, S7)(S4, S7; SL=1)(A1, A2)
If the SR Policy contains only one segment (the egress router 4), the
ingress Router 3 encapsulates P3 into an outer header (A3, S4). The
packet is
P5: (A3, S4)(A1, A2)
5.3.2.1. Reduced Variant
The SR Domain ingress router 3 receives P3 and steers it to SR Domain
egress router 4 via an SR Policy <S7, S4>. If router 3 wants to use
a reduced SRH, Router 3 encapsulates the received packet P3 in an
outer header with a reduced SRH. The packet is
P6: (A3, S7)(S4; SL=1)(A1, A2)
5.4. Transit Node
Nodes 5 acts as transit nodes for packet P1, and sends packet
P1: (A8,S7)(A9,S7;SL=1)
on the interface toward node 7.
5.5. SR End Node
Node 7 receives packet P1 and, using the logic in section 4.3.1,
sends packet
P7: (A8,A9)(A9,S7; SL=0)
on the interface toward router 6.
6. Security Considerations 6. Security Considerations
This section analyzes the security threat model, the security issues This section analyzes the security threat model, the security issues
and proposed solutions related to the new Segment Routing Header. and proposed solutions related to the new Segment Routing Header.
The Segment Routing Header (SRH) is simply another type of the The Segment Routing Header (SRH) is simply another type of the
routing header as described in [RFC8200] and is: routing header as described in [RFC8200] and is:
o Added by an SR edge router when entering the segment routing o Added by an SR edge router when entering the segment routing
domain or by the originating host itself. The source host can domain or by the originating host itself. The source host can
even be outside the SR domain; even be outside the SR domain;
o inspected and acted upon when reaching the destination address of o inspected and acted upon when reaching the destination address of
the IP header per [RFC8200]. the IP header per [RFC8200].
Per [RFC8200], routers on the path that simply forward an IPv6 packet Per [RFC8200], routers on the path that simply forward an IPv6 packet
(i.e. the IPv6 destination address is none of theirs) will never (i.e. the IPv6 destination address is none of theirs) will never
inspect and process the content of the SRH. Routers whose one inspect and process the content of the SRH. Routers whose FIB
interface IPv6 address equals the destination address field of the contains a locally instantiated SRv6 SID equal to the destination
IPv6 packet MUST parse the SRH and, if supported and if the local address field of the IPv6 packet MUST parse the SRH and, if supported
configuration allows it, MUST act accordingly to the SRH content. and if the local configuration allows it, MUST act accordingly to the
SRH content.
As specified in [RFC8200], the default behavior of a non SR-capable As specified in [RFC8200], the default behavior of a non SR-capable
router upon receipt of an IPv6 packet with SRH destined to an address router upon receipt of an IPv6 packet with SRH destined to an address
of its, is to: of its, is to:
o ignore the SRH completely if the Segment Left field is 0 and o ignore the SRH completely if the Segment Left field is 0 and
proceed to process the next header in the IPv6 packet; proceed to process the next header in the IPv6 packet;
o discard the IPv6 packet if Segment Left field is greater than 0, o discard the IPv6 packet if Segment Left field is greater than 0,
it MAY send a Parameter Problem ICMP message back to the Source it MAY send a Parameter Problem ICMP message back to the Source
skipping to change at page 17, line 16 skipping to change at page 18, line 27
applicable. applicable.
6.1.3. Service stealing threat 6.1.3. Service stealing threat
Segment routing is used for added value services, there is also a Segment routing is used for added value services, there is also a
need to prevent non-participating nodes to use those services; this need to prevent non-participating nodes to use those services; this
is called 'service stealing prevention'. is called 'service stealing prevention'.
6.1.4. Topology disclosure 6.1.4. Topology disclosure
The SRH may also contains IPv6 addresses of some intermediate SR- The SRH may also contains SIDs of some intermediate SR-nodes in the
nodes in the path towards the destination, this obviously reveals path towards the destination, this obviously reveals those addresses
those addresses to the potentially hostile attackers if those to the potentially hostile attackers if those attackers are able to
attackers are able to intercept packets containing SRH. On the other intercept packets containing SRH. On the other hand, if the attacker
hand, if the attacker can do a traceroute whose probes will be can do a traceroute whose probes will be forwarded along the SR
forwarded along the SR path, then there is little learned by Policy, then there is little learned by intercepting the SRH itself.
intercepting the SRH itself.
6.1.5. ICMP Generation 6.1.5. ICMP Generation
Per Section 4.4 of [RFC8200], when destination nodes (i.e. where the Per Section 4.4 of [RFC8200], when destination nodes (i.e. where the
destination address is one of theirs) receive a Routing Header with destination address is one of theirs) receive a Routing Header with
unsupported Routing Type, the required behavior is: unsupported Routing Type, the required behavior is:
o If Segments Left is zero, the node must ignore the Routing header o If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet. and proceed to process the next header in the packet.
skipping to change at page 20, line 51 skipping to change at page 22, line 17
6.3.1. Nodes within the SR domain 6.3.1. Nodes within the SR domain
An SR domain is defined as a set of interconnected routers where all An SR domain is defined as a set of interconnected routers where all
routers at the perimeter are configured to add and act on SRH. Some routers at the perimeter are configured to add and act on SRH. Some
routers inside the SR domain can also act on SRH or simply forward routers inside the SR domain can also act on SRH or simply forward
IPv6 packets. IPv6 packets.
The routers inside an SR domain can be trusted to generate SRH and to The routers inside an SR domain can be trusted to generate SRH and to
process SRH received on interfaces that are part of the SR domain. process SRH received on interfaces that are part of the SR domain.
These nodes MUST drop all SRH packets received on an interface that These nodes MUST drop all SRH packets received on an interface that
is not part of the SR domain and containing an SRH whose HMAC field is not part of the SR domain, destined to a locally instantiated SID,
cannot be validated by local policies. This includes obviously and containing an SRH whose HMAC field cannot be validated by local
packet with an SRH generated by a non-cooperative SR domain. policies. This includes obviously packet with an SRH generated by a
non-cooperative SR domain.
If the validation fails, then these packets MUST be dropped, ICMP If the validation fails, then these packets MUST be dropped, ICMP
error messages (parameter problem) SHOULD be generated (but rate error messages (parameter problem) SHOULD be generated (but rate
limited) and SHOULD be logged. limited) and SHOULD be logged.
6.3.2. Nodes outside of the SR domain 6.3.2. Nodes outside of the SR domain
Nodes outside of the SR domain cannot be trusted for physical Nodes outside of the SR domain cannot be trusted for physical
security; hence, they need to request by some trusted means (outside security; hence, they need to request by some trusted means (outside
the scope of this document) a complete SRH for each new connection the scope of this document) a complete SRH for each new connection
(i.e. new destination address). The received SRH MUST include an (i.e. new destination address). The received SRH MUST include an
HMAC TLV which is computed correctly (see Section 6.2). HMAC TLV which is computed correctly (see Section 6.2).
When an outside node sends a packet with an SRH and towards an SR When an outside node sends a packet with an SRH and towards an SR
domain ingress node, the packet MUST contain the HMAC TLV (with a domain ingress node, the packet MUST contain the HMAC TLV (with a
Key-id and HMAC fields) and the the destination address MUST be an Key-id and HMAC fields) and the the destination address MUST be an
address of an SR domain ingress node . address of an SR domain ingress node .
The ingress SR router, i.e., the router with an interface address The ingress SR router, i.e., the router with a SID equal to the
equal to the destination address, MUST verify the HMAC TLV. destination address, MUST verify the HMAC TLV.
If the validation is successful, then the packet is simply forwarded If the validation is successful, then the packet is simply forwarded
as usual for an SR packet. As long as the packet travels within the as usual for an SR packet. As long as the packet travels within the
SR domain, no further HMAC check needs to be done. Subsequent SR domain, no further HMAC check needs to be done. Subsequent
routers in the SR domain MAY verify the HMAC TLV when they process routers in the SR domain MAY verify the HMAC TLV when they process
the SRH (i.e. when they are the destination). the SRH (i.e. when they are the destination).
If the validation fails, then this packet MUST be dropped, an ICMP If the validation fails, then this packet MUST be dropped, an ICMP
error message (parameter problem) SHOULD be generated (but rate error message (parameter problem) SHOULD be generated (but rate
limited) and SHOULD be logged. limited) and SHOULD be logged.
skipping to change at page 22, line 4 skipping to change at page 23, line 20
knowledge on the topology. This is especially applicable when the knowledge on the topology. This is especially applicable when the
path between the source node and the first SR domain ingress router path between the source node and the first SR domain ingress router
is on the public Internet. is on the public Internet.
The first remark is to state that 'security by obscurity' is never The first remark is to state that 'security by obscurity' is never
enough; in other words, the security policy of the SR domain MUST enough; in other words, the security policy of the SR domain MUST
assume that the internal topology and addressing is known by the assume that the internal topology and addressing is known by the
attacker. A simple traceroute will also give the same information attacker. A simple traceroute will also give the same information
(with even more information as all intermediate nodes between SID (with even more information as all intermediate nodes between SID
will also be exposed). IPsec Encapsulating Security Payload will also be exposed). IPsec Encapsulating Security Payload
[RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP
header must appear after any routing header (including SRH). header must appear after any routing header (including SRH).
To prevent a user to leverage the gained knowledge by intercepting To prevent a user to leverage the gained knowledge by intercepting
SRH, it it recommended to apply an infrastructure Access Control List SRH, it it recommended to apply an infrastructure Access Control List
(iACL) at the edge of the SR domain. This iACL will drop all packets (iACL) at the edge of the SR domain. This iACL will drop all packets
from outside the SR-domain whose destination is any address of any from outside the SR-domain whose destination is any address of any
router inside the domain. This security policy should be tuned for router interface or SID inside the domain. This security policy
local operations. should be tuned for local operations.
6.3.4. Impact of BCP-38 6.3.4. Impact of BCP-38
BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks
whether the source address of packets received on an interface is whether the source address of packets received on an interface is
valid for this interface. The use of loose source routing such as valid for this interface. The use of loose source routing such as
SRH forces packets to follow a path which differs from the expected SRH forces packets to follow a path which differs from the expected
routing. Therefore, if BCP-38 was implemented in all routers inside routing. Therefore, if BCP-38 was implemented in all routers inside
the SR domain, then SR packets could be received by an interface the SR domain, then SR packets could be received by an interface
which is not expected one and the packets could be dropped. which is not expected one and the packets could be dropped.
skipping to change at page 23, line 38 skipping to change at page 24, line 52
8. Implementation Status 8. 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.
8.1. Linux 8.1. Linux
Name: Linux Kernel v4.14 Name: Linux Kernel v4.14
Status: Production Status: Production
Implementation: adds SRH, performs END and END.X processing, supports Implementation: adds SRH, performs END processing, supports HMAC TLV
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]
8.2. Cisco Systems 8.2. Cisco Systems
Name: IOS XR and IOS XE Name: IOS XR and IOS XE
Status: Pre-production Status: Pre-production
Implementation: adds SRH, performs END and END.X processing, no TLV Implementation: adds SRH, performs END processing, no TLV processing
processing
Details: [I-D.filsfils-spring-srv6-interop] Details: [I-D.filsfils-spring-srv6-interop]
8.3. FD.io 8.3. FD.io
Name: VPP/Segment Routing for IPv6 Name: VPP/Segment Routing for IPv6
Status: Production Status: Production
Implementation: adds SRH, performs END and END.X processing, no TLV Implementation: adds SRH, performs END processing, no TLV processing
processing
Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and
[I-D.filsfils-spring-srv6-interop] [I-D.filsfils-spring-srv6-interop]
8.4. Barefoot 8.4. Barefoot
Name: Barefoot Networks Tofino NPU Name: Barefoot Networks Tofino NPU
Status: Prototype Status: Prototype
Implementation: performs END and END.X processing, no TLV processing Implementation: performs END processing, no TLV processing
Details: [I-D.filsfils-spring-srv6-interop] Details: [I-D.filsfils-spring-srv6-interop]
8.5. Juniper 8.5. Juniper
Name: Juniper Networks Trio and vTrio NPU's Name: Juniper Networks Trio and vTrio NPU's
Status: Prototype & Experimental Status: Prototype & Experimental
Implementation: SRH insertion mode, Process SID where SID is an Implementation: SRH insertion mode, Process SID where SID is an
skipping to change at page 24, line 48 skipping to change at page 26, line 10
Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung, Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung,
Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun,
Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre Dirk 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.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Ole Troan, Bob Hinden, Fred Baker, The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica,
Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, and David Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal,
Lebrun for their comments to this document. and David Lebrun for their comments to this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[FIPS180-4] [FIPS180-4]
National Institute of Standards and Technology, "FIPS National Institute of Standards and Technology, "FIPS
180-4 Secure Hash Standard (SHS)", March 2012, 180-4 Secure Hash Standard (SHS)", March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
skipping to change at page 25, line 39 skipping to change at page 26, line 48
[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>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R.,
Ed., and M. Townsley, "Use Cases for IPv6 Source Packet
Routing in Networking (SPRING)", RFC 8354,
DOI 10.17487/RFC8354, March 2018,
<https://www.rfc-editor.org/info/rfc8354>.
11.2. Informative References 11.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-00 (work in progress), March 2018. srv6-interop-00 (work in progress), March 2018.
[I-D.filsfils-spring-srv6-network-programming] [I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and
M. Sharif, "SRv6 Network Programming", draft-filsfils- M. Sharif, "SRv6 Network Programming", draft-filsfils-
spring-srv6-network-programming-04 (work in progress), spring-srv6-network-programming-04 (work in progress),
March 2018. March 2018.
[I-D.ietf-isis-l2bundles]
Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
E. Aries, "Advertising L2 Bundle Member Link Attributes in
IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
May 2017.
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura,
"IS-IS Extensions for Segment Routing", draft-ietf-isis-
segment-routing-extensions-15 (work in progress), December
2017.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Filsfils, C., Previdi, S., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-11 (work in progress), January
2018.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-13 data plane", draft-ietf-spring-segment-routing-mpls-13
(work in progress), April 2018. (work in progress), April 2018.
[RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
Zappala, "Source Demand Routing: Packet Format and
Forwarding Specification (Version 1)", RFC 1940,
DOI 10.17487/RFC1940, May 1996,
<https://www.rfc-editor.org/info/rfc1940>.
[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>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", RFC 4942, Co-existence Security Considerations", RFC 4942,
DOI 10.17487/RFC4942, September 2007, DOI 10.17487/RFC4942, September 2007,
<https://www.rfc-editor.org/info/rfc4942>. <https://www.rfc-editor.org/info/rfc4942>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
 End of changes. 95 change blocks. 
390 lines changed or deleted 406 lines changed or added

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