idnits 2.17.1 draft-voyer-6man-extension-header-insertion-07.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 (September 20, 2019) is 1678 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 352 == Missing Reference: 'SRH' is mentioned on line 401, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-22 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-01 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: Standards Track C. Filsfils 5 Expires: March 23, 2020 D. Dukes, Ed. 6 Cisco Systems, Inc. 7 S. Matsushima 8 Softbank 9 J. Leddy 10 Individual Contributor 11 September 20, 2019 13 Insertion of IPv6 Segment Routing Headers in a Controlled Domain 14 draft-voyer-6man-extension-header-insertion-07 16 Abstract 18 Traffic traversing an SR domain is encapsulated in an outer IPv6 19 header for its journey through the SR domain. 21 To implement transport services strictly within the SR domain, the SR 22 domain may require insertion or removal of an SRH after the outer 23 IPv6 header of the SR domain. Any segment within the SRH is strictly 24 contained within the SR domain. 26 The SR domain always preserves the end-to-end integrity of traffic 27 traversing it. No extension header is manipulated, inserted or 28 removed from an inner transported packet. The packet leaving the SR 29 domain is exactly the same (except for the hop-limit update) as the 30 packet entering the SR domain. 32 The SR domain is designed with link MTU sufficiently greater than the 33 MTU at the ingress edge of the SR domain. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on March 23, 2020. 58 Copyright Notice 60 Copyright (c) 2019 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. SRH-based Services Within the SR Domain . . . . . . . . . . . 3 77 2.1. Actions Within the SR Domain . . . . . . . . . . . . . . 5 78 2.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. Detailed Description of Actions in the SR Domain . . . . . . 6 80 3.1. Action 2: SRH Insertion . . . . . . . . . . . . . . . . . 6 81 3.2. Action 3: SRH Removal . . . . . . . . . . . . . . . . . . 7 82 4. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 7 83 4.1. ICMP Error Processing . . . . . . . . . . . . . . . . . . 8 84 4.2. Packet Too Big . . . . . . . . . . . . . . . . . . . . . 8 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 6. Action Within the SR Domain and RFC8200 . . . . . . . . . . . 9 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 91 9.2. Informative References . . . . . . . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction 96 This document describes insertion and removal of SRH within an SR 97 domain, and explores why and how it is safe to do so. 99 2. SRH-based Services Within the SR Domain 101 An SR Domain is defined in [RFC8402]. 103 Section 5.2 of [I-D.ietf-6man-segment-routing-header] further 104 describes the SR domain as a single system with delegation among 105 components. It states: 107 All intra SR Domain packets are of the SR Domain. The IPv6 header 108 is originated by a node of the SR Domain, and is destined to a 109 node of the SR Domain. 111 All inter domain packets are encapsulated for the part of the 112 packet journey that is within the SR Domain. The outer IPv6 113 header is originated by a node of the SR Domain, and is destined 114 to a node of the SR Domain. 116 In other words, all packets within the SR domain have a source and 117 destination address within the SR Domain. 119 The following illustration shows how traffic is encapsulated within 120 an SR domain, and how an SRH is inserted and processed for a packet 121 traversing the SR domain. 123 + * * * * * * * * * * * * * * * * * * * * + 125 * * 126 [1]----[3]--------[5]----------------[6]---------[4]---[2] 127 * | | * 128 | | 129 * | | * 130 [7]----------------[8] 131 * * 133 + * * * * * * * SR Domain * * * * * * * + 135 Figure 1 137 o 3 and 4 are SR Domain edge routers 139 o 5, 6, 7, and 8 are all SR Domain routers 141 o 1 and 2 are hosts outside the SR Domain 142 o The SR domain is secured as per Section 5.1 of 143 [I-D.ietf-6man-segment-routing-header] and no external packet can 144 enter the domain with a destination address equal to a segment of 145 the domain. 147 When host 1 sends a packet to host 2, the packet is 149 P1: (A1,A2) 151 The SR Domain ingress router 3 receives P1 and steers it to SR Domain 152 egress router 4 via an SR Policy . Router 3 encapsulates the 153 received packet in an outer IPv6 header with an SRH. The packet is 155 P2: (A3, S6)(S4; SL=1)(A1, A2) 157 At node 5, P2 is steered through an SR Policy resulting 158 in the insertion of an SRH. S8.PSP is a segment at node 8 that 159 removes the SRH when segments left is decremented to 0 161 P3: (A3, S7)(S6,S8.PSP; SL=2)(S4;SL=1)(A1, A2) 163 At node 7, S7 is processed. The outer most SRH segments left (SL) is 164 decremented and S8 is placed in the destination address of the outer 165 IPv6 header resulting in 167 P4: (A3, S8.PSP)(S6,S8.PSP; SL=1)(S4;SL=1)(A1, A2) 169 At node 8, S8.PSP is processed. The outer most SRH segments left is 170 decremented to 0 and S6 is placed in the destination address of the 171 outer IPv6 header. Since S8.PSP decrements SL to 0 it also removes 172 the SRH resulting in 174 P5: (A3, S6)(S4; SL=1)(A1, A2) 176 At node 6, S6 is processed. SL is decremented and S4 is placed in 177 the destination address of the outer IPv6 header 179 P6: (A3, S4)(S4; SL=0)(A1, A2) 181 At node 4, S4 is processed and the outer IPv6 header chain is removed 182 resulting in 184 P7: (A1, A2) 186 2.1. Actions Within the SR Domain 188 The illustration above shows the possible actions taken in the SR 189 domain. They can be categorized as follows: 191 Action 1 IPv6 encapsulation and SRH insertion at SR Domain ingress 192 edge. 193 Described in [I-D.ietf-6man-segment-routing-header] 195 Action 2 SRH insertion at a node within the SR Domain applying an SR 196 policy to packets sourced and destined to nodes within the 197 SR Domain. The SR Policy may be applied for multiple 198 reasons including TILFA 199 [I-D.ietf-rtgwg-segment-routing-ti-lfa], or intermediate 200 node TE [I-D.ietf-spring-segment-routing-policy]. All 201 segments are within the SR domain. 202 Described in this document 204 Action 3 SRH processing at a segment endpoint, with PSP to remove an 205 SRH when SL is decremented to zero. 206 Described in this document and formally defined as an 207 instruction of the network programming model 208 [I-D.ietf-spring-srv6-network-programming] 210 Action 4 IPv6 and SRH decapsulation at SR domain egress edge 211 Described in draft-ietf-6man-segment-routing-header 213 2.2. Constraints 215 This document defines several constraints on the SR domain that 216 enable the safe insertion and removal of an SRH within the SR domain. 218 Source and destination address: 219 All traffic within the SR domain has IPv6 source and 220 destination address within the SR domain. 222 SRH without additional extension headers: 223 Within the context of this document and the described SRH use- 224 case within the SR domain, the SR domain can guarantee that SRH 225 is the sole extension header after the outer IPv6 header. 227 SRH insertion: 228 Only traffic sourced from and destined to nodes in the SR 229 domain may have an SRH inserted. 231 SRH segment list: 232 Segments in the SRH segment list are all within the SR domain 234 MTU of the SR domain: 235 SR domain link MTU is sufficiently greater than the MTU at the 236 ingress edge of the SR domain. The difference in MTUs should 237 be greater than the sum of the IPv6 header length and the 238 expected length of all inserted SRH within the SR domain. 240 Packet size in the SR domain: Packet size in the SR domain: 241 All traffic forwarded in the SR domain has a packet size less 242 than the MTU of the SR domain. 244 This document does not limit the ability for future documents to 245 widen the scope. 247 These constraints reflect the design practices used in commercial 248 SRv6 deployments reported in 249 [I-D.matsushima-spring-srv6-deployment-status] 251 3. Detailed Description of Actions in the SR Domain 253 Within an SR domain, constrained as defined in Section 2.1, there are 254 two actions that require detailed description in this document. 256 Action 2: SRH insertion at a node within the SR Domain 258 Action 3: SRH processing at a segment endpoint with PSP to remove the 259 SRH when SL is decremented to zero. 261 3.1. Action 2: SRH Insertion 263 When an SRH is inserted by an intermediate node it walks the IPv6 264 header chain to the first header after the IPv6 header and inserts 265 the SRH prior to that header. 267 +---------------+----------------------+------------ 268 | IPv6 header | SRH | IPv4 header 269 | | | 270 | Next Header = | Next Header = | 271 | SRH | IPv4 | 272 +---------------+----------------------+------------ 273 ^-SRH insertion here 275 Figure 2 277 An SR Policy headend within the SR domain inserts an SRH as follows: 279 1. Determine where to insert the SRH. 281 2. Copy the destination address from the IPv6 header to Segment 282 List[0] of the SRH to be inserted. This ensures the original 283 destination address is restored upon execution of the final 284 segment in the inserted SRH. 286 3. Increase the IPv6 header payload length field by the length in 287 bytes of the inserted SRH. 288 If the resulting payload length exceeds 2^16 bytes generate an 289 ICMP "Packet To Big" error message to the source with an MTU of 290 2^16 minus the length in bytes of the SRH and discard the packet. 291 Note: this does not occur in reported deployments given the MTU 292 design constraint. 294 4. Set the SRH next header field to the value in the next header 295 field of the header that will precede the SRH. 297 5. Set the next header field of the header that will precede the SRH 298 to the routing extension header (43) 300 6. Set the IPv6 destination address to the first segment in the 301 segment list of the SRH to be inserted. This segment may or may 302 not be present in the SRH depending on the use of a reduced SRH, 303 see section 4.1.1 of [I-D.ietf-6man-segment-routing-header]. 305 7. Insert the SRH into the packet at the location it should be 306 inserted and resubmit the packet to the IPv6 module for 307 transmission to the new destination. 309 3.2. Action 3: SRH Removal 311 An endpoint of the SRH removes an SRH of the SR domain as follows: 313 1. Decrement payload length by the length in bytes of the SRH being 314 removed. 316 2. Copy the next header value of the SRH being removed to the next 317 header value of the preceding header. 319 3. Remove the SRH from the packet. 321 4. MTU Considerations 323 This document assumes that the SR domain link MTU is sufficiently 324 greater than the MTU at the ingress edge of the SR domain. The 325 difference in MTUs should be greater than the sum of the IPv6 header 326 length and the expected length of all inserted SRH within the SR 327 domain. 329 This is in-line with well known mitigation techniques that have been 330 deployed since the early 2000's for the MPLS-based FRR services and 331 numerous VPN services that involve deploying a greater MTU value in 332 the core than at the ingress edge of a domain. 334 This is also recommended in section 5.3 of 335 [I-D.ietf-6man-segment-routing-header]. 337 4.1. ICMP Error Processing 339 ICMP errors may be generated for packets with one or more SRH 340 present. In such a case the ICMP process of a source node may 341 receive an ICMP error packet with more SRH's than it originated. 343 Processing of such packets follows the processing defined in section 344 5.4 of [I-D.ietf-6man-segment-routing-header] with relevant text 345 copied below: 347 o Walk all extension headers of the invoking IPv6 packet to the 348 routing extension header preceding the upper layer header. 350 * If routing header is type 4 (SRH) 352 + Use the SID at Segment List[0] as the destination address of 353 the invoking packet. 355 ICMP errors are then processed by upper layer transports as defined 356 in [RFC4443]. 358 For IP packets encapsulated in an outer IPv6 header, ICMP error 359 handling is as defined in [RFC2473]. 361 4.2. Packet Too Big 363 When a larger MTU is deployed within the SR domain than at the 364 ingress edge ICMP "Packet Too Big" error messages should not be 365 generated within the SR domain. 367 They must be handled regardless, so in addition to the ICMP 368 processing defined in this document, a source node in the SR domain 369 receiving and processing an ICMP error "Packet Too Big" message 370 SHOULD decrement the MTU received in the message by the size in bytes 371 of the SRH's present in the invoking packet. This is required to 372 compensate for any SRH inserted along the packets path. 374 The SR domain ingress edge processing the ICMP error SHOULD log the 375 error and decrement the ingress edge MTU for traffic traversing the 376 SR domain (if it's greater than the IPv6 minimum MTU of 1280 bytes) 377 or fragment the encapsulated packet to avoid reducing the ingress 378 edge MTU. 380 5. Security Considerations 382 To implement transport services strictly within the SR domain, the SR 383 domain may require the insertion or removal of an SRH after the outer 384 IPv6 header of the SR domain. 386 This document details the actions and reminds the reader of the 387 conditions that ensure 389 1. the integrity of the transported inner packet, 391 2. the security of the SR domain, 393 3. the non-leakage of intra SR domain SRH on external traffic. 395 The SR domain always preserves the end-to-end integrity of traffic 396 traversing it. No extension header is manipulated, inserted or 397 removed from an inner transported packet. The packet leaving the SR 398 domain is exactly the same (except for the hop-limit update) as the 399 packet entering the SR domain. 401 The SR domain is secured as per Section 5.1 of [SRH] and no external 402 packet can enter the domain with a destination address equal to a 403 segment of the domain. 405 An SRH of the SR domain is only added after the outer IPv6 header. 406 An SRH of the SR domain only contains segments within the domain. 407 Under these conditions, the SRH of the SR domain cannot leave the 408 domain. Additionally, egress edge nodes SHOULD ensure packets 409 sourced from within the SR domain (IPv6 source prefix), destined to 410 nodes outside the SR domain (IPv6 destination prefix) do not contain 411 an SRH. 413 All security considerations discussed in 414 [I-D.ietf-6man-segment-routing-header] are equally applicable to an 415 SRH applied by a non-source node within the SR domain. 417 6. Action Within the SR Domain and RFC8200 419 The four actions within the SR domain have the following association 420 with [RFC8200] 422 Action 1 IPv6 encapsulation and optional insertion of SRH at the SR 423 domain ingress edge generates a new IPv6 packet. 425 Insertion of the SRH, if done, is obviously intended by the 426 SR source node. 427 The source node also intends for the SR domain to apply any 428 other SRH required. 429 This is in-line with RFC8200 as the source of the outer 430 header inserts the extension header. 432 Action 2 SRH insertion at a node within the SR Domain. 433 Insertion of the SRH at a node within the SR domain is 434 intended by any source node in the SR domain. 435 The source node has ensured the packet length it sends is 436 sufficient for the domain to insert an SRH. 438 Action 3 SRH processing and removal at a segment endpoint node 439 The node in the destination address parses the SRH and 440 removes the SRH when segments left is decremented to 0. 441 The node removing the SRH is the destination address of the 442 packet as per RFC8200. 444 Action 4 IPv6 and SRH decapsulation at SR domain egress edge 445 The node in the destination address of the IPv6 header 446 decapsulates the outer IPv6 header when no further segments 447 are left. 448 This is in-line with [RFC8200] as the destination of the 449 outer header removes the outer header and its extension 450 header. 452 Actions 1, 3, and 4 are all directly supported by [RFC8200] section 4 454 Extension headers (except for the Hop-by-Hop Options header) are 455 not processed, inserted, or deleted by any node along a packet's 456 delivery path, until the packet reaches the node (or each of the 457 set of nodes, in the case of multicast) identified in the 458 Destination Address field of the IPv6 header. 460 Each extension header should occur at most once, except for the 461 Destination Options header, which should occur at most twice (once 462 before a Routing header and once before the upper-layer header). 464 IPv6 nodes must accept and attempt to process extension headers in 465 any order and occurring any number of times in the same packet 467 Action 2 inserts an SRH in a packet within the SR domain at a node 468 not in the destination address, and inserts more than one SRH in a 469 packet. This does not appear to be permitted by the statements 470 quoted above from RFC8200. However, the restrictions above are not 471 applicable within the SR domain. Every source node participating in 472 the SR domain expects SRH insertion, relies on it for services 473 provided by the SR domain, correctly processes ICMP errors, and 474 according to RFC8200 must process multiple SRH in the same packet. 476 7. IANA Considerations 478 This document doesn't introduce any IANA request. 480 8. Contributors 482 The authors would like to thank the following for their 483 contributions: Robert Raszuk, Stefano Previdi, Stefano Salsano, 484 Antonio Cianfrani, David Lebrun, Olivier Bonaventure, Prem 485 Jonnalagadda, Milad Sharif, Hani Elmalky, Ahmed Abdelsalam, Arthi 486 Ayyangar, Dirk Steinberg, Wim Henderickx. 488 9. References 490 9.1. Normative References 492 [I-D.ietf-6man-segment-routing-header] 493 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 494 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 495 Routing Header (SRH)", draft-ietf-6man-segment-routing- 496 header-22 (work in progress), August 2019. 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, 500 DOI 10.17487/RFC2119, March 1997, 501 . 503 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 504 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 505 December 1998, . 507 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 508 Control Message Protocol (ICMPv6) for the Internet 509 Protocol Version 6 (IPv6) Specification", STD 89, 510 RFC 4443, DOI 10.17487/RFC4443, March 2006, 511 . 513 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 514 (IPv6) Specification", STD 86, RFC 8200, 515 DOI 10.17487/RFC8200, July 2017, 516 . 518 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 519 Decraene, B., Litkowski, S., and R. Shakir, "Segment 520 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 521 July 2018, . 523 9.2. Informative References 525 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 526 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 527 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 528 Camarillo, "Topology Independent Fast Reroute using 529 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 530 lfa-01 (work in progress), March 2019. 532 [I-D.ietf-spring-segment-routing-policy] 533 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 534 bogdanov@google.com, b., and P. Mattes, "Segment Routing 535 Policy Architecture", draft-ietf-spring-segment-routing- 536 policy-03 (work in progress), May 2019. 538 [I-D.ietf-spring-srv6-network-programming] 539 Filsfils, C., Camarillo, P., Leddy, J., 540 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 541 Network Programming", draft-ietf-spring-srv6-network- 542 programming-01 (work in progress), July 2019. 544 [I-D.matsushima-spring-srv6-deployment-status] 545 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 546 Implementation and Deployment Status", draft-matsushima- 547 spring-srv6-deployment-status-01 (work in progress), May 548 2019. 550 Authors' Addresses 552 Daniel Voyer (editor) 553 Bell Canada 555 Email: daniel.voyer@bell.ca 557 Clarence Filsfils 558 Cisco Systems, Inc. 559 Brussels 560 BE 562 Email: cfilsfil@cisco.com 563 Darren Dukes (editor) 564 Cisco Systems, Inc. 565 Ottawa 566 Canada 568 Email: ddukes@cisco.com 570 Satoru Matsushima 571 Softbank 573 Email: satoru.matsushima@g.softbank.co.jp 575 John Leddy 576 Individual Contributor 577 USA 579 Email: john@leddy.net