draft-ietf-6man-segment-routing-header-23.txt   draft-ietf-6man-segment-routing-header-24.txt 
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft D. Dukes, Ed. Internet-Draft D. Dukes, Ed.
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: March 18, 2020 S. Previdi Expires: April 5, 2020 S. Previdi
Huawei Huawei
J. Leddy J. Leddy
Individual Individual
S. Matsushima S. Matsushima
Softbank Softbank
D. Voyer D. Voyer
Bell Canada Bell Canada
September 15, 2019 October 3, 2019
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-23 draft-ietf-6man-segment-routing-header-24
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 called the Segment Routing Header. type of Routing Extension Header called the Segment Routing Header.
This document describes the Segment Routing Header and how it is used This document describes the Segment Routing Header and how it is used
by Segment Routing capable nodes. by Segment Routing capable nodes.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 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 March 18, 2020. This Internet-Draft will expire on April 5, 2020.
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 25 skipping to change at page 2, line 25
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Segment Routing Header . . . . . . . . . . . . . . . . . . . 4 2. Segment Routing Header . . . . . . . . . . . . . . . . . . . 4
2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 8 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 8
2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 9
3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12
3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12
3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 13
4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 13
4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 14 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 14
4.3.1. FIB Entry Is Locally Instantiated SRv6 SID . . . . . 14 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID . . . . . 14
4.3.2. FIB Entry Is A Local Interface . . . . . . . . . . . 16 4.3.2. FIB Entry Is A Local Interface . . . . . . . . . . . 16
4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 17 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 17
4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 17 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 17
5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 17 5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 17
5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 17 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
skipping to change at page 2, line 47 skipping to change at page 2, line 47
5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 19 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 19
5.4. ICMP Error Processing . . . . . . . . . . . . . . . . . . 19 5.4. ICMP Error Processing . . . . . . . . . . . . . . . . . . 19
5.5. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 19 5.5. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 19
5.6. Other Deployments . . . . . . . . . . . . . . . . . . . . 20 5.6. Other Deployments . . . . . . . . . . . . . . . . . . . . 20
6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Abstract Representation of an SRH . . . . . . . . . . . . 20 6.1. Abstract Representation of an SRH . . . . . . . . . . . . 20
6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 21 6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 21
6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 22 6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 22
6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 22 6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 22
6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 22 6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 22
6.3.3. Inter SR Domain Packet - Internal to External . . . . 22 6.3.3. Inter SR Domain Packet - Internal to External . . . . 23
6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 23 6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 23
6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 23 6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 23
6.6. Delegation of Function with HMAC Verification . . . . . . 23 6.6. Delegation of Function with HMAC Verification . . . . . . 23
6.6.1. SID List Verification . . . . . . . . . . . . . . . . 23 6.6.1. SID List Verification . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 24 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 25
7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 25
7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 25 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 25
7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 25 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 26
7.5. Applicability of AH . . . . . . . . . . . . . . . . . . . 26 7.5. Applicability of AH . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8.1. Segment Routing Header Flags Register . . . . . . . . . . 27 8.1. Segment Routing Header Flags Register . . . . . . . . . . 27
8.2. Segment Routing Header TLVs Register . . . . . . . . . . 27 8.2. Segment Routing Header TLVs Register . . . . . . . . . . 27
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 28 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 27
9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 28
9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 28 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 28
9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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 Header called the Segment Routing Header. This type of Routing Header called the Segment Routing Header. This
document describes the Segment Routing Header and how it is used by document describes the Segment Routing Header and how it is used by
Segment Routing capable nodes. Segment 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.
The encoding of IPv6 segments in the Segment Routing Header is The encoding of IPv6 segments in the Segment Routing Header is
defined in this document. defined in this document.
This document uses the terms Segment Routing, SR Domain, SRv6, This document uses the terms Segment Routing, SR Domain, SRv6,
Segment ID (SID), SRv6 SID, Active Segment, and SR Policy as defined Segment ID (SID), SRv6 SID, Active Segment, and SR Policy as defined
in [RFC8402]. in [RFC8402].
1.1. Requirements Language 1.1. Requirements Language
skipping to change at page 5, line 21 skipping to change at page 5, line 21
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
U: Unused and for future use. MUST be 0 on transmission and U: Unused and for future use. MUST be 0 on transmission and
ignored on receipt. ignored on receipt.
o Tag: tag a packet as part of a class or group of packets, e.g., o Tag: tag a packet as part of a class or group of packets, e.g.,
packets sharing the same set of properties. When tag is not used packets sharing the same set of properties. When tag is not used
at source it MUST be set to zero on transmission. When tag is not at source it MUST be set to zero on transmission. When tag is not
used during SRH Processing it SHOULD be ignored. Tag is not used used during SRH Processing it SHOULD be ignored. Tag is not used
when processing the SID defined in Section 4.3.1. It may be used when processing the SID defined in Section 4.3.1. It may be used
when processing other SIDs which are not defined in this document. when processing other SIDs that are not defined in this document.
The allocation and use of tag is outside the scope of this The allocation and use of tag is outside the scope of this
document. document.
o Segment List[n]: 128 bit IPv6 addresses representing the nth o Segment List[n]: 128 bit IPv6 addresses representing the nth
segment in the Segment List. The Segment List is encoded starting segment in the Segment List. The Segment List is encoded starting
from the last segment of the SR Policy. I.e., the first element from the last segment of the SR Policy. I.e., the first element
of the segment list (Segment List [0]) contains the last segment of the segment list (Segment List [0]) contains the last segment
of the SR Policy, the second element contains the penultimate of the SR Policy, the second element contains the penultimate
segment of the SR Policy and so on. segment of the SR Policy and so on.
o Type Length Value (TLV) are described in Section 2.1. o Type Length Value (TLV) are described in Section 2.1.
In the SRH, the Next Header, Hdr Ext Len, Routing Type, and Segments In the SRH, the Next Header, Hdr Ext Len, Routing Type, and Segments
Left fields are defined in Section 4.4 of [RFC8200]. Based on the Left fields are defined in Section 4.4 of [RFC8200]. Based on the
constraints in that section Next Header, Header Ext Len, and Routing constraints in that section, Next Header, Header Ext Len, and Routing
Type are not mutable while Segments Left is mutable. Type are not mutable while Segments Left is mutable.
The mutability of the TLV value is defined by the most significant The mutability of the TLV value is defined by the most significant
bit in the type, as specified in Section 2.1. bit in the type, as specified in Section 2.1.
Section 4.3 defines the mutability of the remaining fields in the SRH Section 4.3 defines the mutability of the remaining fields in the SRH
(Flags, Tag, Segment List) in the context of the SID defined in this (Flags, Tag, Segment List) in the context of the SID defined in this
document. document.
New SIDs defined in the future MUST specify the mutability properties New SIDs defined in the future MUST specify the mutability properties
skipping to change at page 6, line 21 skipping to change at page 6, line 21
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, however an implementation adding is optional for any implementation, however, an implementation adding
or parsing TLVs MUST support PAD TLVs. Other documents may define 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 is greater than (Last TLVs are present when the Hdr Ext Len is greater than (Last
Entry+1)*2. Entry+1)*2.
While processing TLVs at a segment endpoint, TLVs MUST be fully While processing TLVs at a segment endpoint, TLVs MUST be fully
contained within the SRH as determined by the Hdr Ext Len. Detection contained within the SRH as determined by the Hdr Ext Len. Detection
of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an
ICMP Parameter Problem, Code 0, message to the Source Address, ICMP Parameter Problem, Code 0, message to the Source Address,
pointing to the Hdr Ext Len field of the SRH, and the packet being pointing to the Hdr Ext Len field of the SRH, and the packet being
discarded. discarded.
An implementation MAY limit the number and/or length of TLVs it An implementation MAY limit the number and/or length of TLVs it
processes based on local configuration. It MAY: processes based on local configuration. It MAY:
o Limit the number of consecutive Pad1 (Section 2.1.1.1) options to o Limit the number of consecutive Pad1 (Section 2.1.1.1) options to
1, if padding of more than one byte is required then PadN 1. If padding of more than one byte is required, then PadN
(Section 2.1.1.2) should be used. (Section 2.1.1.2) should be used.
o Limit the length in PadN to 5. o Limit the length in PadN to 5.
o Limit the maximum number of non-Pad TLVs to be processed. o Limit the maximum number of non-Pad TLVs to be processed.
o Limit the maximum length of all TLVs to be processed. o Limit the maximum length of all TLVs to be processed.
The implementation MAY stop processing additional TLVs in the SRH The implementation MAY stop processing additional TLVs in the SRH
when these configured limits are exceeded. when these configured limits are exceeded.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
| Type | Length | Variable length data | Type | Length | Variable length data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
Type: An 8 bit value. Unrecognized Types MUST be ignored on receipt. Type: An 8 bit codepoint from Segment Routing Header TLVs Register
TBD IANA Reference. Unrecognized Types MUST be ignored on receipt.
Length: The length of the Variable length data. Length: The length of the Variable length data in bytes.
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) entries contain OPTIONAL information that may
by the node identified in the Destination Address (DA) of the packet. be used 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 codepoint
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.
The highest-order bit of the TLV type specifies whether or not the The highest-order bit of the TLV type (bit 0) specifies whether or
TLV data of that type can change en route to the packet's final not the TLV data of that type can change en route to the packet's
destination: final destination:
0: TLV data does not change en route 0: TLV data does not change en route
1: TLV data does 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.
skipping to change at page 8, line 15 skipping to change at page 8, line 15
2.1.1. Padding TLVs 2.1.1. Padding TLVs
There are two types of Padding TLVs, pad1 and padN, the following There are two types of Padding TLVs, pad1 and padN, the following
applies to both: applies to both:
Padding TLVs are used for meeting the alignment requirement of the Padding TLVs are used for meeting the alignment requirement of the
subsequent TLVs. subsequent TLVs.
Padding TLVs are used to pad the SRH to a multiple of 8 octets. Padding TLVs are used to pad the SRH to a multiple of 8 octets.
Padding TLVs are used for alignment.
Padding TLVs are ignored by a node processing the SRH TLV. Padding TLVs are ignored by a node processing the SRH TLV.
Multiple Padding TLVs MAY be used in one SRH Multiple Padding TLVs MAY be used in one SRH
2.1.1.1. PAD1 2.1.1.1. PAD1
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 0) Type: to be assigned by IANA (Suggested value 0)
A single Pad1 TLV MUST be used when a single byte of padding is A single Pad1 TLV MUST be used when a single byte of padding is
required. If more than one byte of padding is required a Pad1 TLV required. A Pad1 TLV MUST NOT be used if more than one consecutive
MUST NOT be used, the PadN TLV MUST be used. byte of padding is required.
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 4). Type: to be assigned by IANA (suggested value 4).
Length: 0 to 5 Length: 0 to 5
Padding: Length octets of padding. Padding bits have no
semantics. They MUST be set to 0 on transmission and ignored on Padding: Length octets of padding. Padding bits have no semantic.
receipt. They MUST be set to 0 on transmission and 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.
2.1.2. HMAC TLV 2.1.2. HMAC TLV
Alignment requirement: 8n Alignment requirement: 8n
The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL
and has the following format: and has the following format:
skipping to change at page 9, line 44 skipping to change at page 9, line 41
o Length: 38. o Length: 38.
o RESERVED: 2 octets. MUST be 0 on transmission and ignored on o RESERVED: 2 octets. MUST be 0 on transmission and ignored on
receipt. receipt.
o HMAC Key ID: A 4 octet opaque number which uniquely identifies the o HMAC Key ID: A 4 octet opaque number which uniquely identifies the
pre-shared key and algorithm used to generate the HMAC. pre-shared key and algorithm used to generate the HMAC.
o HMAC: 32 octets of keyed HMAC. o HMAC: 32 octets of keyed HMAC.
The HMAC TLV is used to verify the source of a packet is permitted to The HMAC TLV is used to verify that the SRH applied to a packet was
use the current segment in the destination address of the packet, and selected by an authorized party, and to ensure that the segment list
ensure the segment list is not modified in transit. is not modified after generation. This also allows for verification
that the current segment (by virtue of being in the authorized
segment list) is authorized for use. The SR Domain ensures the
source node is permitted to use the source address in the packet via
ingress filtering mechanisms as defined in BCP 84 [RFC3704], or other
strategies as appropriate.
2.1.2.1. HMAC Generation and Verification 2.1.2.1. HMAC Generation and Verification
Local configuration determines when to check for an HMAC and Local configuration determines when to check for an HMAC and
potentially indicates what the HMAC protects, and a requirement on potentially indicates what the HMAC protects, and a requirement on
where the HMAC TLV must appear (e.g. first TLV), and whether or not where the HMAC TLV must appear (e.g. first TLV), and whether or not
to verify the destination address is equal to the current segment. to verify the destination address is equal to the current segment.
This local configuration is outside the scope of this document. It This local configuration is outside the scope of this document. It
may be based on the active segment at an SR Segment endpoint node, may be based on the active segment at an SR Segment endpoint node,
the result of an ACL that considers incoming interface, HMAC Key ID, the result of an ACL that considers incoming interface, HMAC Key ID,
skipping to change at page 11, line 5 skipping to change at page 11, line 5
* SRH: all addresses in the Segment List (variable octets) * SRH: all addresses in the Segment List (variable octets)
The HMAC digest is truncated to 32 octets and placed in the HMAC The HMAC digest is truncated to 32 octets and placed in the HMAC
field of the HMAC TLV. field of the HMAC TLV.
For HMAC algorithms producing digests less than 32 octets, the digest For HMAC algorithms producing digests less than 32 octets, the digest
is placed in the lowest order octets of the HMAC field. Remaining is placed in the lowest order octets of the HMAC field. Remaining
octets MUST be set to zero. octets MUST be set to zero.
If HMAC verification is successful, the packet is forwarded to the If HMAC verification is successful, processing proceeds as normal.
next segment.
If HMAC verification fails, an ICMP error message (parameter problem, If HMAC verification fails, an ICMP error message (parameter problem,
error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate
limited) and SHOULD be logged and the packet discarded. limited) and SHOULD be logged and the packet discarded.
2.1.2.2. HMAC Pre-Shared Key Algorithm 2.1.2.2. HMAC Pre-Shared Key Algorithm
The HMAC Key ID field allows for the simultaneous existence of The HMAC Key ID field allows for the simultaneous existence of
several hash algorithms (SHA-256, SHA3-256 ... or future ones) as several hash algorithms (SHA-256, SHA3-256 ... or future ones) as
well as pre-shared keys. well as pre-shared keys.
The HMAC Key ID field is opaque, i.e., it has neither syntax nor The HMAC Key ID field is opaque, i.e., it has neither syntax nor
semantic except as an identifier of the right combination of pre- semantic except as an identifier of the right combination of pre-
shared key and hash algorithm, and except that a value of 0 means shared key and hash algorithm.
that there is no HMAC field.
At the HMAC TLV verification node the Key ID uniquely identifies the At the HMAC TLV gernerating and verification nodes, the Key ID
pre-shared key and HMAC algorithm. uniquely identifies the pre-shared key and HMAC algorithm.
At the HMAC TLV generating node the Key ID and destination address At the HMAC TLV generating node, the Text for the HMAC computation is
uniquely identify the pre-shared key and HMAC algorithm. Utilizing set to the IPv6 header fields and SRH fields as they would appear at
the destination address with the Key ID allows for overlapping key the verification node, not necessarily the same as the source node
IDs amongst different HMAC verification nodes. The Text for the HMAC sending a packet with the HMAC TLV.
computation is set to the IPv6 header fields and SRH fields as they
would appear at the verification node, not necessarily the same as
the source node sending a packet with the HMAC TLV.
Pre-shared key roll-over is supported by having two key IDs in use Pre-shared key roll-over is supported by having two key IDs in use
while the HMAC TLV generating node and verifying node converge to a while the HMAC TLV generating node and verifying node converge to a
new key. new key.
The HMAC TLV generating node may need to revoke an SRH for which it
previously generated an HMAC. Revocation is achieved by allocating a
new key and key ID, then rolling over the key ID associated with the
SRH to be revoked. The HMAC TLV verifying node drops packets with
the revoked SRH.
An implementation supporting HMAC can support multiple hash An implementation supporting HMAC can support multiple hash
functions. An implementation supporting HMAC MUST implement SHA-2 functions. An implementation supporting HMAC MUST implement SHA-2
[FIPS180-4] in its SHA-256 variant. [FIPS180-4] in its SHA-256 variant.
The selection of pre-shared key and algorithm, and their distribution The selection of pre-shared key and algorithm, and their distribution
is outside the scope of this document, some options may include: is outside the scope of this document. Some options may include:
o in the configuration of the HMAC generating or verifying nodes, o in the configuration of the HMAC generating or verifying nodes,
either by static configuration or any SDN oriented approach either by static configuration or any SDN oriented approach
o dynamically using a trusted key distribution protocol such as o dynamically using a trusted key distribution protocol such as
[RFC6407] [RFC6407]
While key management is outside the scope of this document, the
recommendations of BCP 107 [RFC4107] should be considered when
choosing the key management system.
3. SR Nodes 3. SR Nodes
There are different types of nodes that may be involved in segment There are different types of nodes that may be involved in segment
routing networks: source SR nodes originate packets with a segment in routing networks: source SR nodes originate packets with a segment in
the destination address of the IPv6 header, transit nodes that the destination address of the IPv6 header, transit nodes that
forward packets destined to a remote segment, and SR segment endpoint forward packets destined to a remote segment, and SR segment endpoint
nodes that process a local segment in the destination address of an nodes that process a local segment in the destination address of an
IPv6 header. IPv6 header.
3.1. Source SR Node 3.1. Source SR Node
skipping to change at page 13, line 4 skipping to change at page 13, line 9
4. Packet Processing 4. Packet Processing
This section describes SRv6 packet processing at the SR source, This section describes SRv6 packet processing at the SR source,
Transit and SR segment endpoint nodes. Transit and SR segment endpoint nodes.
4.1. Source SR Node 4.1. Source SR Node
A Source node steers a packet into an SR Policy. If the SR Policy A Source node steers a packet into an SR Policy. If the SR Policy
results in a segment list containing a single segment, and there is results in a segment list containing a single segment, and there is
no need to add information to SRH flag or TLV, the DA is set to the no need to add information to the SRH flag or to add TLV, the DA is
single segment list entry and the SRH MAY be omitted. set to the single segment list entry and the SRH MAY be omitted.
When needed, the SRH is created as follows: When needed, the SRH is created as follows:
Next Header and Hdr Ext Len fields are set as specified in Next Header and Hdr Ext Len fields are set as specified in
[RFC8200]. [RFC8200].
Routing Type field is set as TBD (to be allocated by IANA, Routing Type field is set as TBD (to be allocated by IANA,
suggested value 4). suggested value 4).
The DA of the packet is set with the value of the first segment. The DA of the packet is set with the value of the first segment.
The first element of the SRH Segment List is the ultimate segment. The first element of the SRH Segment List is the ultimate segment.
The second element is the penultimate segment and so on. The second element is the penultimate segment, and so on.
The Segments Left field is set to n-1 where n is the number of The Segments Left field is set to n-1 where n is the number of
elements in the SR Policy. elements in the SR Policy.
The Last Entry field is set to n-1 where n is the number of The Last Entry field is set to n-1 where n is the number of
elements in the SR Policy. elements in the SR Policy.
HMAC TLV may be set according to Section 2.1.2. TLVs (including HMAC) may be set according to their specification.
The packet is forwarded toward the packet's Destination Address The packet is forwarded toward the packet's Destination Address
(the first segment). (the first segment).
4.1.1. Reduced SRH 4.1.1. Reduced SRH
When a source does not require the entire SID list to be preserved in When a source does not require the entire SID list to be preserved in
the SRH, a reduced SRH may be used. the SRH, a reduced SRH may be used.
A reduced SRH does not contain the first segment of the related SR A reduced SRH does not contain the first segment of the related SR
skipping to change at page 17, line 31 skipping to change at page 17, line 31
o securing the SR Domain from external attempt to use its SIDs o securing the SR Domain from external attempt to use its SIDs
o SR Domain as a single system with delegation between components o SR Domain as a single system with delegation between components
o handling packets of the SR Domain o handling packets of the SR Domain
5.1. Securing the SR Domain 5.1. Securing the SR Domain
Nodes outside the SR Domain are not trusted: they cannot directly use Nodes outside the SR Domain are not trusted: they cannot directly use
the SID's of the domain. This is enforced by two levels of access the SIDs of the domain. This is enforced by two levels of access
control lists: control lists:
1. Any packet entering the SR Domain and destined to a SID within 1. Any packet entering the SR Domain and destined to a SID within
the SR Domain is dropped. This may be realized with the the SR Domain is dropped. This may be realized with the
following logic, other methods with equivalent outcome are following logic. Other methods with equivalent outcome are
considered compliant: considered compliant:
* allocate all the SID's from a block S/s * allocate all the SID's from a block S/s
* configure each external interface of each edge node of the * configure each external interface of each edge node of the
domain with an inbound infrastructure access list (IACL) which domain with an inbound infrastructure access list (IACL) which
drops any incoming packet with a destination address in S/s drops any incoming packet with a destination address in S/s
* Failure to implement this method of ingress filtering exposes * Failure to implement this method of ingress filtering exposes
the SR Domain to source routing attacks as described and the SR Domain to source routing attacks as described and
referenced in [RFC5095] referenced in [RFC5095]
2. The distributed protection in #1 is complemented with per node 2. The distributed protection in #1 is complemented with per node
protection, dropping packets to SIDs from source addresses protection, dropping packets to SIDs from source addresses
outside the SR Domain. This may be realized with the following outside the SR Domain. This may be realized with the following
logic, other methods with equivalent outcome are considered logic. Other methods with equivalent outcome are considered
compliant: compliant:
* assign all interface addresses from prefix A/a * assign all interface addresses from prefix A/a
* at node k, all SIDs local to k are assigned from prefix Sk/sk * at node k, all SIDs local to k are assigned from prefix Sk/sk
* configure each internal interface of each SR node k in the SR * configure each internal interface of each SR node k in the SR
Domain with an inbound IACL which drops any incoming packet Domain with an inbound IACL which drops any incoming packet
with a destination address in Sk/sk if the source address is with a destination address in Sk/sk if the source address is
not in A/a. not in A/a.
skipping to change at page 19, line 13 skipping to change at page 19, line 13
segment list is not modified while traversing the SR Domain. segment list is not modified while traversing the SR Domain.
5.3. MTU Considerations 5.3. MTU Considerations
An SR Domain ingress edge node encapsulates packets traversing the SR An SR Domain ingress edge node encapsulates packets traversing the SR
Domain, and needs to consider the MTU of the SR Domain. Within the Domain, and needs to consider the MTU of the SR Domain. Within the
SR Domain, well known mitigation techniques are RECOMMENDED, such as SR Domain, well known mitigation techniques are RECOMMENDED, such as
deploying a greater MTU value within the SR Domain than at the deploying a greater MTU value within the SR Domain than at the
ingress edges. ingress edges.
Encapsulation with an outer IPv6 header and SRH share the same MTU
and fragmentation considerations as IPv6 tunnels described in
[RFC2473]. In addition there are known issues with IPv6 tunnels
documented in [I-D.ietf-intarea-tunnels] section 5.2 that SHOULD be
considered.
5.4. ICMP Error Processing 5.4. ICMP Error Processing
ICMP error packets generated within the SR Domain are sent to source ICMP error packets generated within the SR Domain are sent to source
nodes within the SR Domain. The invoking packet in the ICMP error nodes within the SR Domain. The invoking packet in the ICMP error
message may contain an SRH. Since the destination address of a message may contain an SRH. Since the destination address of a
packet with an SRH changes as each segment is processed, it may not packet with an SRH changes as each segment is processed, it may not
be the destination used by the socket or application that generated be the destination used by the socket or application that generated
the invoking packet. the invoking packet.
For the source of an invoking packet to process the ICMP error For the source of an invoking packet to process the ICMP error
message, the correct destination address must be determined. The message, the ultimate destination address of the IPv6 header may be
following logic is used to determine the destination address for use required. The following logic is used to determine the destination
by protocol error handlers. address for use by protocol error handlers.
o Walk all extension headers of the invoking IPv6 packet to the o Walk all extension headers of the invoking IPv6 packet to the
routing extension header preceding the upper layer header. routing extension header preceding the upper layer header.
* If routing header is type 4 (SRH) * If routing header is type TBD IANA (SRH)
+ Use the SID at Segment List[0] as the destination address of + The SID at Segment List[0] may be used as the destination
the invoking packet. address of the invoking packet.
ICMP errors are then processed by upper layer transports as defined ICMP errors are then processed by upper layer transports as defined
in [RFC4443]. in [RFC4443].
For IP packets encapsulated in an outer IPv6 header, ICMP error For IP packets encapsulated in an outer IPv6 header, ICMP error
handling is as defined in [RFC2473]. handling is as defined in [RFC2473].
5.5. Load Balancing and ECMP 5.5. Load Balancing and ECMP
For any inter domain packet, the SR Source node MUST impose a flow For any inter domain packet, the SR Source node MUST impose a flow
skipping to change at page 21, line 45 skipping to change at page 22, line 4
Figure 3 Figure 3
o 3 and 4 are SR Domain edge routers o 3 and 4 are SR Domain edge routers
o 5, 6, and 7 are all SR Domain routers o 5, 6, and 7 are all SR Domain routers
o 8 and 9 are hosts within the SR Domain o 8 and 9 are hosts within the SR Domain
o 1 and 2 are hosts outside the SR Domain o 1 and 2 are hosts outside the SR Domain
o The SR domain implements ingress filtering as per Section 5.1 and
o The SR domain is secured as per Section 5.1 and no external packet no external packet can enter the domain with a destination address
can enter the domain with a destination address equal to a segment equal to a segment of the domain.
of the domain.
6.3. Source SR Node 6.3. Source SR Node
6.3.1. Intra SR Domain Packet 6.3.1. Intra SR Domain Packet
When host 8 sends a packet to host 9 via an SR Policy <S7,A9> the When host 8 sends a packet to host 9 via an SR Policy <S7,A9> the
packet is packet is
P1: (A8,S7)(A9,S7; SL=1) P1: (A8,S7)(A9,S7; SL=1)
skipping to change at page 22, line 34 skipping to change at page 22, line 37
P3: (A1,A2) P3: (A1,A2)
The SR Domain ingress router 3 receives P3 and steers it to SR Domain 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 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 received packet P3 in an outer header with an SRH. The packet is
P4: (A3, S7)(S4, S7; SL=1)(A1, A2) P4: (A3, S7)(S4, S7; SL=1)(A1, A2)
If the SR Policy contains only one segment (the egress router 4), the 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 ingress Router 3 encapsulates P3 into an outer header (A3, S4)
packet is without SRH. The packet is
P5: (A3, S4)(A1, A2) P5: (A3, S4)(A1, A2)
6.3.2.1. Reduced Variant 6.3.2.1. Reduced Variant
The SR Domain ingress router 3 receives P3 and steers it to SR Domain 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 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 a reduced SRH, Router 3 encapsulates the received packet P3 in an
outer header with a reduced SRH. The packet is outer header with a reduced SRH. The packet is
skipping to change at page 23, line 39 skipping to change at page 23, line 46
Node 7 receives packet P1 and, using the logic in Section 4.3.1, Node 7 receives packet P1 and, using the logic in Section 4.3.1,
sends packet sends packet
P7: (A8,A9)(A9,S7; SL=0) P7: (A8,A9)(A9,S7; SL=0)
on the interface toward router 6. on the interface toward router 6.
6.6. Delegation of Function with HMAC Verification 6.6. Delegation of Function with HMAC Verification
This section describes how a function may be delegated within the SR This section describes how a function may be delegated within the SR
Domain to non SR source nodes. In the following sections consider a Domain. In the following sections consider a host 8 connected to a
host 8 connected to a top of rack 5. top of rack 5.
6.6.1. SID List Verification 6.6.1. SID List Verification
An operator may prefer to add the SRH at source 8, while 5 verifies An operator may prefer to apply the SRH at source 8, while 5 verifies
the SID list is valid. the SID list is valid.
For illustration purpose, an SDN controller provides 8 an SRH For illustration purpose, an SDN controller provides 8 an SRH
terminating at node 9, with segment list <S5,S7,S6,A9>, and HMAC TLV terminating at node 9, with segment list <S5,S7,S6,A9>, and HMAC TLV
computed for the SRH. The HMAC key is shared with 5, node 8 does not computed for the SRH. The HMAC key ID and key associated with the
know the key. Node 5 is configured with an IACL applied to the HMAC TLV is shared with 5. Node 8 does not know the key. Node 5 is
interface connected to 8, requiring HMAC verification for any packet configured with an IACL applied to the interface connected to 8,
destined to S/s. requiring HMAC verification for any packet destined to S/s.
Node 8 originates packets with the received SRH with HMAC TLV. Node 8 originates packets with the received SRH including HMAC TLV.
P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC) P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC)
Node 5 receives and verifies the HMAC for the SRH, then forwards the Node 5 receives and verifies the HMAC for the SRH, then forwards the
packet to the next segment packet to the next segment
P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC) P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC)
Node 6 receives Node 6 receives
skipping to change at page 25, line 41 skipping to change at page 25, line 50
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 snooped within the SR Domain, the SRH may reveal packets can be snooped within the SR Domain, the SRH may reveal
topology, 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. Applicability of AH 7.5. Applicability of AH
The SR Domain is a trusted domain, as defined in [RFC8402] Section 2 The SR Domain is a trusted domain, as defined in [RFC8402] Section 2
and Section 8.2. The SR Source is trusted to add an SRH (optionally and Section 8.2. The SR Source is trusted to add an SRH (optionally
verified via the HMAC TLV in this document), and segments advertised verified as having been generated by a trusted source via the HMAC
within the domain are trusted to be accurate and advertised by TLV in this document), and segments advertised within the domain are
trusted sources via a secure control plane. As such the SR Domain trusted to be accurate and advertised by trusted sources via a secure
does not rely on the Authentication Header (AH) as defined in control plane. As such the SR Domain does not rely on the
[RFC4302] to secure the SRH. 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 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 segment endpoint node is not defined in this document. Future
documents may define use of SRH with AH and its processing. 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 46 skipping to change at page 27, line 6
TBD IANA SR Upper-layer Header Error TBD IANA SR Upper-layer Header Error
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the SRH, Authority (IANA) regarding registration of values related to the SRH,
in accordance with BCP 26, [RFC8126]. in accordance with BCP 26, [RFC8126].
The following terms are used here with the meanings defined in BCP The following terms are used here with the meanings defined in BCP
26: "namespace", "assigned value", "registration". 26: "namespace", "assigned value", "registration".
The following policies are used here with the meanings defined in BCP The following policies are used here with the meanings defined in BCP
26: "Private Use", "First Come First Served", "Expert Review", 26 [RFC8126]: "IETF Review".
"Specification Required", "IETF Consensus", "Standards Action".
For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the
Designated Expert. The intention is that any allocation will be
accompanied by a published RFC. In order to allow for the allocation
of values prior to the RFC being approved for publication, the
Designated Expert can approve allocations once it seems clear that an
RFC will be published. The Designated expert will post a request to
the 6man WG mailing list (or a successor designated by the Area
Director) for comment and review, including an Internet-Draft.
Before a period of 30 days has passed, the Designated Expert will
either approve or deny the registration request and publish a notice
of the decision to the 6man WG mailing list or its successor, as well
as informing IANA. A denial notice must be justified by an
explanation, and in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become
acceptable should be provided.
8.1. Segment Routing Header Flags Register 8.1. Segment Routing Header Flags 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 Flags Bits. The registration procedure is "Expert identify SRH Flags Bits. The registration procedure is "IETF
Review" as defined in [RFC8126]. Suggested registry name is "Segment Review". Suggested registry name is "Segment Routing Header Flags".
Routing Header Flags". Flags is 8 bits. 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 "IETF Review".
defined in [RFC8126]. Suggested registry name is "Segment Routing Suggested registry name is "Segment Routing Header TLVs". A TLV is
Header TLVs". A TLV is identified through an unsigned 8 bit identified through an unsigned 8 bit codepoint value, with assigned
codepoint value, with assigned values 0-127 for TLVs that do not values 0-127 for TLVs that do not change en route, and 128-255 for
change en route, and 128-255 for TLVs that may change en route. The TLVs that may change en route. The following codepoints are defined
following codepoints are defined in this document: in this document:
Assigned Description Reference Assigned Description Reference
Value Value
----------------------------------------------------- -----------------------------------------------------
0 Pad1 TLV This document 0 Pad1 TLV This document
1 Reserved This document 1 Reserved This document
2 Reserved This document 2 Reserved This document
3 Reserved This document 3 Reserved This document
4 PadN TLV This document 4 PadN TLV This document
5 HMAC TLV This document 5 HMAC TLV This document
skipping to change at page 29, line 38 skipping to change at page 29, line 28
Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, 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. David Lebrun, Benjamin Kaduk, Frank Xialiang, Mirja Kuhlewind, Roman
Danyliw, Joe Touch, and Magnus Westerlund for their comments to this
document.
12. References 12. References
12.1. Normative References 12.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-
fips-180-4.pdf>. 180-4.pdf>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[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>.
[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>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[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>.
[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>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
skipping to change at page 31, line 5 skipping to change at page 31, line 18
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
12.2. Informative References 12.2. Informative References
[I-D.filsfils-spring-srv6-interop] [I-D.filsfils-spring-srv6-interop]
Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A.,
Salsano, S., Bonaventure, O., Horn, J., and J. Liste, Salsano, S., Bonaventure, O., Horn, J., and J. Liste,
"SRv6 interoperability report", draft-filsfils-spring- "SRv6 interoperability report", draft-filsfils-spring-
srv6-interop-02 (work in progress), March 2019. srv6-interop-02 (work in progress), March 2019.
[I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "IP Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-10 (work in
progress), September 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-01 (work in progress), May spring-srv6-deployment-status-01 (work in progress), May
2019. 2019.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<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,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008, DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>. <https://www.rfc-editor.org/info/rfc5308>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[SRN] Lebrun, D., Jadin, M., Clad, F., Filsfils, C., and O. [SRN] Lebrun, D., Jadin, M., Clad, F., Filsfils, C., and O.
Bonaventure, "Software Resolved Networks: Rethinking Bonaventure, "Software Resolved Networks: Rethinking
Enterprise Networks with IPv6 Segment Routing", 2018, Enterprise Networks with IPv6 Segment Routing", 2018,
<https://inl.info.ucl.ac.be/system/files/ <https://inl.info.ucl.ac.be/system/files/
sosr18-final15-embedfonts.pdf>. sosr18-final15-embedfonts.pdf>.
 End of changes. 62 change blocks. 
129 lines changed or deleted 141 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/