draft-ietf-6man-segment-routing-header-16.txt   draft-ietf-6man-segment-routing-header-17.txt 
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Previdi Intended status: Standards Track S. Previdi
Expires: August 8, 2019 Huawei Expires: September 26, 2019 Huawei
J. Leddy J. Leddy
Individual Individual
S. Matsushima S. Matsushima
Softbank Softbank
D. Voyer, Ed. D. Voyer, Ed.
Bell Canada Bell Canada
February 4, 2019 March 25, 2019
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-16 draft-ietf-6man-segment-routing-header-17
Abstract Abstract
Segment Routing can be applied to the IPv6 data plane using a new Segment Routing can be applied to the IPv6 data plane using a new
type of Routing Extension Header. This document describes the type of Routing Extension Header. This document describes the
Segment Routing Extension Header and how it is used by Segment Segment Routing Extension Header and how it is used by Segment
Routing capable nodes. Routing capable nodes.
Requirements Language Requirements Language
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 August 8, 2019. This Internet-Draft will expire on September 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Segment Routing Extension Header . . . . . . . . . . . . . . 4 2. Segment Routing Extension Header . . . . . . . . . . . . . . 4
2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 6
2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8
3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 10 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11
3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11
3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 11 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 12
4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12
4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12
4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 12 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 13
4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 14 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 15
4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 15 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 16
4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 15 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 16
5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 15 5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 16
5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 15 5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 16
5.2. SR Domain as a single system with delegation among 5.2. SR Domain as a single system with delegation among
components . . . . . . . . . . . . . . . . . . . . . . . 16 components . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 17 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 17
5.4. AH ICV . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4. AH ICV . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5. ESP ICV . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. ESP ICV . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.6. ICMP Error Processing . . . . . . . . . . . . . . . . . . 17 5.6. ICMP Error Processing . . . . . . . . . . . . . . . . . . 18
5.7. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 18 5.7. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 18
5.8. Other Deployments . . . . . . . . . . . . . . . . . . . . 18 5.8. Other Deployments . . . . . . . . . . . . . . . . . . . . 19
6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Abstract Representation of an SRH . . . . . . . . . . . . 18 6.1. Abstract Representation of an SRH . . . . . . . . . . . . 19
6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 19 6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 20
6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 20 6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 21
6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 20 6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 21
6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 20 6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 21
6.3.3. Inter SR Domain Packet - Internal to External . . . . 21 6.3.3. Inter SR Domain Packet - Internal to External . . . . 22
6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 21 6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 22
6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 21 6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 22
6.6. Delegation of Function with HMAC Verification . . . . . . 21 6.6. Delegation of Function with HMAC Verification . . . . . . 22
6.6.1. SID List Verification . . . . . . . . . . . . . . . . 21 6.6.1. SID List Verification . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 23 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 24
7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 23 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 23 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 24
7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 24 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8.1. Segment Routing Header Flags Register . . . . . . . . . . 24 8.1. Segment Routing Header Flags Register . . . . . . . . . . 26
8.2. Segment Routing Header TLVs Register . . . . . . . . . . 24 8.2. Segment Routing Header TLVs Register . . . . . . . . . . 26
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 26
9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 26
9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 25 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 27
9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Segment Routing can be applied to the IPv6 data plane using a new Segment Routing can be applied to the IPv6 data plane using a new
type of Routing Extension Header (SRH). This document describes the type of Routing Extension Header (SRH). This document describes the
Segment Routing Extension Header and how it is used by Segment Segment Routing Extension Header and how it is used by Segment
Routing capable nodes. Routing capable nodes.
The Segment Routing Architecture [RFC8402] describes Segment Routing The Segment Routing Architecture [RFC8402] describes Segment Routing
and its instantiation in two data planes MPLS and IPv6. and its instantiation in two data planes MPLS and IPv6.
SR with the MPLS data plane is defined in
[I-D.ietf-spring-segment-routing-mpls].
SR with the IPv6 data plane is defined in
[I-D.filsfils-spring-srv6-network-programming].
The encoding of MPLS labels and label stacking are defined in
[RFC3032].
The encoding of IPv6 segments in the Segment Routing Extension Header The encoding of IPv6 segments in the Segment Routing Extension Header
is defined in this document. is defined in this document.
Terminology used within this document is defined in detail in Terminology used within this document is defined in detail in
[RFC8402]. Specifically, these terms: Segment Routing, SR Domain, [RFC8402]. Specifically, these terms: Segment Routing, SR Domain,
SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy. SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy.
2. Segment Routing Extension Header 2. Segment Routing Extension Header
Routing Headers are defined in [RFC8200]. The Segment Routing Header Routing Headers are defined in [RFC8200]. The Segment Routing Header
skipping to change at page 5, line 40 skipping to change at page 5, line 34
of the segment list (Segment List [0]) contains the last segment of the segment list (Segment List [0]) contains the last segment
of the SR Policy, the second element contains the penultimate of the SR Policy, the second element contains the penultimate
segment of the SR Policy and so on. segment of the SR Policy and so on.
o Type Length Value (TLV) are described in Section 2.1. o Type Length Value (TLV) are described in Section 2.1.
2.1. SRH TLVs 2.1. SRH TLVs
This section defines TLVs of the Segment Routing Header. This section defines TLVs of the Segment Routing Header.
TLVs are present when the Hdr Ext Len exceeds the Last Entry element
in the Segment List.
While processing TLVs at a segment endpoint, TLVs MUST be fully
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
ICMP Parameter Problem, Code 0, message to the Source Address,
pointing to the Hdr Ext Len field of the SRH, and the packet being
discarded.
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
skipping to change at page 6, line 51 skipping to change at page 7, line 7
Additional TLVs may be defined in the future. Additional TLVs may be defined in the future.
2.1.1. Padding TLVs 2.1.1. Padding TLVs
There are two types of padding TLVs, pad0 and padN, the following There are two types of padding TLVs, pad0 and padN, the following
applies to both: applies to both:
Padding TLVs are used to pad the TLVs to a multiple of 8 octets. Padding TLVs are used to pad the TLVs to a multiple of 8 octets.
More than one Padding TLV MUST NOT appear in the SRH.
The Padding TLVs are used to align the SRH total length on the 8
octet boundary.
When present, a single Pad0 or PadN TLV MUST appear as the last When present, a single Pad0 or PadN TLV MUST appear as the last
TLV. TLV. More than one Padding TLV MUST NOT appear in the SRH. The
Padding TLVs are used to align the SRH total length on the 8 octet
When present, a PadN TLV MUST have a length from 0 to 5 in order 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.
2.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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 8, line 45 skipping to change at page 8, line 45
o HMAC: 32 octets of keyed HMAC, not present if Key ID is 0. o HMAC: 32 octets of keyed HMAC, not present if Key ID is 0.
The HMAC TLV is used to verify the source of a packet is permitted to The HMAC TLV is used to verify the source of a packet is permitted to
use the current segment in the destination address of the packet, and use the current segment in the destination address of the packet, and
ensure the segment list is not modified in transit. ensure the segment list is not modified in transit.
2.1.2.1. HMAC Generation and Verification 2.1.2.1. HMAC Generation and Verification
Local policy determines when to check for an HMAC and potentially Local policy determines when to check for an HMAC and potentially
provides an alternate composition of Text, and a requirement on where provides an alternate composition of Text, and a requirement on where
the HMAC TLV must appear (e.g. first TLV). This local policy is the HMAC TLV must appear (e.g. first TLV), and whether or not to
outside the scope of this document. It may be based on the active verify the destination address is equal to the current segment. This
segment at an SR Segment endpoint node, the result of an ACL that local policy is outside the scope of this document. It may be based
considers incoming interface, HMAC Key ID, or other packet fields. on the active segment at an SR Segment endpoint node, the result of
an ACL that considers incoming interface, HMAC Key ID, or other
packet fields.
An implementation that supports the generation and verification of
the HMAC SHOULD support the following default behavior as defined in
the remainder of this section.
The HMAC verification begins by checking the current segment is equal
to the destination address of the IPv6 header, i.e. destination
address is equal to Segment List [Segments Left] and Segments Left is
less than or equal to Last Segment+1.
The HMAC field is the output of the HMAC computation as defined in The HMAC field is the output of the HMAC computation as defined in
[RFC2104], using: [RFC2104], using:
o key: the pre-shared key identified by HMAC Key ID o key: the pre-shared key identified by HMAC Key ID
o HMAC algorithm: identified by the HMAC Key ID o HMAC algorithm: identified by the HMAC Key ID
o Text: a concatenation of the following fields from the IPv6 header o Text: a concatenation of the following fields from the IPv6 header
and the SRH, as it would be received at the node verifying the and the SRH, as it would be received at the node verifying the
skipping to change at page 13, line 10 skipping to change at page 13, line 26
This document, and section, defines a single SRv6 SID called END. This document, and section, defines a single SRv6 SID called END.
Future documents may define additional SRv6 SIDs. In which case, the Future documents may define additional SRv6 SIDs. In which case, the
entire content of this section will be defined in that document. entire content of this section will be defined in that document.
If the FIB entry represents a locally instantiated SRv6 SID, process If the FIB entry represents a locally instantiated SRv6 SID, process
the next header of the IPv6 header as defined in section 4 of the next header of the IPv6 header as defined in section 4 of
[RFC8200] [RFC8200]
The following sections describe the actions to take while processing The following sections describe the actions to take while processing
next header fields. next header fields of the IPv6, and subsequent extension headers in
the order they are received.
4.3.1.1. SRH Processing 4.3.1.1. SRH Processing
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If Segments Left is equal to zero { S02. If Segments Left is equal to zero {
S03. Proceed to process the next header in the packet, S03. Proceed to process the next header in the packet,
whose type is identified by the Next Header field in whose type is identified by the Next Header field in
the Routing header. the Routing header.
S04. } S04. }
S05. Else { S05. Else {
S06. If local policy requires TLV processing { S06. If local policy requires TLV processing {
S07. Perform TLV processing (see TLV Processing) S07. Perform TLV processing (see TLV Processing)
S08. } S08. }
skipping to change at page 18, line 12 skipping to change at page 19, line 5
For IP packets encapsulated in an outer IPv6 header, ICMP error For IP packets encapsulated in an outer IPv6 header, ICMP error
handling is as defined in [RFC2473]. handling is as defined in [RFC2473].
5.7. Load Balancing and ECMP 5.7. Load Balancing and ECMP
For any inter domain packet, the SR Source node MUST impose a flow For any inter domain packet, the SR Source node MUST impose a flow
label computed based on the inner packet. The computation of the label computed based on the inner packet. The computation of the
flow label is as recommended in [RFC6438] for the sending Tunnel End flow label is as recommended in [RFC6438] for the sending Tunnel End
Point. Point.
For any intra domain packet, the SR Source node SHOULD impose a flow
label computed as described in [RFC6437] to assist ECMP load
balancing at transit nodes incapable of computing a 5-tuple beyond
the SRH.
At any transit node within an SR domain, the flow label MUST be used At any transit node within an SR domain, the flow label MUST be used
as defined in [RFC6438] to calculate the ECMP hash toward the as defined in [RFC6438] to calculate the ECMP hash toward the
destination address. If flow label is not used, the transit node may destination address. If flow label is not used, the transit node
hash all packets between a pair of SR Edge nodes to the same link. would likely 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.8. Other Deployments 5.8. Other Deployments
Other deployment models and their implications on security, MTU, Other deployment models and their implications on security, MTU,
HMAC, ICMP error processing and interaction with other extension HMAC, ICMP error processing and interaction with other extension
headers are outside the scope of this document. headers are outside the scope of this document.
skipping to change at page 24, line 24 skipping to change at page 25, line 24
This document makes the following registrations in the Internet This document makes the following registrations in the Internet
Protocol Version 6 (IPv6) Parameters "Routing Type" registry Protocol Version 6 (IPv6) Parameters "Routing Type" registry
maintained by IANA: maintained by IANA:
Suggested Description Reference Suggested Description Reference
Value Value
---------------------------------------------------------- ----------------------------------------------------------
4 Segment Routing Header (SRH) This document 4 Segment Routing Header (SRH) This document
This document request IANA to create and maintain a new Registry: This section provides guidance to the Internet Assigned Numbers
"Segment Routing Header TLVs" Authority (IANA) regarding registration of values related to the SRH,
in accordance with BCP 26, [RFC8126].
The following terms are used here with the meanings defined in BCP
26: "namespace", "assigned value", "registration".
The following policies are used here with the meanings defined in BCP
26: "Private Use", "First Come First Served", "Expert 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 "Expert
Review" as defined in [RFC8126]. Suggested registry name is "Segment Review" as defined in [RFC8126]. Suggested registry name is "Segment
Routing Header Flags". Flags is 8 bits, the following bits are Routing Header Flags". Flags is 8 bits.
defined in this document:
Suggested Description Reference
Bit
-----------------------------------------------------
4 HMAC This document
8.2. Segment Routing Header TLVs Register 8.2. Segment Routing Header TLVs Register
This document requests the creation of a new IANA managed registry to This document requests the creation of a new IANA managed registry to
identify SRH TLVs. The registration procedure is "Expert Review" as identify SRH TLVs. The registration procedure is "Expert Review" as
defined in [RFC8126]. Suggested registry name is "Segment Routing defined in [RFC8126]. Suggested registry name is "Segment Routing
Header TLVs". A TLV is identified through an unsigned 8 bit Header TLVs". A TLV is identified through an unsigned 8 bit
codepoint value. The following codepoints are defined in this codepoint value. The following codepoints are defined in this
document: document:
skipping to change at page 25, line 31 skipping to change at page 26, line 47
Implementation: adds SRH, performs END processing, supports HMAC TLV Implementation: adds SRH, performs END processing, supports HMAC TLV
Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and
[I-D.filsfils-spring-srv6-interop] [I-D.filsfils-spring-srv6-interop]
9.2. Cisco Systems 9.2. Cisco Systems
Name: IOS XR and IOS XE Name: IOS XR and IOS XE
Status: Pre-production Status: Production (IOS XR), Pre-protuction (IOS XE)
Implementation: adds SRH, performs END processing, no TLV processing Implementation: adds SRH, performs END processing, no TLV processing
Details: [I-D.filsfils-spring-srv6-interop] Details: [I-D.filsfils-spring-srv6-interop]
9.3. FD.io 9.3. FD.io
Name: VPP/Segment Routing for IPv6 Name: VPP/Segment Routing for IPv6
Status: Production Status: Production
skipping to change at page 27, line 43 skipping to change at page 29, line 11
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
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-01 (work in progress), September 2018. srv6-interop-02 (work in progress), March 2019.
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network-
programming-06 (work in progress), October 2018.
[I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-18
(work in progress), December 2018.
[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>.
[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>.
[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 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>. <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] and , "Software Resolved Networks: Rethinking Enterprise [SRN] Lebrun, D., Jadin, M., Clad, F., Filsfils, C., and O.
Networks with IPv6 Segment Routing", 2018, Bonaventure, "Software Resolved Networks: Rethinking
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>.
Authors' Addresses Authors' Addresses
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
 End of changes. 25 change blocks. 
104 lines changed or deleted 124 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/