idnits 2.17.1 draft-voyer-6man-extension-header-insertion-02.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 : ---------------------------------------------------------------------------- ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-bashandy-rtgwg-segment-routing-ti-lfa-00 == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-00 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-06 == Outdated reference: A later version (-01) exists of draft-dukes-sr-for-sdwan-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Voyer 3 Internet-Draft D. Bernier 4 Intended status: Informational Bell Canada 5 Expires: May 24, 2018 J. Leddy 6 Comcast 7 C. Filsfils 8 D. Dukes 9 Cisco Systems, Inc. 10 S. Previdi, Ed. 11 Individual Contributor 12 S. Salsano 13 Universita di Roma Tor Vergata 14 A. Cianfrani 15 Universita La Sapienza 16 D. Lebrun 17 O. Bonaventure 18 Universite Catholique de Louvain 19 P. Jonnalagadda 20 M. Sharif 21 Barefoot Networks 22 H. Elmalky 23 Ericsson 24 A. Abdelsalam 25 Gran Sasso Science Institute 26 R. Raszuk 27 Bloomberg 28 A. Ayyangar 29 Arista 30 D. Steinberg 31 Steinberg Consulting 32 W. Henderickx 33 Nokia 34 November 20, 2017 36 Insertion of IPv6 Segment Routing Headers in a Controlled Domain 37 draft-voyer-6man-extension-header-insertion-02 39 Abstract 41 The network operator and vendor community has clearly indicated that 42 IPv6 header insertion is useful and required. This is notably the 43 case when the entire journey of the packet remains in its source 44 domain. In such a context, it does not matter where the extension 45 header is inserted. The source domain may decide to place the IPv6 46 extension header insertion where it suits its best: at the source of 47 the packet or at any midpoint within the source domain. 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at http://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 Copyright Notice 72 Copyright (c) 2017 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 88 2. Source Domain and Packet Journey . . . . . . . . . . . . . . 3 89 2.1. Example: 6PE . . . . . . . . . . . . . . . . . . . . . . 4 90 3. Transit through a Source Domain . . . . . . . . . . . . . . . 5 91 3.1. Example: SDWAN . . . . . . . . . . . . . . . . . . . . . 5 92 4. SRH insertion in Source Domain . . . . . . . . . . . . . . . 6 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 95 7. Manageability Considerations . . . . . . . . . . . . . . . . 7 96 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 100 10.2. Informative References . . . . . . . . . . . . . . . . . 8 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 103 1. Introduction 105 We define the concept of "domain" as the set of nodes under the same 106 administration. For example, a network operator infrastructure 107 including routers and links grouped into BGP autonomous systems (ASs) 108 and routing domains (running OSFP or IS-IS). 110 We define "source domain" as the domain of the source of the packet. 112 2. Source Domain and Packet Journey 114 (--- Source Domain ---) 115 ( ) 116 ( 1-----2-----3-----9 ) 117 ( | | ) 118 ( 4-----5 ) 119 (---------------------) 121 Figure 1: Source Domain 123 In the previous diagram: 125 o All the nodes 1 to 9 are in the same domain D. 127 o Node 1 originates a packet P1 destined to 9 (SA=1, DA=9). 129 o Domain D runs a link-state routing protocols which implements the 130 Fast Reroute (FRR) service through the Topology Independent Loop 131 Free Alternates (TI-LFA, 132 [I-D.bashandy-rtgwg-segment-routing-ti-lfa]). 134 o All link metrics are set to 10. 136 o Node 2's TI-LFA pre-computed backup path for the destination 9 is 137 the Segment Routing Policy <5, 9> via outgoing interface (OIF) to 138 node 4 according to [I-D.filsfils-spring-segment-routing-policy], 139 [I-D.filsfils-spring-srv6-network-programming] and 140 [I-D.ietf-6man-segment-routing-header]. 142 Within the 50 milliseconds of link 2-3 failure detection, node 2 143 reroutes the traffic destined to 9 by inserting the pre-computed 144 segment routing header (SRH) with SID list <5, 9> and forwards the 145 packet to node 4. Node 4 forwards based on DA=5 to neighbor 5. Node 146 5 updates the DA to 9 and removes the SRH. Node 9 receives the 147 packet with (SA=1, DA=9). 149 This FRR service is clearly beneficial for the operator of domain D: 150 without this FRR operation, depending on the scale of the domain and 151 the quality of the routing convergence implementation, traffic could 152 be dropped for hundreds to thousands of milliseconds waiting for the 153 routing plane to converge. 155 This FRR service is largely deployed with MPLS. 157 It is important to note that the operators industry is strongly 158 requiring the same TI-LFA FRR service without the need to deploy or 159 maintain the MPLS layer. 161 Obviously, this FRR service increases the size of the packet during 162 its journey within domain D. This is well-known to operators. Well- 163 known mitigation techniques have been deployed for more than 15 years 164 for the MPLS-based FRR service and the numerous VPN services. The 165 same exact technique can be used which consists of deploying an 166 infrastructure capable of an MTU value higher in the core than at the 167 ingress edge. 169 2.1. Example: 6PE 171 An illustrative example of packet size increasing while in transit is 172 given by the 6PE use case ([RFC4798]) and consists of the following: 174 o An ingress router encapsulates incoming IPv6 packets into a MPLS 175 label stack. 177 o The ingress router forwards the encapsulated packet across the 178 MPLS core infrastructure of the operator. 180 o While transiting in the core, the size of the label stack (hence 181 the size of the packet) may increase when additional labels are 182 pushed on top of the packet due to services such as traffic 183 engineering (TE) and/or fast reroute (FRR). 185 o Once the packet reaches the egress router, the label stack is 186 removed and the packet is sent out of the operator network as an 187 IPv6 packet. 189 Using the example topology in Figure 1: 191 o Router 1 receives an incoming IPv6 packet, classifies it and does 192 push a label corresponding to the egress router this packet must 193 reach (router 9). At this stage the packet size has already 194 increased by the size of one label (32 bits). 196 o In addition, router 1 is configured with a policy consisting of a 197 traffic engineered path (2, 4, 5, 9) represented by an additional 198 label. At this stage the packet size has increased by the size of 199 two labels). 201 o While in transit in the traffic engineered path, a link may fail 202 and fast reroute (FRR) may have been provisioned so that the 203 packet is immediately re-routed (e.g., by router 4) using an 204 additional label. At this stage the packet size has increased by 205 the size of three labels. 207 o It has also to be noted that the packet may be part of a virtual 208 private network (VPN) service in which case it will have an 209 additional label corresponding to the VPN the packet belongs to. 210 In this case the packet size has increased by the size of four 211 labels. 213 o Once the packet reaches its egress router (router 9) the label 214 stack is consumed, the packet shape and size is restored to its 215 original state and the packet is forwarded externally, as a plain 216 IPv6 packet. 218 3. Transit through a Source Domain 220 (--- Source Domain ---) 221 ( ) 222 A---( 1-----2-----3-----9 )---B 223 ( | | ) 224 ( 4-----5 ) 225 (---------------------) 227 Figure 2: Transit Through a Source Domain 229 We now consider a packet P2 sent from A to B where A and B are 230 external nodes to the domain D. 232 We assume that when node 1 receives the packet, for service 233 transparency reason (the packet that exits the domain MUST be the 234 same as when it entered the domain), node 1 encapsulates the packet 235 P2 in an outer IPv6 header with SA=1 and DA=9. We call the resulting 236 packet P3. 238 Note that node 1 in Domain D is the source of a new IPv6 packet (P3) 239 that encapsulates P2, therefore we refer to this scenario as "Transit 240 Through a Source domain". 242 From the viewpoint of domain D, packet P3 is the same as packet P1 of 243 the previous use-case. Indeed, domain D only considers the outer 244 header and from that viewpoint, the outer header is the same: (SA=1, 245 DA=9). Furthermore, as for packet P1, the entire journey of packet 246 P3 is contained within domain D. 248 Node 2 may thus rightfully insert an SRH on packet P3 to implement a 249 sub-50 milliseconds FRR operation upon the loss of the link 2-to-3 250 and node 5 can remove this SRH. 252 The transparency of the service is guaranteed: the insertion and 253 removal of the SRH on packet P3 has no impact on packet P2. P2 at 254 the exit of the domain D is the same as at the entrance of the domain 255 D. 257 Customers of the transit service offered by domain D do demand FRR 258 services. The 50 millisecond FRR operation provides a much better 259 service availability than 100's to 1000's of milliseconds of loss for 260 each routing transition. 262 3.1. Example: SDWAN 264 An illustration example of transit through a source domain is given 265 by [I-D.dukes-sr-for-sdwan], and consist of the following: 267 o An ingress SDWAN Edge node encrypts and encapsulates incoming IPv4 268 or IPv6 packets in an IPv6 header; 270 o The ingress node inserts an SRH with a binding SID; 272 o The use of the binding SID is an explicit agreement within the 273 source domain to apply a given SLA to the traffic containing the 274 binding SID; 276 o As the packet traverses the source domain, the binding SID and the 277 SRH containing it MAY be removed (if the binding SID was a PSP 278 SID); 280 o A new SRH MAY be inserted within the source domain, corresponding 281 to the path represented by the binding SID, and this SRH MAY be 282 removed before the packet exits the source domain (again depending 283 on the last SID in the SID list and whether or not it was a PSP 284 SID). 286 Using the example topology in Figure 1: 288 o Router 1 receives a packet destined to B, which it encrypts and 289 encapsulates in an IPv6 header destined to router 9; 291 o Router 1 inserts an SRH containing a binding SID S2.1 (a binding 292 SID at 2,) to receive a path with a negotiated SLA, and sends the 293 packet toward S1 with an outer header and SRH of: 294 (SA=1,DA=S2.1)(9,S2.1;SL=1) 296 o Router 2 receives the packet and perform PSP for S2.1 298 o Router 2 inserts a new SRH with segment list 300 o Once the packet reaches its egress router (router 9) the SRH has 301 been removed (if S4 was a PSP SID), the outer IPv6 header is 302 removed, the inner packet decrypted and the original packet is 303 forwarded externally toward B. 305 4. SRH insertion in Source Domain 307 This document reminds that for a packet whose journey is 308 completely contained within its source domain, it does not matter 309 where the IPv6 extension header insertion is done. 311 It could be at the source or at the first-hop router or at any 312 node of the source domain. 314 The source domain owns the packet and decides the location, which 315 suits it best. 317 During the packet journey in the source domain, any node in the 318 source domain may insert an SRH and the egress node MUST remove 319 both the outer IPv6 header and inserted SRH. 321 In conclusion, in a context of a controlled/trusted domain, the 322 insertion of SRHs in packets that are sourced within the domain is 323 useful, required and also harmless. Hence, a context-less ban of 324 IPv6 extension header insertion does not make sense. 326 5. Security Considerations 328 This document proposes to insert an SRH to a transit packet if 329 such packet is originated and destined within a controlled/trusted 330 domain. Typically, when an operator encapsulates an externally 331 received packet and sends this packet in a tunneled mode from 332 ingress to egress, insertion of SRH is safe and confined within 333 the operator's infrastructure. In such conditions, the security 334 of the original packet is not compromised by header insertion and 335 the packet leaves the operator's domain without the any header 336 that the operator may have added. 338 A controlled/trusted domain can operate SRv6-based services for 339 internal traffic while preventing any external traffic from 340 accessing these internal SRv6-based services. Several mechanisms 341 exists and are currently used by operators. Here follows a non- 342 exhaustive example list: 344 o Access-lists (ACL) on the each externally facing interface in 345 order to drop any incoming traffic with SA or DA belonging to the 346 internal SID space. 348 o ACL to prevent access to local SIDs from outside the operator's 349 infrastructure. 351 o Support Unicast-RPF on source address on external interface. 353 6. IANA Considerations 355 This document doesn't introduce any IANA request. 357 7. Manageability Considerations 359 TBD 361 8. Contributors 363 TBD 365 9. Acknowledgements 367 TBD 369 10. References 370 10.1. Normative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, 374 DOI 10.17487/RFC2119, March 1997, 375 . 377 10.2. Informative References 379 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 380 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 381 and P. Francois, "Abstract", draft-bashandy-rtgwg-segment- 382 routing-ti-lfa-00 (work in progress), February 2017. 384 [I-D.filsfils-spring-segment-routing-policy] 385 Filsfils, C., Sivabalan, S., Yoyer, D., Nanduri, M., Lin, 386 S., bogdanov@google.com, b., Horneffer, M., Clad, F., 387 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 388 Routing Policy for Traffic Engineering", draft-filsfils- 389 spring-segment-routing-policy-00 (work in progress), 390 February 2017. 392 [I-D.filsfils-spring-srv6-network-programming] 393 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 394 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 395 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 396 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 397 Sharif, M., Ayyangar, A., Mynam, S., Bashandy, A., Raza, 398 K., Dukes, D., Clad, F., and P. Camarillo, "SRv6 Network 399 Programming", draft-filsfils-spring-srv6-network- 400 programming-00 (work in progress), March 2017. 402 [I-D.ietf-6man-segment-routing-header] 403 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 404 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 405 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 406 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 407 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 408 segment-routing-header-06 (work in progress), March 2017. 410 [I-D.dukes-sr-for-sdwan] 411 Dukes, D., Filsfils, C., Dawra, G., Camirillo, P., Clad, F., 412 Salsano, S., draft-dukes-sr-for-sdwan-00 (work in progress) 413 October 2017. 415 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 416 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 417 Provider Edge Routers (6PE)", RFC 4798, 418 DOI 10.17487/RFC4798, February 2007, 419 . 421 Authors' Addresses 423 Daniel Voyer (editor) 424 Bell Canada 425 Montreal 426 CA 428 Email: daniel.voyer@bell.ca 430 Daniel Bernier 431 Bell Canada 432 Montreal 433 CA 435 Email: daniel.bernier@bell.ca 437 John Leddy 438 Comcast 439 4100 East Dry Creek Road 440 Centennial, CO 80122 441 US 443 Email: John_Leddy@comcast.com 445 Clarence Filsfils 446 Cisco Systems, Inc. 447 Brussels 448 BE 450 Email: cfilsfil@cisco.com 452 Stefano Previdi 453 Individual Contributor 454 Italy 456 Email: stefano@previdi.net 458 Darren Dukes 459 Cisco Systems 460 Canada 462 Email: ddukes@cisco.com 463 Stefano Salsano 464 Universita di Roma Tor Vergata 465 Rome 466 IT 468 Email: stefano.salsano@uniroma2.it 470 Antonio Cianfrani 471 Universita La Sapienza 472 Rome 473 Italy 475 Email: antonio.cianfrani@uniroma1.it 477 David Lebrun 478 Universite Catholique de Louvain 479 Place Ste Barbe, 2 480 Louvain-la-Neuve, 1348 481 Belgium 483 Email: david.lebrun@uclouvain.be 485 Olivier Bonaventure 486 Universite Catholique de Louvain 487 Place Ste Barbe, 2 488 Louvain-la-Neuve, 1348 489 Belgium 491 Email: olivier.bonaventure@uclouvain.be 493 Prem Jonnalagadda 494 Barefoot Networks 495 US 497 Email: prem@barefootnetworks.com 499 Milad Sharif 500 Barefoot Networks 501 US 503 Email: msharif@barefootnetworks.com 505 Hani Elmalky 506 Ericsson 507 US 509 Email: hani.elmalky@ericsson.com 510 Ahmed Abdelsalam 511 Gran Sasso Science Institute 512 IT 514 Email: ahmed.abdelsalam@gssi.infn.it 516 Robert Raszuk 517 Bloomberg 519 Email: robert@raszuk.net 521 Arthi Ayyangar 522 Arista 524 Email: arthi@arista.com 526 Dirk Steinberg 527 Steinberg Consulting 528 DE 530 Email: dws@dirksteinberg.de 532 Wim Henderickx 533 Nokia 534 BE 536 Email: wim.henderickx@nokia.com 538 Jeff Tantsura 539 Individual 541 Email: jefftant@gmail.com