Insertion of IPv6 Segment Routing Headers in a Controlled Domain
draft-voyer-6man-extension-header-insertion-07
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Daniel Voyer , Clarence Filsfils , Darren Dukes , Satoru Matsushima , John Leddy | ||
| Last updated | 2019-09-20 (Latest revision 2019-07-08) | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-voyer-6man-extension-header-insertion-07
Network Working Group D. Voyer, Ed.
Internet-Draft Bell Canada
Intended status: Standards Track C. Filsfils
Expires: March 23, 2020 D. Dukes, Ed.
Cisco Systems, Inc.
S. Matsushima
Softbank
J. Leddy
Individual Contributor
September 20, 2019
Insertion of IPv6 Segment Routing Headers in a Controlled Domain
draft-voyer-6man-extension-header-insertion-07
Abstract
Traffic traversing an SR domain is encapsulated in an outer IPv6
header for its journey through the SR domain.
To implement transport services strictly within the SR domain, the SR
domain may require insertion or removal of an SRH after the outer
IPv6 header of the SR domain. Any segment within the SRH is strictly
contained within the SR domain.
The SR domain always preserves the end-to-end integrity of traffic
traversing it. No extension header is manipulated, inserted or
removed from an inner transported packet. The packet leaving the SR
domain is exactly the same (except for the hop-limit update) as the
packet entering the SR domain.
The SR domain is designed with link MTU sufficiently greater than the
MTU at the ingress edge of the SR domain.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
Voyer, et al. Expires March 23, 2020 [Page 1]
Internet-Draft SRH Insertion September 2019
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 23, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SRH-based Services Within the SR Domain . . . . . . . . . . . 3
2.1. Actions Within the SR Domain . . . . . . . . . . . . . . 5
2.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5
3. Detailed Description of Actions in the SR Domain . . . . . . 6
3.1. Action 2: SRH Insertion . . . . . . . . . . . . . . . . . 6
3.2. Action 3: SRH Removal . . . . . . . . . . . . . . . . . . 7
4. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. ICMP Error Processing . . . . . . . . . . . . . . . . . . 8
4.2. Packet Too Big . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Action Within the SR Domain and RFC8200 . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Voyer, et al. Expires March 23, 2020 [Page 2]
Internet-Draft SRH Insertion September 2019
1. Introduction
This document describes insertion and removal of SRH within an SR
domain, and explores why and how it is safe to do so.
2. SRH-based Services Within the SR Domain
An SR Domain is defined in [RFC8402].
Section 5.2 of [I-D.ietf-6man-segment-routing-header] further
describes the SR domain as a single system with delegation among
components. It states:
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 the SR Domain.
All inter domain packets are encapsulated for the part of the
packet 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 the SR Domain.
In other words, all packets within the SR domain have a source and
destination address within the SR Domain.
The following illustration shows how traffic is encapsulated within
an SR domain, and how an SRH is inserted and processed for a packet
traversing the SR domain.
+ * * * * * * * * * * * * * * * * * * * * +
* *
[1]----[3]--------[5]----------------[6]---------[4]---[2]
* | | *
| |
* | | *
[7]----------------[8]
* *
+ * * * * * * * SR Domain * * * * * * * +
Figure 1
o 3 and 4 are SR Domain edge routers
o 5, 6, 7, and 8 are all SR Domain routers
o 1 and 2 are hosts outside the SR Domain
Voyer, et al. Expires March 23, 2020 [Page 3]
Internet-Draft SRH Insertion September 2019
o The SR domain is secured as per Section 5.1 of
[I-D.ietf-6man-segment-routing-header] and no external packet can
enter the domain with a destination address equal to a segment of
the domain.
When host 1 sends a packet to host 2, the packet is
P1: (A1,A2)
The SR Domain ingress router 3 receives P1 and steers it to SR Domain
egress router 4 via an SR Policy <S6, S4>. Router 3 encapsulates the
received packet in an outer IPv6 header with an SRH. The packet is
P2: (A3, S6)(S4; SL=1)(A1, A2)
At node 5, P2 is steered through an SR Policy <S7,S8.PSP> resulting
in the insertion of an SRH. S8.PSP is a segment at node 8 that
removes the SRH when segments left is decremented to 0
P3: (A3, S7)(S6,S8.PSP; SL=2)(S4;SL=1)(A1, A2)
At node 7, S7 is processed. The outer most SRH segments left (SL) is
decremented and S8 is placed in the destination address of the outer
IPv6 header resulting in
P4: (A3, S8.PSP)(S6,S8.PSP; SL=1)(S4;SL=1)(A1, A2)
At node 8, S8.PSP is processed. The outer most SRH segments left is
decremented to 0 and S6 is placed in the destination address of the
outer IPv6 header. Since S8.PSP decrements SL to 0 it also removes
the SRH resulting in
P5: (A3, S6)(S4; SL=1)(A1, A2)
At node 6, S6 is processed. SL is decremented and S4 is placed in
the destination address of the outer IPv6 header
P6: (A3, S4)(S4; SL=0)(A1, A2)
At node 4, S4 is processed and the outer IPv6 header chain is removed
resulting in
P7: (A1, A2)
Voyer, et al. Expires March 23, 2020 [Page 4]
Internet-Draft SRH Insertion September 2019
2.1. Actions Within the SR Domain
The illustration above shows the possible actions taken in the SR
domain. They can be categorized as follows:
Action 1 IPv6 encapsulation and SRH insertion at SR Domain ingress
edge.
Described in [I-D.ietf-6man-segment-routing-header]
Action 2 SRH insertion at a node within the SR Domain applying an SR
policy to packets sourced and destined to nodes within the
SR Domain. The SR Policy may be applied for multiple
reasons including TILFA
[I-D.ietf-rtgwg-segment-routing-ti-lfa], or intermediate
node TE [I-D.ietf-spring-segment-routing-policy]. All
segments are within the SR domain.
Described in this document
Action 3 SRH processing at a segment endpoint, with PSP to remove an
SRH when SL is decremented to zero.
Described in this document and formally defined as an
instruction of the network programming model
[I-D.ietf-spring-srv6-network-programming]
Action 4 IPv6 and SRH decapsulation at SR domain egress edge
Described in draft-ietf-6man-segment-routing-header
2.2. Constraints
This document defines several constraints on the SR domain that
enable the safe insertion and removal of an SRH within the SR domain.
Source and destination address:
All traffic within the SR domain has IPv6 source and
destination address within the SR domain.
SRH without additional extension headers:
Within the context of this document and the described SRH use-
case within the SR domain, the SR domain can guarantee that SRH
is the sole extension header after the outer IPv6 header.
SRH insertion:
Only traffic sourced from and destined to nodes in the SR
domain may have an SRH inserted.
SRH segment list:
Segments in the SRH segment list are all within the SR domain
Voyer, et al. Expires March 23, 2020 [Page 5]
Internet-Draft SRH Insertion September 2019
MTU of the SR domain:
SR domain link MTU is sufficiently greater than the MTU at the
ingress edge of the SR domain. The difference in MTUs should
be greater than the sum of the IPv6 header length and the
expected length of all inserted SRH within the SR domain.
Packet size in the SR domain: Packet size in the SR domain:
All traffic forwarded in the SR domain has a packet size less
than the MTU of the SR domain.
This document does not limit the ability for future documents to
widen the scope.
These constraints reflect the design practices used in commercial
SRv6 deployments reported in
[I-D.matsushima-spring-srv6-deployment-status]
3. Detailed Description of Actions in the SR Domain
Within an SR domain, constrained as defined in Section 2.1, there are
two actions that require detailed description in this document.
Action 2: SRH insertion at a node within the SR Domain
Action 3: SRH processing at a segment endpoint with PSP to remove the
SRH when SL is decremented to zero.
3.1. Action 2: SRH Insertion
When an SRH is inserted by an intermediate node it walks the IPv6
header chain to the first header after the IPv6 header and inserts
the SRH prior to that header.
+---------------+----------------------+------------
| IPv6 header | SRH | IPv4 header
| | |
| Next Header = | Next Header = |
| SRH | IPv4 |
+---------------+----------------------+------------
^-SRH insertion here
Figure 2
An SR Policy headend within the SR domain inserts an SRH as follows:
1. Determine where to insert the SRH.
Voyer, et al. Expires March 23, 2020 [Page 6]
Internet-Draft SRH Insertion September 2019
2. Copy the destination address from the IPv6 header to Segment
List[0] of the SRH to be inserted. This ensures the original
destination address is restored upon execution of the final
segment in the inserted SRH.
3. Increase the IPv6 header payload length field by the length in
bytes of the inserted SRH.
If the resulting payload length exceeds 2^16 bytes generate an
ICMP "Packet To Big" error message to the source with an MTU of
2^16 minus the length in bytes of the SRH and discard the packet.
Note: this does not occur in reported deployments given the MTU
design constraint.
4. Set the SRH next header field to the value in the next header
field of the header that will precede the SRH.
5. Set the next header field of the header that will precede the SRH
to the routing extension header (43)
6. Set the IPv6 destination address to the first segment in the
segment list of the SRH to be inserted. This segment may or may
not be present in the SRH depending on the use of a reduced SRH,
see section 4.1.1 of [I-D.ietf-6man-segment-routing-header].
7. Insert the SRH into the packet at the location it should be
inserted and resubmit the packet to the IPv6 module for
transmission to the new destination.
3.2. Action 3: SRH Removal
An endpoint of the SRH removes an SRH of the SR domain as follows:
1. Decrement payload length by the length in bytes of the SRH being
removed.
2. Copy the next header value of the SRH being removed to the next
header value of the preceding header.
3. Remove the SRH from the packet.
4. MTU Considerations
This document assumes that the SR domain link MTU is sufficiently
greater than the MTU at the ingress edge of the SR domain. The
difference in MTUs should be greater than the sum of the IPv6 header
length and the expected length of all inserted SRH within the SR
domain.
Voyer, et al. Expires March 23, 2020 [Page 7]
Internet-Draft SRH Insertion September 2019
This is in-line with well known mitigation techniques that have been
deployed since the early 2000's for the MPLS-based FRR services and
numerous VPN services that involve deploying a greater MTU value in
the core than at the ingress edge of a domain.
This is also recommended in section 5.3 of
[I-D.ietf-6man-segment-routing-header].
4.1. ICMP Error Processing
ICMP errors may be generated for packets with one or more SRH
present. In such a case the ICMP process of a source node may
receive an ICMP error packet with more SRH's than it originated.
Processing of such packets follows the processing defined in section
5.4 of [I-D.ietf-6man-segment-routing-header] with relevant text
copied below:
o Walk all extension headers of the invoking IPv6 packet to the
routing extension header preceding the upper layer header.
* If routing header is type 4 (SRH)
+ Use the SID at Segment List[0] as the destination address of
the invoking packet.
ICMP errors are then processed by upper layer transports as defined
in [RFC4443].
For IP packets encapsulated in an outer IPv6 header, ICMP error
handling is as defined in [RFC2473].
4.2. Packet Too Big
When a larger MTU is deployed within the SR domain than at the
ingress edge ICMP "Packet Too Big" error messages should not be
generated within the SR domain.
They must be handled regardless, so in addition to the ICMP
processing defined in this document, a source node in the SR domain
receiving and processing an ICMP error "Packet Too Big" message
SHOULD decrement the MTU received in the message by the size in bytes
of the SRH's present in the invoking packet. This is required to
compensate for any SRH inserted along the packets path.
The SR domain ingress edge processing the ICMP error SHOULD log the
error and decrement the ingress edge MTU for traffic traversing the
SR domain (if it's greater than the IPv6 minimum MTU of 1280 bytes)
Voyer, et al. Expires March 23, 2020 [Page 8]
Internet-Draft SRH Insertion September 2019
or fragment the encapsulated packet to avoid reducing the ingress
edge MTU.
5. Security Considerations
To implement transport services strictly within the SR domain, the SR
domain may require the insertion or removal of an SRH after the outer
IPv6 header of the SR domain.
This document details the actions and reminds the reader of the
conditions that ensure
1. the integrity of the transported inner packet,
2. the security of the SR domain,
3. the non-leakage of intra SR domain SRH on external traffic.
The SR domain always preserves the end-to-end integrity of traffic
traversing it. No extension header is manipulated, inserted or
removed from an inner transported packet. The packet leaving the SR
domain is exactly the same (except for the hop-limit update) as the
packet entering the SR domain.
The SR domain is secured as per Section 5.1 of [SRH] and no external
packet can enter the domain with a destination address equal to a
segment of the domain.
An SRH of the SR domain is only added after the outer IPv6 header.
An SRH of the SR domain only contains segments within the domain.
Under these conditions, the SRH of the SR domain cannot leave the
domain. Additionally, egress edge nodes SHOULD ensure packets
sourced from within the SR domain (IPv6 source prefix), destined to
nodes outside the SR domain (IPv6 destination prefix) do not contain
an SRH.
All security considerations discussed in
[I-D.ietf-6man-segment-routing-header] are equally applicable to an
SRH applied by a non-source node within the SR domain.
6. Action Within the SR Domain and RFC8200
The four actions within the SR domain have the following association
with [RFC8200]
Action 1 IPv6 encapsulation and optional insertion of SRH at the SR
domain ingress edge generates a new IPv6 packet.
Voyer, et al. Expires March 23, 2020 [Page 9]
Internet-Draft SRH Insertion September 2019
Insertion of the SRH, if done, is obviously intended by the
SR source node.
The source node also intends for the SR domain to apply any
other SRH required.
This is in-line with RFC8200 as the source of the outer
header inserts the extension header.
Action 2 SRH insertion at a node within the SR Domain.
Insertion of the SRH at a node within the SR domain is
intended by any source node in the SR domain.
The source node has ensured the packet length it sends is
sufficient for the domain to insert an SRH.
Action 3 SRH processing and removal at a segment endpoint node
The node in the destination address parses the SRH and
removes the SRH when segments left is decremented to 0.
The node removing the SRH is the destination address of the
packet as per RFC8200.
Action 4 IPv6 and SRH decapsulation at SR domain egress edge
The node in the destination address of the IPv6 header
decapsulates the outer IPv6 header when no further segments
are left.
This is in-line with [RFC8200] as the destination of the
outer header removes the outer header and its extension
header.
Actions 1, 3, and 4 are all directly supported by [RFC8200] section 4
Extension headers (except for the Hop-by-Hop Options header) are
not processed, inserted, or deleted by any node along a packet's
delivery path, until the packet reaches the node (or each of the
set of nodes, in the case of multicast) identified in the
Destination Address field of the IPv6 header.
Each extension header should occur at most once, except for the
Destination Options header, which should occur at most twice (once
before a Routing header and once before the upper-layer header).
IPv6 nodes must accept and attempt to process extension headers in
any order and occurring any number of times in the same packet
Action 2 inserts an SRH in a packet within the SR domain at a node
not in the destination address, and inserts more than one SRH in a
packet. This does not appear to be permitted by the statements
quoted above from RFC8200. However, the restrictions above are not
Voyer, et al. Expires March 23, 2020 [Page 10]
Internet-Draft SRH Insertion September 2019
applicable within the SR domain. Every source node participating in
the SR domain expects SRH insertion, relies on it for services
provided by the SR domain, correctly processes ICMP errors, and
according to RFC8200 must process multiple SRH in the same packet.
7. IANA Considerations
This document doesn't introduce any IANA request.
8. Contributors
The authors would like to thank the following for their
contributions: Robert Raszuk, Stefano Previdi, Stefano Salsano,
Antonio Cianfrani, David Lebrun, Olivier Bonaventure, Prem
Jonnalagadda, Milad Sharif, Hani Elmalky, Ahmed Abdelsalam, Arthi
Ayyangar, Dirk Steinberg, Wim Henderickx.
9. References
9.1. Normative References
[I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-22 (work in progress), August 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Voyer, et al. Expires March 23, 2020 [Page 11]
Internet-Draft SRH Insertion September 2019
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
9.2. Informative References
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B.,
Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
Camarillo, "Topology Independent Fast Reroute using
Segment Routing", draft-ietf-rtgwg-segment-routing-ti-
lfa-01 (work in progress), March 2019.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing-
policy-03 (work in progress), May 2019.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-ietf-spring-srv6-network-
programming-01 (work in progress), July 2019.
[I-D.matsushima-spring-srv6-deployment-status]
Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6
Implementation and Deployment Status", draft-matsushima-
spring-srv6-deployment-status-01 (work in progress), May
2019.
Authors' Addresses
Daniel Voyer (editor)
Bell Canada
Email: daniel.voyer@bell.ca
Clarence Filsfils
Cisco Systems, Inc.
Brussels
BE
Email: cfilsfil@cisco.com
Voyer, et al. Expires March 23, 2020 [Page 12]
Internet-Draft SRH Insertion September 2019
Darren Dukes (editor)
Cisco Systems, Inc.
Ottawa
Canada
Email: ddukes@cisco.com
Satoru Matsushima
Softbank
Email: satoru.matsushima@g.softbank.co.jp
John Leddy
Individual Contributor
USA
Email: john@leddy.net
Voyer, et al. Expires March 23, 2020 [Page 13]