idnits 2.17.1 draft-voyer-6man-extension-header-insertion-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Voyer, Ed. 3 Internet-Draft Bell Canada 4 Intended status: Informational J. Leddy 5 Expires: January 9, 2020 Individual Contributor 6 C. Filsfils 7 D. Dukes, Ed. 8 Cisco Systems, Inc. 9 S. Previdi 10 Individual Contributor 11 S. Matsushima 12 Softbank 13 July 8, 2019 15 Insertion of IPv6 Segment Routing Headers in a Controlled Domain 16 draft-voyer-6man-extension-header-insertion-06 18 Abstract 20 The network operator and vendor community has clearly indicated that 21 IPv6 header insertion is useful and required. This is notably the 22 case when the entire journey of the packet remains in its source 23 domain. In such a context, it does not matter where the extension 24 header is inserted. The source domain may decide to place the IPv6 25 extension header insertion where it suits its best: at the source of 26 the packet or at any midpoint within the source domain. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Source Domain and Packet Journey . . . . . . . . . . . . . . 3 69 3. Transit Through a Source Domain . . . . . . . . . . . . . . . 4 70 4. Impact of SRH Insertion Within a Source Domain . . . . . . . 5 71 4.1. ICMP Error message processing . . . . . . . . . . . . . . 5 72 4.1.1. ICMP Error message processing with routing header . . 5 73 4.2. Destination outside the Source Domain . . . . . . . . . . 6 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 7. Manageability Considerations . . . . . . . . . . . . . . . . 6 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 81 10.2. Informative References . . . . . . . . . . . . . . . . . 7 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 84 1. Introduction 86 We define the concept of "domain" as the set of nodes under the same 87 administration. For example, a network operator infrastructure 88 including routers and links grouped into BGP autonomous systems (ASs) 89 and routing domains (running OSFP or IS-IS). 91 We define "source domain" as the domain of the source of the packet. 93 2. Source Domain and Packet Journey 95 (-- Source Domain D --) 96 ( ) 97 ( 1-----2-----3-----9 ) 98 ( | | ) 99 ( 4-----5 ) 100 (---------------------) 102 Figure 1: Source Domain 104 In the previous diagram: 106 o All the nodes 1 to 9 are in the same Source Domain D. 108 o Node 1 originates a packet P1 destined to 9 (SA=1, DA=9). 110 o Domain D runs a link-state routing protocols which implements the 111 Fast Reroute (FRR) service through the Topology Independent Loop 112 Free Alternates (TI-LFA, 113 [I-D.bashandy-rtgwg-segment-routing-ti-lfa]). 115 o All link metrics are set to 10. 117 o Node 2's TI-LFA pre-computed backup path for the destination 9 is 118 the Segment Routing Policy <5, 9> via outgoing interface (OIF) to 119 node 4 according to [I-D.filsfils-spring-segment-routing-policy], 120 [I-D.filsfils-spring-srv6-network-programming], and 121 [I-D.ietf-6man-segment-routing-header] 123 Within the 50 milliseconds of link 2-3 failure detection, node 2 124 reroutes the traffic destined to 9 by inserting the pre-computed 125 segment routing header (SRH) with SID list <5, 9> and forwards the 126 packet to node 4. Node 4 forwards based on DA=5 to neighbor 5. Node 127 5 updates the DA to 9 and removes the SRH. Node 9 receives the 128 packet with (SA=1, DA=9). 130 This FRR service is clearly beneficial for the operator of domain D: 131 without this FRR operation, depending on the scale of the domain and 132 the quality of the routing convergence implementation, traffic could 133 be dropped for hundreds to thousands of milliseconds waiting for the 134 routing plane to converge. 136 This FRR service is largely deployed with MPLS. 138 It is important to note that the operators industry is strongly 139 requiring the same TI-LFA FRR service without the need to deploy or 140 maintain the MPLS layer. 142 Obviously, this FRR service increases the size of the packet during 143 its journey within domain D. This is well-known to operators. Well- 144 known mitigation techniques have been deployed for more than 15 years 145 for the MPLS-based FRR service and the numerous VPN services. This 146 is often achieved by deploying a greater MTU value higher in the core 147 than at the ingress edge. 149 3. Transit Through a Source Domain 151 (-- Source Domain D --) 152 ( ) 153 A---( 1-----2-----3-----9 )---B 154 ( | | ) 155 ( 4-----5 ) 156 (---------------------) 158 Figure 2: Transit Through a Source Domain 160 Consider a packet sent from A to B called P2 (A,B). A and B are 161 external nodes to the Source Domain D. 163 Any packet transiting through source domain D must be unchanged when 164 it exits domain D. 166 Therefore, node 1 encapsulates the packet P2 in an outer IPv6 header 167 with SA=1 and DA=9. Resulting in packet P3 (1,9)(A,B). 169 From the viewpoint of domain D, packet P3 is the same as packet P1 of 170 the previous use-case. Indeed, domain D only considers the outer 171 header when forwarding P3 and the outer header is: (SA=1, DA=9). As 172 with packet P1, the entire journey of packet P3 is contained within 173 source domain D. 175 Node 2 may thus rightfully insert an SRH on packet P3 to implement a 176 sub-50 milliseconds FRR operation upon the loss of the link 2-to-3 177 and node 5 can remove this SRH. 179 The transparency of the service is guaranteed: the insertion and 180 removal of the SRH on packet P3 has no impact on packet P2. P2 at 181 the exit of the domain D is the same as at the entrance of the domain 182 D. 184 Customers of the transit service offered by source domain D do demand 185 FRR services. The 50 millisecond FRR operation provides a much 186 better service availability than 100's to 1000's of milliseconds of 187 loss for each routing transition. 189 4. Impact of SRH Insertion Within a Source Domain 191 This section discusses the impact of SRH insertion within a source 192 domain for traffic transiting the source domain, or traffic generated 193 within the source domain. 195 Any SRH inserted on a packet within a source domain MUST be removed 196 before delivery to destination. This requirement ensures the 197 destination node will not receive a packet with an SRH not inserted 198 by the source SR Node. Therefore there is no impact of an 199 inadvertent SRH being received at a destination node. 201 There are however two points of impact associated with ICMP error 202 generation back to the source: 204 Path MTU discovery [RFC8201] may generate ICMP error messages to 205 the packet source. 207 Hop Limit may be exhausted and generate ICMP error messages to the 208 packet source. 210 4.1. ICMP Error message processing 212 Using the example packet P1 from Section 3. If Hop Limit decrements 213 to 0 or a Packet Too Big (PTB) error is generated at node 4, after 214 the SRH is inserted, the destination address in P1 is 5. 216 This results in an ICMP error message generated to node 1, as per 217 [RFC4443] but with an unfamiliar destination address. 219 4.1.1. ICMP Error message processing with routing header 221 During parsing of the ICMP error message at node 1, the invoking 222 packet's protocol receives the error. In the case of UDP and TCP, 223 the invoking packet four-tuple (source address, source port, 224 destination address, destination port) identifies a UDP or TCP 225 session. 227 Since the original destination (node 9) is not the current 228 destination of the invoking packet, the lookup cannot succeed in 229 current implementations, and the error is not delivered to the source 230 UDP or TCP session. 232 This is common for any use of routing headers regardless of whether a 233 routing header is inserted at source or by an intermediate node. 235 4.2. Destination outside the Source Domain 237 Since the SRH inserted within an intermediate node MUST be removed 238 when all segments within the SRH have been visited, it is not 239 possible to leak the SRH to the destination outside the source 240 domain. 242 5. Security Considerations 244 This document proposes to insert an SRH to a transit packet if such 245 packet is originated and destined within a controlled/trusted domain. 247 Insertion of SRH is safe when confined within a source domain. 249 In such conditions, the security of the original packet is not 250 compromised by header insertion. The packet reaches the destination 251 or leaves the source domain without any inserted header. 253 A source domain can operate SRv6-based services for internal traffic 254 while preventing any external traffic from accessing these internal 255 SRv6-based services. Several mechanisms exists and are currently 256 used today, for example: 258 o Access-lists (ACL) on the each externally facing interface in 259 order to drop any incoming traffic with SA or DA belonging to the 260 internal SID space. 262 o ACL to prevent access to local SIDs from outside the operator's 263 infrastructure. 265 o Support Unicast-RPF on source address on external interface. 267 6. IANA Considerations 269 This document doesn't introduce any IANA request. 271 7. Manageability Considerations 273 TBD 275 8. Contributors 277 The authors would like to thank the following for their 278 contributions: Stefano Salsano, Antonio Cianfrani, David Lebrun, 279 Olivier Bonaventure, Prem Jonnalagadda, Milad Sharif, Hani Elmalky, 280 Ahmed Abdelsalam, Robert Raszuk, Arthi Ayyangar, Dirk Steinberg, Wim 281 Henderickx. 283 9. Acknowledgements 285 TBD 287 10. References 289 10.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 297 Control Message Protocol (ICMPv6) for the Internet 298 Protocol Version 6 (IPv6) Specification", STD 89, 299 RFC 4443, DOI 10.17487/RFC4443, March 2006, 300 . 302 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 303 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 304 DOI 10.17487/RFC8201, July 2017, 305 . 307 10.2. Informative References 309 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 310 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 311 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 312 Camarillo, "Topology Independent Fast Reroute using 313 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 314 lfa-05 (work in progress), October 2018. 316 [I-D.filsfils-spring-segment-routing-policy] 317 Filsfils, C., Sivabalan, S., Hegde, S., 318 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 319 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 320 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 321 J., Clad, F., and K. Raza, "Segment Routing Policy 322 Architecture", draft-filsfils-spring-segment-routing- 323 policy-06 (work in progress), May 2018. 325 [I-D.filsfils-spring-srv6-network-programming] 326 Filsfils, C., Camarillo, P., Leddy, J., 327 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 328 Network Programming", draft-filsfils-spring-srv6-network- 329 programming-07 (work in progress), February 2019. 331 [I-D.ietf-6man-segment-routing-header] 332 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 333 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 334 Routing Header (SRH)", draft-ietf-6man-segment-routing- 335 header-21 (work in progress), June 2019. 337 Authors' Addresses 339 Daniel Voyer (editor) 340 Bell Canada 342 Email: daniel.voyer@bell.ca 344 John Leddy 345 Individual Contributor 346 USA 348 Email: john@leddy.net 350 Clarence Filsfils 351 Cisco Systems, Inc. 352 Brussels 353 BE 355 Email: cfilsfil@cisco.com 357 Darren Dukes (editor) 358 Cisco Systems, Inc. 359 Ottawa 360 Canada 362 Email: ddukes@cisco.com 364 Stefano Previdi 365 Individual Contributor 366 Italy 368 Email: stefano@previdi.net 370 Satoru Matsushima 371 Softbank 373 Email: satoru.matsushima@g.softbank.co.jp