idnits 2.17.1 draft-voyer-6man-extension-header-insertion-01.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 -- 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 Summary: 0 errors (**), 0 flaws (~~), 5 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: April 2, 2018 J. Leddy 6 Comcast 7 C. Filsfils 8 S. Previdi, Ed. 9 Cisco Systems, Inc. 10 S. Salsano 11 Universita di Roma Tor Vergata 12 A. Cianfrani 13 Universita La Sapienza 14 D. Lebrun 15 O. Bonaventure 16 Universite Catholique de Louvain 17 P. Jonnalagadda 18 M. Sharif 19 Barefoot Networks 20 H. Elmalky 21 Ericsson 22 A. Abdelsalam 23 Gran Sasso Science Institute 24 R. Raszuk 25 Bloomberg 26 A. Ayyangar 27 Arista 28 D. Steinberg 29 Steinberg Consulting 30 W. Henderickx 31 Nokia 32 September 29, 2017 34 Insertion of IPv6 Segment Routing Headers in a Controlled Domain 35 draft-voyer-6man-extension-header-insertion-01 37 Abstract 39 The network operator and vendor community has clearly indicated that 40 IPv6 header insertion is useful and required. This is notably the 41 case when the entire journey of the packet remains in its source 42 domain. In such a context, it does not matter where the extension 43 header is inserted. The source domain may decide to place the IPv6 44 extension header insertion where it suits its best: at the source of 45 the packet or at any midpoint within the source domain. 47 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 [RFC2119]. 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at http://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 Copyright Notice 70 Copyright (c) 2017 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 2. Source Domain and Packet Journey . . . . . . . . . . . . . . 3 87 2.1. Example: 6PE . . . . . . . . . . . . . . . . . . . . . . 4 88 3. Transit through a Source Domain . . . . . . . . . . . . . . . 5 89 4. SRH insertion in Source Domain . . . . . . . . . . . . . . . 6 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 92 7. Manageability Considerations . . . . . . . . . . . . . . . . 7 93 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 97 10.2. Informative References . . . . . . . . . . . . . . . . . 8 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 100 1. Introduction 102 We define the concept of "domain" as the set of nodes under the same 103 administration. For example, a network operator infrastructure 104 including routers and links grouped into BGP autonomous systems (ASs) 105 and routing domains (running OSFP or IS-IS). 107 We define "source domain" as the domain of the source of the packet. 109 2. Source Domain and Packet Journey 111 (--- Source Domain ---) 112 ( ) 113 ( 1-----2-----3-----9 ) 114 ( | | ) 115 ( 4-----5 ) 116 (---------------------) 118 Figure 1: Source Domain 120 In the previous diagram: 122 o All the nodes 1 to 9 are in the same domain D. 124 o Node 1 originates a packet P1 destined to 9 (SA=1, DA=9). 126 o Domain D runs a link-state routing protocols which implements the 127 Fast Reroute (FRR) service through the Topology Independent Loop 128 Free Alternates (TI-LFA, 129 [I-D.bashandy-rtgwg-segment-routing-ti-lfa]). 131 o All link metrics are set to 10. 133 o Node 2's TI-LFA precomputed backup path for the destination 9 is 134 the Segment Routing Policy <5, 9> via outgoing interface (OIF) to 135 node 4 according to [I-D.filsfils-spring-segment-routing-policy], 136 [I-D.filsfils-spring-srv6-network-programming] and 137 [I-D.ietf-6man-segment-routing-header]. 139 Within the 50 milliseconds of link 2-3 failure detection, node 2 140 reroutes the traffic destined to 9 by inserting the precomputed 141 segment routing header (SRH) with SID list <5, 9> and forwards the 142 packet to node 4. Node 4 forwards based on DA=5 to neighbor 5. Node 143 5 updates the DA to 9 and removes the SRH. Node 9 receives the 144 packet with (SA=1, DA=9). 146 This FRR service is clearly beneficial for the operator of domain D: 147 without this FRR operation, depending on the scale of the domain and 148 the quality of the routing convergence implementation, traffic could 149 be dropped for hundreds to thousands of milliseconds waiting for the 150 routing plane to converge. 152 This FRR service is largely deployed with MPLS. 154 It is important to note that the operators industry is strongly 155 requiring the same TI-LFA FRR service without the need to deploy or 156 maintain the MPLS layer. 158 Obviously, this FRR service increases the size of the packet during 159 its journey within domain D. This is well-known to operators. Well- 160 known mitigation techniques have been deployed for more than 15 years 161 for the MPLS-based FRR service and the numerous VPN services. The 162 same exact technique can be used which consists of deploying an 163 infrastructure capable of an MTU value higher in the core than at the 164 ingress edge. 166 2.1. Example: 6PE 168 An illustrative example of packet size increasing while in transit is 169 given by the 6PE use case ([RFC4798]) and consists of the following: 171 o An ingress router encapsulates incoming IPv6 packets into a MPLS 172 label stack. 174 o The ingress router forwards the encapsulated packet across the 175 MPLS core infrastructure of the operator. 177 o While transiting in the core, the size of the label stack (hence 178 the size of the packet) may increase when additional labels are 179 pushed on top of the packet due to services such as traffic 180 engineering (TE) and/or fast reroute (FRR). 182 o Once the packet reaches the egress router, the label stack is 183 removed and the packet is sent out of the operator network as an 184 IPv6 packet. 186 Using the example topology in Figure 1: 188 o Router 1 receives an incoming IPv6 packet, classifies it and does 189 push a label corresponding to the egress router this packet must 190 reach (router 9). At this stage the packet size has already 191 increased by the size of one label (32 bits). 193 o In addition, router 1 is configured with a policy consisting of a 194 traffic engineered path (2, 4, 5, 9) represented by an additional 195 label. At this stage the packet size has increased by the size of 196 two labels). 198 o While in transit in the traffic engineered path, a link may fail 199 and fast reroute (FRR) may have been provisioned so that the 200 packet is immediately re-routed (e.g., by router 4) using an 201 additional label. At this stage the packet size has increased by 202 the size of three labels. 204 o It has also to be noted that the packet may be part of a virtual 205 private network (VPN) service in which case it will have an 206 additional label corresponding to the VPN the packet belongs to. 207 In this case the packet size has increased by the size of four 208 labels. 210 o Once the packet reaches its egress router (router 9) the label 211 stack is consumed, the packet shape and size is restored to its 212 original state and the packet is forwarded externally, as a plain 213 IPv6 packet. 215 3. Transit through a Source Domain 217 (--- Source Domain ---) 218 ( ) 219 A---( 1-----2-----3-----9 )---B 220 ( | | ) 221 ( 4-----5 ) 222 (---------------------) 224 Figure 2: Transit Through a Source Domain 226 We now consider a packet P2 sent from A to B where A and B are 227 external nodes to the domain D. 229 We assume that when node 1 receives the packet, for service 230 transparency reason (the packet that exits the domain MUST be the 231 same as when it entered the domain), node 1 encapsulates the packet 232 P2 in an outer IPv6 header with SA=1 and DA=9. We call the resulting 233 packet P3. 235 Note that node 1 in Domain D is the source of a new IPv6 packet (P3) 236 that encapsulates P2, therefore we refer to this scenario as "Transit 237 Through a Source domain". 239 From the viewpoint of domain D, packet P3 is the same as packet P1 of 240 the previous use-case. Indeed, domain D only considers the outer 241 header and from that viewpoint, the outer header is the same: (SA=1, 242 DA=9). Furthermore, as for packet P1, the entire journey of packet 243 P3 is contained within domain D. 245 Node 2 may thus rightfully insert an SRH on packet P3 to implement a 246 sub-50 milliseconds FRR operation upon the loss of the link 2-to-3 247 and node 5 can remove this SRH. 249 The transparency of the service is guaranteed: the insertion and 250 removal of the SRH on packet P3 has no impact on packet P2. P2 at 251 the exit of the domain D is the same as at the entrance of the domain 252 D. 254 Customers of the transit service offered by domain D do demand FRR 255 services. The 50 millisecond FRR operation provides a much better 256 service availability than 100's to 1000's of milliseconds of loss for 257 each routing transition. 259 4. SRH insertion in Source Domain 261 This document reminds that for a packet whose journey is completely 262 contained within its source domain, it does not matter where the IPv6 263 extension header insertion is done. 265 It could be at the source or at the first-hop router or at any node 266 of the source domain. 268 The source domain owns the packet and decides the location, which 269 suits it best. 271 During the packet journey in the source domain, any node in the 272 source domain may insert an SRH and the egress node MUST remove both 273 the outer IPv6 header and inserted SRH. 275 In conclusion, in a context of a controlled/trusted domain, the 276 insertion of SRHs in packets that are sourced within the domain is 277 useful, required and also harmless. Hence, a context-less ban of 278 IPv6 extension header insertion does not make sense. 280 5. Security Considerations 282 This document proposes to insert an SRH to a transit packet if such 283 packet is originated and destined within a controlled/trusted domain. 284 Typically, when an operator encapsulates an externally received 285 packet and sends this packet in a tunneled mode from ingress to 286 egress, insertion of SRH is safe and confined within the operator's 287 infrastructure. In such conditions, the security of the original 288 packet is not compromised by header insertion and the packet leaves 289 the operator's domain without the any header that the operator may 290 have added. 292 A controlled/trusted domain can operate SRv6-based services for 293 internal traffic while preventing any external traffic from accessing 294 these internal SRv6-based services. Several mechanisms exists and 295 are currently used by operators. Here follows a non-exhaustive 296 example list: 298 o Access-lists (ACL) on the each externally facing interface in 299 order to drop any incoming traffic with SA or DA belonging to the 300 internal SID space. 302 o ACL to prevent access to local SIDs from outside the operator's 303 infrastructure. 305 o Support Unicast-RPF on source address on external interface. 307 6. IANA Considerations 309 This document doesn't introduce any IANA request. 311 7. Manageability Considerations 313 TBD 315 8. Contributors 317 TBD 319 9. Acknowledgements 321 TBD 323 10. References 324 10.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 10.2. Informative References 333 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 334 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 335 and P. Francois, "Abstract", draft-bashandy-rtgwg-segment- 336 routing-ti-lfa-00 (work in progress), February 2017. 338 [I-D.filsfils-spring-segment-routing-policy] 339 Filsfils, C., Sivabalan, S., Yoyer, D., Nanduri, M., Lin, 340 S., bogdanov@google.com, b., Horneffer, M., Clad, F., 341 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 342 Routing Policy for Traffic Engineering", draft-filsfils- 343 spring-segment-routing-policy-00 (work in progress), 344 February 2017. 346 [I-D.filsfils-spring-srv6-network-programming] 347 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 348 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 349 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 350 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 351 Sharif, M., Ayyangar, A., Mynam, S., Bashandy, A., Raza, 352 K., Dukes, D., Clad, F., and P. Camarillo, "SRv6 Network 353 Programming", draft-filsfils-spring-srv6-network- 354 programming-00 (work in progress), March 2017. 356 [I-D.ietf-6man-segment-routing-header] 357 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 358 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 359 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 360 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 361 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 362 segment-routing-header-06 (work in progress), March 2017. 364 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 365 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 366 Provider Edge Routers (6PE)", RFC 4798, 367 DOI 10.17487/RFC4798, February 2007, 368 . 370 Authors' Addresses 372 Daniel Voyer 373 Bell Canada 374 Montreal 375 CA 377 Email: daniel.voyer@bell.ca 379 Daniel Bernier 380 Bell Canada 381 Montreal 382 CA 384 Email: daniel.bernier@bell.ca 386 John Leddy 387 Comcast 388 4100 East Dry Creek Road 389 Centennial, CO 80122 390 US 392 Email: John_Leddy@comcast.com 394 Clarence Filsfils 395 Cisco Systems, Inc. 396 Brussels 397 BE 399 Email: cfilsfil@cisco.com 401 Stefano Previdi (editor) 402 Cisco Systems, Inc. 403 Via Del Serafico, 200 404 Rome 00142 405 Italy 407 Email: sprevidi@cisco.com 409 Stefano Salsano 410 Universita di Roma Tor Vergata 411 Rome 412 IT 413 Email: stefano.salsano@uniroma2.it 415 Antonio Cianfrani 416 Universita La Sapienza 417 Rome 418 Italy 420 Email: antonio.cianfrani@uniroma1.it 422 David Lebrun 423 Universite Catholique de Louvain 424 Place Ste Barbe, 2 425 Louvain-la-Neuve, 1348 426 Belgium 428 Email: david.lebrun@uclouvain.be 430 Olivier Bonaventure 431 Universite Catholique de Louvain 432 Place Ste Barbe, 2 433 Louvain-la-Neuve, 1348 434 Belgium 436 Email: olivier.bonaventure@uclouvain.be 438 Prem Jonnalagadda 439 Barefoot Networks 440 US 442 Email: prem@barefootnetworks.com 444 Milad Sharif 445 Barefoot Networks 446 US 448 Email: msharif@barefootnetworks.com 450 Hani Elmalky 451 Ericsson 452 US 454 Email: hani.elmalky@ericsson.com 455 Ahmed Abdelsalam 456 Gran Sasso Science Institute 457 IT 459 Email: ahmed.abdelsalam@gssi.infn.it 461 Robert Raszuk 462 Bloomberg 464 Email: robert@raszuk.net 466 Arthi Ayyangar 467 Arista 469 Email: arthi@arista.com 471 Dirk Steinberg 472 Steinberg Consulting 473 DE 475 Email: dws@dirksteinberg.de 477 Wim Henderickx 478 Nokia 479 BE 481 Email: wim.henderickx@nokia.com 483 Jeff Tantsura 484 Individual 486 Email: jefftant@gmail.com