draft-ietf-6man-segment-routing-header-22.txt   draft-ietf-6man-segment-routing-header-23.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: February 7, 2020 S. Previdi Expires: March 18, 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
August 6, 2019 September 15, 2019
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-22 draft-ietf-6man-segment-routing-header-23
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 February 7, 2020. This Internet-Draft will expire on March 18, 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 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 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
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
skipping to change at page 7, line 36 skipping to change at page 7, line 36
The highest-order bit of the TLV type specifies whether or not the The highest-order bit of the TLV type specifies whether or not the
TLV data of that type can change en route to the packet's final TLV data of that type can change en route to the packet's final
destination: 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.
The "Length" field of the TLV is used to skip the TLV while The "Length" field of the TLV is used to skip the TLV while
inspecting the SRH in case the node doesn't support or recognize the inspecting the SRH in case the node doesn't support or recognize the
Type. The "Length" defines the TLV length in octets, not including Type. The "Length" defines the TLV length in octets, not including
the "Type" and "Length" fields. the "Type" and "Length" fields.
The following TLVs are defined in this document: The following TLVs are defined in this document:
Padding 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, 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 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.
skipping to change at page 11, line 10 skipping to change at page 11, line 10
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, the packet is forwarded to the
next segment. 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. 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, and except that a value of 0 means
skipping to change at page 13, line 26 skipping to change at page 13, line 26
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 7. HMAC TLV may be set according to Section 2.1.2.
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 14, line 18 skipping to change at page 14, line 18
4.3. SR Segment Endpoint Node 4.3. SR Segment Endpoint Node
Without constraining the details of an implementation, the SR segment Without constraining the details of an implementation, the SR segment
endpoint node creates Forwarding Information Base (FIB) entries for endpoint node creates Forwarding Information Base (FIB) entries for
its local SIDs. its local SIDs.
When an SRv6-capable node receives an IPv6 packet, it performs a When an SRv6-capable node receives an IPv6 packet, it performs a
longest-prefix-match lookup on the packets destination address. This longest-prefix-match lookup on the packets destination address. This
lookup can return any of the following: lookup can return any of the following:
A FIB entry that represents a locally instantiated SRv6 SID * A FIB entry that represents a locally instantiated SRv6 SID
A FIB entry that represents a local interface, not locally * A FIB entry that represents a local interface, not locally
instantiated as an SRv6 SID instantiated as an SRv6 SID
A FIB entry that represents a non-local route * A FIB entry that represents a non-local route
No Match * No Match
4.3.1. FIB Entry Is Locally Instantiated SRv6 SID 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID
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,
skipping to change at page 16, line 38 skipping to change at page 16, line 38
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
header. header.
} }
A unique error code allows an SR Source node to recognize an error in A unique error code allows an SR Source node to recognize an error in
SID processing at an endpoint. SID processing at an endpoint.
4.3.2. FIB Entry is a Local Interface 4.3.2. FIB Entry Is A Local Interface
If the FIB entry represents a local interface, not locally If the FIB entry represents a local interface, not locally
instantiated as an SRv6 SID, the SRH is processed as follows: instantiated as an SRv6 SID, the SRH is processed as follows:
If Segments Left is zero, the node must ignore the Routing header If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet, whose type and proceed to process the next header in the packet, whose type
is identified by the Next Header field in the Routing Header. is identified by the Next Header field in the Routing Header.
If Segments Left is non-zero, the node must discard the packet and If Segments Left is non-zero, the node must discard the packet and
send an ICMP Parameter Problem, Code 0, message to the packet's send an ICMP Parameter Problem, Code 0, message to the packet's
skipping to change at page 18, line 16 skipping to change at page 18, line 16
* 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.
5.2. SR Domain as a single system with delegation among components 5.2. SR Domain as A Single System with Delegation Among Components
All intra SR Domain packets are of the SR Domain. The IPv6 header is All intra SR Domain packets are of the SR Domain. The IPv6 header is
originated by a node of the SR Domain, and is destined to a node of originated by a node of the SR Domain, and is destined to a node of
the SR Domain. the SR Domain.
All inter domain packets are encapsulated for the part of the packet All inter domain packets are encapsulated for the part of the packet
journey that is within the SR Domain. The outer IPv6 header is journey that is within the SR Domain. The outer IPv6 header is
originated by a node of the SR Domain, and is destined to a node of originated by a node of the SR Domain, and is destined to a node of
the SR Domain. the SR Domain.
skipping to change at page 24, line 44 skipping to change at page 24, line 44
to the SR Domain, destined to SIDs within the SR Domain (i.e., to the SR Domain, destined to SIDs within the SR Domain (i.e.,
bearing a SID in the destination address). This ingress filtering is bearing a SID in the destination address). This ingress filtering is
via an IACL at SR Domain ingress border nodes. Additional protection via an IACL at SR Domain ingress border nodes. Additional protection
is applied via an IACL at each SR Segment Endpoint node, filtering is applied via an IACL at each SR Segment Endpoint node, filtering
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 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 [RFC5095] deprecates the Type 0 Routing header due to a number of
significant attacks that are referenced in that document. Such significant attacks that are referenced in that document. Such
attacks include bypassing filtering devices, reaching otherwise attacks include bypassing filtering devices, reaching otherwise
unreachable Internet systems, network topology discovery, bandwidth unreachable Internet systems, network topology discovery, bandwidth
exhaustion, and defeating anycast. exhaustion, and defeating anycast.
Because this document specifies that the SRH is for use within an SR Because this document specifies that the SRH is for use within an SR
skipping to change at page 30, line 14 skipping to change at page 30, line 14
[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:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[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
 End of changes. 15 change blocks. 
19 lines changed or deleted 24 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/