draft-ietf-6man-segment-routing-header-24.txt   draft-ietf-6man-segment-routing-header-25.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: April 5, 2020 S. Previdi Expires: April 12, 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
October 3, 2019 October 10, 2019
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-24 draft-ietf-6man-segment-routing-header-25
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 April 5, 2020. This Internet-Draft will expire on April 12, 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 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 14
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
Components . . . . . . . . . . . . . . . . . . . . . . . 18 Components . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 19 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 12 skipping to change at page 3, line 12
6.6. Delegation of Function with HMAC Verification . . . . . . 23 6.6. Delegation of Function with HMAC Verification . . . . . . 23
6.6.1. SID List Verification . . . . . . . . . . . . . . . . 24 6.6.1. SID List Verification . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . 26 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 Registry . . . . . . . . . . 27
8.2. Segment Routing Header TLVs Register . . . . . . . . . . 27 8.2. Segment Routing Header TLVs Registry . . . . . . . . . . 27
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . . . . . 28 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
skipping to change at page 7, line 11 skipping to change at page 7, line 11
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 codepoint from Segment Routing Header TLVs Register Type: An 8 bit codepoint from Segment Routing Header TLVs Registry
TBD IANA Reference. Unrecognized Types MUST be ignored on receipt. TBD IANA Reference. Unrecognized Types MUST be ignored on receipt.
Length: The length of the Variable length data in bytes. 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) entries contain OPTIONAL information that may Type Length Value (TLV) entries contain OPTIONAL information that may
be used by the node identified in the Destination Address (DA) of the be used by the node identified in the Destination Address (DA) of the
packet. packet.
skipping to change at page 9, line 18 skipping to change at page 9, line 18
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:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED | | Type | Length |D| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Key ID (4 octets) | | HMAC Key ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| // | //
| HMAC (32 octets) // | HMAC (Variable) //
| // | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: to be assigned by IANA (suggested value 5). o Type: to be assigned by IANA (suggested value 5).
o Length: 38. o Length: The length of the variable length data in bytes.
o RESERVED: 2 octets. MUST be 0 on transmission and ignored on o D: 1 bit. 1 indicates the Destination Address verification is
disabled due to use of reduced segment list, Section 4.1.1.
o RESERVED: 15 bits. 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: Keyed HMAC, in multiples of 8 octets, at most 32 octets.
The HMAC TLV is used to verify that the SRH applied to a packet was The HMAC TLV is used to verify that the SRH applied to a packet was
selected by an authorized party, and to ensure that the segment list selected by an authorized party, and to ensure that the segment list
is not modified after generation. This also allows for verification is not modified after generation. This also allows for verification
that the current segment (by virtue of being in the authorized that the current segment (by virtue of being in the authorized
segment list) is authorized for use. The SR Domain ensures the segment list) is authorized for use. The SR Domain ensures the
source node is permitted to use the source address in the packet via source node is permitted to use the source address in the packet via
ingress filtering mechanisms as defined in BCP 84 [RFC3704], or other ingress filtering mechanisms as defined in BCP 84 [RFC3704], or other
strategies as appropriate. 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. This local
potentially indicates what the HMAC protects, and a requirement on configuration is outside the scope of this document. It may be based
where the HMAC TLV must appear (e.g. first TLV), and whether or not on the active segment at an SR Segment endpoint node, the result of
to verify the destination address is equal to the current segment. an ACL that considers incoming interface, HMAC Key ID, or other
This local configuration is outside the scope of this document. It packet fields.
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,
or other packet fields.
An implementation that supports the generation and verification of An implementation that supports the generation and verification of
the HMAC SHOULD support the following default behavior as defined in the HMAC SHOULD support the following default behavior as defined in
the remainder of this section. the remainder of this section.
The HMAC verification begins by checking the current segment is equal The HMAC verification begins by checking the current segment is equal
to the destination address of the IPv6 header, i.e. destination to the destination address of the IPv6 header. The check is
address is equal to Segment List [Segments Left] and Segments Left is successful when either
less than or equal to Last Segment+1.
o HMAC D bit is 1 and Segments Left is greater than Last Entry.
o HMAC Segments Left is less than or equal to Last Entry and
destination address is equal to Segment List [Segments Left].
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
HMAC: HMAC:
* IPv6 header: source address (16 octets) * IPv6 header: source address (16 octets)
* SRH: Last Entry (1 octet) * SRH: Last Entry (1 octet)
* SRH: Flags (1 octet) * SRH: Flags (1 octet)
* SRH: HMAC Key-id (4 octets) * SRH: HMAC 16 bits following Length
* SRH: HMAC Key ID (4 octets)
* 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. Subsequent
octets MUST be set to zero. octets MUST be set to zero such that the HMAC length is a multiple of
8 octets.
If HMAC verification is successful, processing proceeds as normal. If HMAC verification is successful, processing proceeds as normal.
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. shared key and hash algorithm.
At the HMAC TLV gernerating and verification nodes, the Key ID At the HMAC TLV generating and verification nodes, the Key ID
uniquely identifies the pre-shared key and HMAC algorithm. uniquely identifies the pre-shared key and HMAC algorithm.
At the HMAC TLV generating node, the Text for the HMAC computation is At the HMAC TLV generating node, the Text for the HMAC computation is
set to the IPv6 header fields and SRH fields as they would appear at 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 the verification node, not necessarily the same as the source node
sending a packet with the HMAC TLV. 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.
skipping to change at page 19, line 15 skipping to change at page 19, line 15
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 Encapsulation with an outer IPv6 header and SRH share the same MTU
and fragmentation considerations as IPv6 tunnels described in and fragmentation considerations as IPv6 tunnels described in
[RFC2473]. In addition there are known issues with IPv6 tunnels [RFC2473]. Further investigation on the limitation of various
documented in [I-D.ietf-intarea-tunnels] section 5.2 that SHOULD be tunneling methods (including IPv6 tunnels) are discussed in
considered. [I-D.ietf-intarea-tunnels] and SHOULD be considered by operators when
considering MTU within the SR Domain.
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.
skipping to change at page 25, line 10 skipping to change at page 25, line 10
packets not from within the SR Domain, destined to SIDs in the SR packets not from within the SR Domain, destined to SIDs in the SR
Domain. ACLs are easily supported for small numbers of prefixes, Domain. ACLs are easily supported for small numbers of prefixes,
making summarization important, and when the prefixes requiring making summarization important, and when the prefixes requiring
filtering is kept to a seldom changing set. filtering is kept to a seldom changing set.
Additionally, ingress filtering of IPv6 source addresses as Additionally, ingress filtering of IPv6 source addresses as
recommended in BCP38 [RFC2827] SHOULD be used. recommended in BCP38 [RFC2827] SHOULD be used.
7.1. Source Routing Attacks 7.1. Source Routing Attacks
[RFC5095] deprecates the Type 0 Routing header due to a number of An SR domain implements distributed and per node protection as
significant attacks that are referenced in that document. Such described in section 5.1. Additionally, domains deny traffic with
attacks include bypassing filtering devices, reaching otherwise spoofed addresses by implementing the recommendations in BCP 84
unreachable Internet systems, network topology discovery, bandwidth [RFC3704].
exhaustion, and defeating anycast.
Because this document specifies that the SRH is for use within an SR Full implementation of the recommended protection blocks the attacks
domain protected by ingress filtering via IACLs; such attacks cannot documented in [RFC5095] from outside the SR domain, including
be mounted from outside an SR Domain. As specified in this document, bypassing filtering devices, reaching otherwise unreachable Internet
SR Domain ingress edge nodes drop packets entering the SR Domain systems, network topology discovery, bandwidth exhaustion, and
destined to segments within the SR Domain. defeating anycast.
Additionally, this document specifies the use of IACL on SR Segment Failure to implement distributed and per node protection allows
Endpoint nodes within the SR Domain to limit the source addresses attackers to bypass filtering devices and exposes the SR Domain to
permitted to send packets to a SID in the SR Domain. these attacks.
Such attacks may, however, be mounted from within the SR Domain, from Compromised nodes within the SR Domain may mount the attacks listed
nodes permitted to source traffic to SIDs in the domain. As such, above along with other known attacks on IP networks (e.g. DOS/DDOS,
these attacks and other known attacks on an IP network (e.g. DOS/ topology discovery, man-in-the-middle, traffic interception/
DDOS, topology discovery, man-in-the-middle, traffic interception/ siphoning).
siphoning), can occur from compromised nodes within an SR Domain.
7.2. Service Theft 7.2. Service Theft
Service theft is defined as the use of a service offered by the SR Service theft is defined as the use of a service offered by the SR
Domain by a node not authorized to use the service. Domain by a node not authorized to use the service.
Service theft is not a concern within the SR Domain as all SR Source Service theft is not a concern within the SR Domain as all SR Source
nodes and SR segment endpoint nodes within the domain are able to nodes and SR segment endpoint nodes within the domain are able to
utilize the services of the Domain. If a node outside the SR Domain utilize the services of the Domain. If a node outside the SR Domain
learns of segments or a topological service within the SR domain, learns of segments or a topological service within the SR domain,
skipping to change at page 27, line 8 skipping to change at page 27, line 8
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 [RFC8126]: "IETF Review". 26 [RFC8126]: "IETF Review".
8.1. Segment Routing Header Flags Register 8.1. Segment Routing Header Flags Registry
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 "IETF identify SRH Flags Bits. The registration procedure is "IETF
Review". Suggested registry name is "Segment Routing Header Flags". Review". Suggested registry name is "Segment Routing Header Flags".
Flags is 8 bits. Flags is 8 bits.
8.2. Segment Routing Header TLVs Register 8.2. Segment Routing Header TLVs Registry
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 "IETF Review". identify SRH TLVs. The registration procedure is "IETF Review".
Suggested registry name is "Segment Routing Header TLVs". A TLV is Suggested registry name is "Segment Routing Header TLVs". A TLV is
identified through an unsigned 8 bit codepoint value, with assigned identified through an unsigned 8 bit codepoint value, with assigned
values 0-127 for TLVs that do not change en route, and 128-255 for values 0-127 for TLVs that do not change en route, and 128-255 for
TLVs that may change en route. The following codepoints are defined TLVs that may change en route. The following codepoints are defined
in this document: in this document:
Assigned Description Reference Assigned Description Reference
 End of changes. 25 change blocks. 
52 lines changed or deleted 58 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/