draft-ietf-6man-segment-routing-header-19.txt   draft-ietf-6man-segment-routing-header-20.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: November 22, 2019 S. Previdi Expires: December 12, 2019 S. Previdi
Huawei Huawei
J. Leddy J. Leddy
Individual Individual
S. Matsushima S. Matsushima
Softbank Softbank
D. Voyer, Ed. D. Voyer
Bell Canada Bell Canada
May 21, 2019 June 10, 2019
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-19 draft-ietf-6man-segment-routing-header-20
Abstract Abstract
Segment Routing can be applied to the IPv6 data plane using a new Segment Routing can be applied to the IPv6 data plane using a new
type of Routing Extension Header. This document describes the type of Routing Extension Header. This document describes the
Segment Routing Extension Header and how it is used by Segment Segment Routing Extension Header and how it is used by Segment
Routing capable nodes. Routing capable nodes.
Status of This Memo Status of This Memo
skipping to change at page 1, line 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 November 22, 2019. This Internet-Draft will expire on December 12, 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 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Segment Routing Extension Header . . . . . . . . . . . . . . 4 2. Segment Routing Extension Header . . . . . . . . . . . . . . 4
2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 8
2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 9
3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . 13 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 13
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
skipping to change at page 3, line 14 skipping to change at page 3, line 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 24 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . . 27 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 28
9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 Extension Header (SRH). This document describes the type of Routing Extension Header (SRH). This document describes the
Segment Routing Extension Header and how it is used by Segment Segment Routing Extension Header and how it is used by Segment
Routing capable nodes. Routing capable nodes.
The Segment Routing Architecture [RFC8402] describes Segment Routing The Segment Routing Architecture [RFC8402] describes Segment Routing
and its instantiation in two data planes MPLS and IPv6. and its instantiation in two data planes MPLS and IPv6.
skipping to change at page 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 SID types which are not defined in this when processing other SIDs which are not defined in this document.
document. The allocation and use of tag is outside the scope of The allocation and use of tag is outside the scope of this
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, and Routing Type fields are In the SRH, the Next Header, Hdr Ext Len, and Routing Type fields are
defined in Section 4.4 of [RFC8200] as not mutable. The Segments defined in Section 4.4 of [RFC8200] as not mutable. The Segments
Left field is defined as mutable in Section 4.4 of [RFC8200]. Left field is defined as mutable in Section 4.4 of [RFC8200].
Some of the other fields of the SRH change en route (i.e. they are The mutability of the TLV value is defined by the most significant
mutable). The SRH is processed as defined in Section 4.3 of this bit in the type, as specified in Section 2.1.
document, and uniquely per SID type. The mutability of the remaining
fields in the SRH (Flags, Tag, Segment List, Optional TLVs) are Section 4.3 defines the mutability of the remaining fields in the SRH
defined in that section, in the context of segment processing. (Flags, Tag, Segment List) in the context of the SID defined in this
document.
New SIDs defined in the future MUST specify the mutability properties
of the Flags, Tag, and Segment List and indicate how the HMAC TLV
(Section 2.1.2) verification works. Note, that in effect these
fields are mutable.
Consistent with the source routing model, the source of the SRH
always knows how to set the segment list, Flags, Tag and TLVs of the
SRH for use within the SR Domain. How it achieves this is outside
the scope of this document, but may be based on topology, available
SIDs and their mutability properties, the SRH mutability requirements
of the destination, or any other information.
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
skipping to change at page 6, line 22 skipping to change at page 6, line 35
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 Pad0 (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
skipping to change at page 7, line 10 skipping to change at page 7, line 26
Type. Type.
Type Length Value (TLV) contain OPTIONAL information that may be used Type Length Value (TLV) contain OPTIONAL information that may be used
by the node identified in the Destination Address (DA) of the packet. by the node identified in the Destination Address (DA) of the packet.
Each TLV has its own length, format and semantic. The code-point Each TLV has its own length, format and semantic. The code-point
allocated (by IANA) to each TLV Type defines both the format and the allocated (by IANA) to each TLV Type defines both the format and the
semantic of the information carried in the TLV. Multiple TLVs may be semantic of the information carried in the TLV. Multiple TLVs may be
encoded in the same SRH. encoded in the same SRH.
TLVs may change en route at each segment. To identify when a TLV The highest-order bit of the TLV type specifies whether or not the
type may change en route the most significant bit of the Type has the TLV data of that type can change en route to the packet's final
following significance: 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 7, line 38 skipping to change at page 8, line 7
The following TLVs are defined in this document: The following TLVs are defined in this document:
Padding TLVs Padding TLVs
HMAC TLV HMAC TLV
Additional TLVs may be defined in the future. Additional TLVs may be defined in the future.
2.1.1. Padding TLVs 2.1.1. Padding TLVs
There are two types of padding TLVs, pad0 and padN, the following There are two types of padding TLVs, pad1 and padN, the following
applies to both: applies to both:
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 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. PAD0 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 Pad0 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 Pad0 TLV required. If more than one byte of padding is required a Pad1 TLV
MUST NOT be used, the PadN TLV MUST be used. MUST NOT be used, the PadN TLV MUST be used.
2.1.1.2. PADN 2.1.1.2. PADN
Alignment requirement: none Alignment requirement: none
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Padding (variable) | | Type | Length | Padding (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Padding (variable) // // Padding (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: to be assigned by IANA (suggested value 1). 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 Padding: Length octets of padding. Padding bits have no
semantics. They MUST be set to 0 on transmission and ignored on semantics. They MUST be set to 0 on transmission and ignored on
receipt. receipt.
The PadN TLV MUST be used when more than one byte of padding is The PadN TLV MUST be used when more than one byte of padding is
required. required.
skipping to change at page 14, line 17 skipping to change at page 14, line 27
This document, and section, defines a single SRv6 SID. Future This document, and section, defines a single SRv6 SID. Future
documents may define additional SRv6 SIDs. In which case, the entire documents may define additional SRv6 SIDs. In which case, the entire
content of this section will be defined in that document. content of this section will be defined in that document.
If the FIB entry represents a locally instantiated SRv6 SID, process If the FIB entry represents a locally instantiated SRv6 SID, process
the next header chain of the IPv6 header as defined in section 4 of the next header chain of the IPv6 header as defined in section 4 of
[RFC8200]. Section 4.3.1.1 describes how to process an SRH, [RFC8200]. Section 4.3.1.1 describes how to process an SRH,
Section 4.3.1.2 describes how to process an upper layer header or no Section 4.3.1.2 describes how to process an upper layer header or no
next header. next header.
Processing this SID type modifies the Segments Left and, if Processing this SID modifies the Segments Left and, if configured to
configured to process TLVs, it may modify the "variable length data" process TLVs, it may modify the "variable length data" of TLV types
of TLV types that change en route. Therefore Segments Left is that change en route. Therefore Segments Left is mutable and TLVs
mutable and TLVs that change en route are mutable. The remainder of that change en route are mutable. The remainder of the SRH (Flags,
the SRH (Flags, Tag, Segment List, and TLVs that do not change en Tag, Segment List, and TLVs that do not change en route) are
route) are immutable while processing this SID type. immutable while processing this SID.
4.3.1.1. SRH Processing 4.3.1.1. SRH Processing
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If Segments Left is equal to zero { S02. If Segments Left is equal to zero {
S03. Proceed to process the next header in the packet, S03. Proceed to process the next header in the packet,
whose type is identified by the Next Header field in whose type is identified by the Next Header field in
the Routing header. the Routing header.
S04. } S04. }
S05. Else { S05. Else {
S06. If local configuration requires TLV processing { S06. If local configuration requires TLV processing {
skipping to change at page 15, line 42 skipping to change at page 15, line 42
S22. Resubmit the packet to the IPv6 module for transmission S22. Resubmit the packet to the IPv6 module for transmission
to the new destination. to the new destination.
S23. } S23. }
S24. } S24. }
S25. } S25. }
S26. } S26. }
4.3.1.1.1. TLV Processing 4.3.1.1.1. TLV Processing
Local configuration determines how TLVs are to be processed when the Local configuration determines how TLVs are to be processed when the
Active Segment is a local SID type defined in this document. The Active Segment is a local SID defined in this document. The
definition of local configuration is outside the scope of this definition of local configuration is outside the scope of this
document. document.
For illustration purpose only, two example local configurations that For illustration purpose only, two example local configurations that
may be associated with a SID are provided below. may be associated with a SID are provided below.
Example 1: Example 1:
For any packet received from interface I2 For any packet received from interface I2
Skip TLV processing Skip TLV processing
skipping to change at page 16, line 21 skipping to change at page 16, line 21
If first TLV is HMAC { If first TLV is HMAC {
Process the HMAC TLV Process the HMAC TLV
} }
Else { Else {
Discard the packet Discard the packet
} }
4.3.1.2. Upper-layer Header or No Next Header 4.3.1.2. Upper-layer Header or No Next Header
When processing the Upper-layer header of a packet matching a FIB When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an SRv6 SID type defined in this entry locally instantiated as an SRv6 SID defined in this document.
document.
IF (Upper-layer Header is IPv4 or IPv6) and IF (Upper-layer Header is IPv4 or IPv6) and
local configuration permits { local configuration permits {
Perform IPv6 decapsulation Perform IPv6 decapsulation
Resubmit the decapsulated packet to the IPv4 or IPv6 module Resubmit the decapsulated packet to the IPv4 or IPv6 module
} }
ELSE { ELSE {
Send an ICMP parameter problem message to the Source Address and Send an ICMP parameter problem message to the Source Address and
discard the packet. Error code (TBD by IANA) "SR Upper-layer discard the packet. Error code (TBD by IANA) "SR Upper-layer
Header Error", pointer set to the offset of the upper-layer Header Error", pointer set to the offset of the upper-layer
skipping to change at page 27, line 29 skipping to change at page 27, line 29
identify SRH TLVs. The registration procedure is "Expert Review" as identify SRH TLVs. The registration procedure is "Expert Review" as
defined in [RFC8126]. Suggested registry name is "Segment Routing defined in [RFC8126]. Suggested registry name is "Segment Routing
Header TLVs". A TLV is identified through an unsigned 8 bit Header TLVs". A TLV is identified through an unsigned 8 bit
codepoint value, with assigned values 0-127 for TLVs that do not codepoint value, with assigned values 0-127 for TLVs that do not
change en route, and 128-255 for TLVs that may change en route. The change en route, and 128-255 for TLVs that may change en route. The
following codepoints are defined in this document: following codepoints are defined in this document:
Assigned Description Reference Assigned Description Reference
Value Value
----------------------------------------------------- -----------------------------------------------------
0 Pad0 TLV This document 0 Pad1 TLV This document
1 PadN TLV This document 1 Reserved This document
2 Reserved This document
3 Reserved for Opaque TLV [*]
4 PadN TLV This document
5 HMAC TLV This document 5 HMAC TLV This document
6 Reserved for NSH TLV [*]
124-126 Experimentation and Test This document
127 Reserved This document
252-254 Experimentation and Test This document
255 Reserved This document
[*] [I-D.xuclad-spring-sr-service-programming]
Values 1,2 were defined in draft versions of this specification and
are Reserved for backwards compatibility with early implementations.
Values 127 and 255 are Reserved to allow for expansion of the Type
field in future specifications if needed.
9. Implementation Status 9. Implementation Status
This section is to be removed prior to publishing as an RFC. This section is to be removed prior to publishing as an RFC.
See [I-D.matsushima-spring-srv6-deployment-status] for updated See [I-D.matsushima-spring-srv6-deployment-status] for updated
deployment and interoperability reports. deployment and interoperability reports.
9.1. Linux 9.1. Linux
skipping to change at page 30, line 33 skipping to change at page 31, line 5
Salsano, S., Bonaventure, O., Horn, J., and J. Liste, Salsano, S., Bonaventure, O., Horn, J., and J. Liste,
"SRv6 interoperability report", draft-filsfils-spring- "SRv6 interoperability report", draft-filsfils-spring-
srv6-interop-02 (work in progress), March 2019. srv6-interop-02 (work in progress), March 2019.
[I-D.matsushima-spring-srv6-deployment-status] [I-D.matsushima-spring-srv6-deployment-status]
Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6
Implementation and Deployment Status", draft-matsushima- Implementation and Deployment Status", draft-matsushima-
spring-srv6-deployment-status-01 (work in progress), May spring-srv6-deployment-status-01 (work in progress), May
2019. 2019.
[I-D.xuclad-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-xuclad-spring-sr-service-
programming-02 (work in progress), April 2019.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
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>.
skipping to change at page 32, line 15 skipping to change at page 32, line 38
Individual Individual
US US
Email: john@leddy.net Email: john@leddy.net
Satoru Matsushima Satoru Matsushima
Softbank Softbank
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Daniel Voyer (editor) Daniel Voyer
Bell Canada Bell Canada
Email: daniel.voyer@bell.ca Email: daniel.voyer@bell.ca
 End of changes. 25 change blocks. 
43 lines changed or deleted 77 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/