idnits 2.17.1 draft-bonica-spring-srv6-plus-05.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 (August 28, 2019) is 1696 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 552 -- Looks like a reference, but probably isn't: '1' on line 553 == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-05 ** Downref: Normative reference to an Experimental draft: draft-bonica-6man-comp-rtg-hdr (ref. 'I-D.bonica-6man-comp-rtg-hdr') == Outdated reference: A later version (-09) exists of draft-bonica-6man-seg-end-opt-04 == Outdated reference: A later version (-21) exists of draft-bonica-6man-vpn-dest-opt-06 == Outdated reference: A later version (-06) exists of draft-bonica-lsr-crh-isis-extensions-00 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-22 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 == Outdated reference: A later version (-02) exists of draft-li-spring-compressed-srv6-np-00 == Outdated reference: A later version (-10) exists of draft-mirsky-6man-unified-id-sr-03 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group R. Bonica 3 Internet-Draft S. Hegde 4 Intended status: Standards Track Juniper Networks 5 Expires: February 29, 2020 Y. Kamite 6 NTT Communications Corporation 7 A. Alston 8 D. Henriques 9 Liquid Telecom 10 J. Halpern 11 Ericsson 12 J. Linkova 13 Google 14 G. Chen 15 Baidu 16 August 28, 2019 18 IPv6 Support for Segment Routing: SRv6+ 19 draft-bonica-spring-srv6-plus-05 21 Abstract 23 This document describes SRv6+. SRv6+ is a Segment Routing (SR) 24 solution that leverages IPv6. It supports a wide variety of use- 25 cases while remaining in strict compliance with IPv6 specifications. 26 SRv6+ is optimized for ASIC-based forwarding devices that operate at 27 high data rates. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 29, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 65 3. Paths, Segments And Instructions . . . . . . . . . . . . . . 5 66 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Adjacency Segments . . . . . . . . . . . . . . . . . . . 6 68 4.2. Node Segments . . . . . . . . . . . . . . . . . . . . . . 7 69 5. Segment Identifiers (SID) . . . . . . . . . . . . . . . . . . 7 70 5.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. Assigning SIDs to Adjacency Segments . . . . . . . . . . 10 72 5.3. Assigning SIDs to Node Segments . . . . . . . . . . . . . 10 73 6. Service Instructions . . . . . . . . . . . . . . . . . . . . 10 74 6.1. Per-Segment . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.2. Per-Path . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7. The IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. The Routing Header . . . . . . . . . . . . . . . . . . . 12 78 7.2. The Destination Options Header . . . . . . . . . . . . . 13 79 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 14 80 9. Differences Between SRv6 and SRv6+ . . . . . . . . . . . . . 14 81 9.1. Routing Header Size . . . . . . . . . . . . . . . . . . . 14 82 9.2. Decoupling of Topological and Service Instructions . . . 16 83 9.3. Authentication . . . . . . . . . . . . . . . . . . . . . 16 84 9.4. Traffic Engineering Capability . . . . . . . . . . . . . 17 85 9.5. IP Addressing Architecture . . . . . . . . . . . . . . . 17 86 10. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 11. Operational Considerations . . . . . . . . . . . . . . . . . 18 88 11.1. Ping and Traceroute . . . . . . . . . . . . . . . . . . 18 89 11.2. ICMPv6 Rate Limitting . . . . . . . . . . . . . . . . . 18 90 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 93 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 15.1. Normative References . . . . . . . . . . . . . . . . . . 18 95 15.2. Informative References . . . . . . . . . . . . . . . . . 20 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 98 1. Overview 100 Network operators deploy Segment Routing (SR) [RFC8402] so that they 101 can forward packets through SR paths. An SR path provides 102 unidirectional connectivity from its ingress node to its egress node. 103 While an SR path can follow the least cost path from ingress to 104 egress, it can also follow any other path. 106 An SR path contains one or more segments. A segment provides 107 unidirectional connectivity from its ingress node to its egress node. 108 It includes a topological instruction that controls its behavior. 110 The topological instruction is executed on the segment ingress node. 111 It determines the segment egress node and the method by which the 112 segment ingress node forwards packets to the segment egress node. 114 Per-segment service instructions can augment a segment. Per-segment 115 service instructions, if present, are executed on the segment egress 116 node. 118 Likewise, a per-path service instruction can augment a path. The 119 per-path service instruction, if present, is executed on the path 120 egress node. Section 3 of this document illustrates the relationship 121 between SR paths, segments and instructions. 123 A Segment Identifier (SID) identifies each segment. Because there is 124 a one-to-one relationship between segments and the topological 125 instructions that control them, the SID that identifies a segment 126 also identifies the topological instruction that controls it. 128 A SID is different from the topological instruction that it 129 identifies. While a SID identifies a topological instruction, it 130 does not contain the topological instruction that it identifies. 131 Therefore, a SID can be encoded in relatively few bits, while the 132 topological instruction that it identifies may require many more bits 133 for encoding. 135 An SR path can be represented by its ingress node as an ordered 136 sequence of SIDs. In order to forward a packet through an SR path, 137 the SR ingress node encodes the SR path into the packet as an ordered 138 sequence of SIDs. It can also augment the packet with service 139 instructions. 141 Because the SR ingress node is also the first segment ingress node, 142 it executes the topological instruction associated with the first 143 segment. This causes the packet to be forwarded to the first segment 144 egress node. When the first segment egress node receives the packet, 145 it executes any per-segment service instructions that augment the 146 first segment. 148 If the SR path contains exactly one segment, the first segment egress 149 node is also the path egress node. In this case, that node executes 150 any per-path service instruction that augments the path, and SR 151 forwarding is complete. 153 If the SR path contains multiple segments, the first segment egress 154 node is also the second segment ingress node. In this case, that 155 node executes the topological instruction associated with the second 156 segment. The above-described procedure continues until the packet 157 arrives at the SR egress node. 159 In the above-described procedure, only the SR ingress node maintains 160 path information. Segment ingress and egress nodes maintain 161 information regarding the segments in which they participate, but 162 they do not maintain path information. 164 The SR architecture, described above, can leverage either an MPLS 165 [RFC3031] data plane or an IPv6 [RFC8200] data plane. SR-MPLS 166 [I-D.ietf-spring-segment-routing-mpls] leverages MPLS. SRv6 167 [I-D.ietf-spring-srv6-network-programming] 168 [I-D.ietf-6man-segment-routing-header] leverages IPv6. 170 This document describes SRv6+. SRv6+ is another SR variant that 171 leverages IPv6. It supports a wide variety of use-cases while 172 remaining in strict compliance with IPv6 specifications. SRv6+ is 173 optimized for ASIC-based forwarding devices that operate at high data 174 rates. Section 9 of this document highlights differences between 175 SRv6 and SRv6+. 177 2. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in BCP 182 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 3. Paths, Segments And Instructions 187 An SRv6+ path is determined by the segments that it contains. It can 188 be represented by its ingress node as an ordered sequence of SIDs. 190 A segment is determined by its ingress node and by the topological 191 instruction that controls its behavior. The topological instruction 192 determines the segment egress node and the method by which the 193 segment ingress node forwards packets to the segment egress node. 195 Per-segment service instructions augment, but do not determine, 196 segments. A segment ingress node can: 198 o Send one packet through a segment with one per-segment service 199 instruction. 201 o Send another packet through the same segment with a different per- 202 segment service instruction. 204 o Send another packet through the same segment without any per- 205 segment service instructions. 207 Likewise, per-path service instructions augment, but do not 208 determine, paths. 210 ---- ---- ---- ---- ---- ---- 211 |Node|----|Node|----|Node|----|Node|----|Node|----|Node| 212 | A | | B | | C | | D | | E | | F | 213 ---- ---- ---- ---- ---- ---- 214 | | | | 215 -------------------| |-------------------| 216 Segment A-C |---------| Segment D-F 217 Segment C-D 218 | | 219 ------------------------------------------------- 220 SRv6+ Path 222 Figure 1: Paths, Segments And Instructions 224 Figure 1 depicts an SRv6+ path. The path provides unidirectional 225 connectivity from its ingress node (i.e., Node A) to its egress node 226 (i.e., Node F). It contains Segment A-C, Segment C-D and Segment 227 D-F. 229 In Segment A-C, Node A is the ingress node, Node B is a transit node, 230 and Node C is the egress node. Therefore, the topological 231 instruction that controls the segment is executed on Node A, while 232 per-segment service instructions that augment the segment (if any 233 exist) are executed on Node C. 235 In Segment C-D, Node C is the ingress node and Node D is the egress 236 node. Therefore, the topological instruction that controls the 237 segment is executed on Node C, while per-segment service instructions 238 that augment the segment (if any exist) are executed on Node D. 240 In Segment D-F, Node D is the ingress node, Node E is a transit node, 241 and Node F is the egress node. Therefore, the topological 242 instruction that controls the segment is executed on Node D, while 243 per-segment service instructions that augment the segment (if any 244 exist) are executed on Node F. 246 Node F is also the path egress node. Therefore, if a per-path 247 service instruction augments the path, it is executed on Node F. 249 Segments A-C, C-D and D-F are also contained by other paths that are 250 not included in the figure. 252 4. Segment Types 254 SRv6+ supports the following segment types: 256 o Adjacency. 258 o Node. 260 Adjacency segments forward packets through a specified link that 261 connects the segment ingress node to the segment egress node. Node 262 segments forward packets through the least cost path from the segment 263 ingress node to the segment egress node. 265 Each segment type is described below. 267 4.1. Adjacency Segments 269 When a packet is submitted to an adjacency segment, the topological 270 instruction associated with that segment operates upon the packet. 271 The topological instruction executes on the segment ingress node and 272 receives the following parameters: 274 o An IPv6 address that identifies an interface on the segment egress 275 node. 277 o An interface identifier. 279 The topological instruction behaves as follows: 281 o If the interface that was received as a parameter is not 282 operational, discard the packet and send an ICMPv6 [RFC4443] 283 Destination Unreachable message (Code: 5, Source Route Failed) to 284 the packet's source node. 286 o Overwrite the packet's Destination Address with the IPv6 address 287 that was received as a parameter. 289 o Forward the packet through the above-mentioned interface. 291 For further processing details, see [I-D.bonica-6man-comp-rtg-hdr]. 293 4.2. Node Segments 295 When a packet is submitted to a node segment, the topological 296 instruction associated with that segment operates upon the packet. 297 The topological instruction executes on the segment ingress node and 298 receives an IPv6 address as a parameter. The IPv6 address identifies 299 an interface on the segment egress node. 301 The topological instruction behaves as follows: 303 o If the segment ingress node does not have a viable route to the 304 IPv6 address received as a parameter, discard the packet and send 305 an ICMPv6 Destination Unreachable message (Code:1 Net Unreachable) 306 to the packet's source node. 308 o Overwrite the packet's Destination Address with the destination 309 address that was received as a parameter. 311 o Forward the packet to the next hop along the least cost path to 312 the segment egress node. If there are multiple least cost paths 313 to the segment egress node (i.e., Equal Cost Multipath), execute 314 procedures so that all packets belonging to a flow are forwarded 315 through the same next hop. 317 For further processing details, see [I-D.bonica-6man-comp-rtg-hdr]. 319 5. Segment Identifiers (SID) 321 A Segment Identifier (SID) is an unsigned integer that identifies a 322 segment. Because there is a one-to-one relationship between segments 323 and the topological instructions that control them, the SID that 324 identifies a segment also identifies the topological instruction that 325 controls it. 327 A SID is different from the topological instruction that it 328 identifies. While a SID identifies a topological instruction, it 329 does not contain the topological instruction that it identifies. 330 Therefore, a SID can be encoded in relatively few bits, while the 331 topological instruction that it identifies may require many more bits 332 for encoding. 334 SIDs have node-local significance. This means that a segment ingress 335 node MUST identify each segment that it originates with a unique SID. 336 However, a SID that is used by one segment ingress node to identify a 337 segment that it originates can be used by another segment ingress 338 node to identify another segment. For example, SID S can identify 339 both of the following: 341 o A segment whose ingress is Node A and whose egress is Node Z. 343 o Another segment whose ingress is Node B and whose egress is also 344 node Z. 346 Although SIDs have node-local significance, an SRv6+ path can be 347 uniquely identified by its ingress node and an ordered sequence of 348 SIDs. This is because the topological instruction associated with 349 each segment determines the ingress node of the next segment (i.e., 350 the node upon which the next SID has significance.) 352 SIDs can be assigned in a manner that simplifies network operations. 353 See Section 5.2 and Section 5.3 for details. 355 5.1. Range 357 SID values range from 0 to a configurable Maximum SID Value (MSV). 358 The values 0 through 15 are reserved for future use. The following 359 are valid MSVs: 361 o 65,535 (i.e., 2**16 minus 1). 363 o 4,294,967,295 (i.e., 2**32 minus 1). 365 In order to optimize packet encoding (Section 7.1), network operators 366 can configure all nodes within an SRv6+ domain to have the smallest 367 feasible MSV. The following paragraphs explain how an operator 368 determines the smallest feasible MSV. 370 Consider an SRv6+ domain that contains 5,000 nodes connected to one 371 another by point-to-point infrastructure links. The network topology 372 is not a full-mesh. In fact, each node supports 200 point-to-point 373 infrastructure links or fewer. Given this SRv6+ domain, we will 374 determine the smallest feasible MSV under the following conditions: 376 o The SRv6+ domain contains adjacency segments only. 378 o The SRv6+ domain contains node segments only. 380 o The SRv6+ domain contains both adjacency and node segments. 382 If an SRv6+ domain contains adjacency segments only, and each node 383 creates a adjacency segment to each of its neighbors, each node will 384 create 200 segments or fewer and consume 200 SIDs or fewer. This is 385 because each node has 200 neighbors or fewer. Because SIDs have 386 node-local significance (i.e., they can be reused across nodes), the 387 smallest feasible MSV is 65,535. 389 Adding nodes to this SRv6+ domain will not increase the smallest 390 feasible MSV, so long as each node continues to support 65,519 point- 391 to-point infrastructure links or fewer. If a single node is added to 392 the domain and that node supports 65,520 infrastructure links, the 393 smallest feasible MSV will increase to 4,294,967,295. 395 If an SRv6+ domain contains node segments only, and every node 396 creates a node segment to every other node, every node will create 397 4,999 segments and consume 4,999 SIDs. This is because the domain 398 contains 5,000 nodes. Because SIDs have node-local significance 399 (i.e., they can be reused across nodes), the smallest feasible MSV is 400 65,535. 402 Adding nodes to this SRv6+ domain will not increase the smallest 403 feasible MSV until the number of nodes exceeds 65,519. When the 404 smallest feasible MSV increases, it becomes 4,294,967,295. 406 If an SRv6+ domain contains both adjacency and node segments, each 407 node will create 5,199 segments or fewer and consume 5,199 SIDs or 408 fewer. This value is the sum of the following: 410 o The number of node segments that each node will create, given that 411 every node creates a node segment to every other node (i.e., 412 4,999). 414 o The number of adjacency segments that each node will create, given 415 that each node creates a adjacency segment to each of its 416 neighbors (i.e., 200 or fewer). 418 Because SIDs have node-local significance (i.e., they can be reused 419 across nodes), the smallest feasible MSV is 65,535. 421 Adding nodes to this SRv6+ domain will not increase the smallest 422 feasible MSV until the number of nodes plus the maximum number of 423 infrastructure links per node exceeds 65,519. When the smallest 424 feasible MSV increases, it becomes 4,294,967,295. 426 5.2. Assigning SIDs to Adjacency Segments 428 Network operators can establish conventions by which they assign SIDs 429 to adjacency segments. These conventions can simplify network 430 operations. 432 For example, a network operator can reserved a range of SIDs for 433 adjacency segments. It can further divide that range into subranges, 434 so that all segments sharing a common egress node are identified by 435 SIDs from the same subrange. 437 5.3. Assigning SIDs to Node Segments 439 In order to simplify network operations, all node segments that share 440 a common egress node are identified by the same SID. In order to 441 maintain this discipline, network wide co-ordination is required. 443 For example, assume that an SRv6+ domain contains N nodes. Network 444 administrators reserve a block of N SIDs and configure one of those 445 SIDs on each node. Each node advertises its SID into the control 446 plane. When another node receives that advertisement, it creates a 447 node segment between itself and the advertising node. It also 448 associates the SID that it received in the advertisement with the 449 newly created segment. See [I-D.bonica-lsr-crh-isis-extensions] for 450 details. 452 6. Service Instructions 454 SRv6+ supports the following service instruction types: 456 o Per-segment. 458 o Per-path. 460 Each is described below. 462 6.1. Per-Segment 464 Per-segment service instructions can augment a segment. Per-segment 465 service instructions, if present, are executed on the segment egress 466 node. Because the path egress node is also a segment egress node, it 467 can execute per-segment service instructions. 469 The following are examples of per-segment service instructions: 471 o Expose a packet to a firewall policy. 473 o Expose a packet to a sampling policy. 475 Per-segment Service Instruction Identifiers identify a set of service 476 instructions. Per-segment Service Instruction Identifiers are 477 allocated and distributed by a controller. They have domain-wide 478 significance. 480 6.2. Per-Path 482 A per-path service instruction can augment a path. The per-path 483 service instruction, if present, is executed on the path egress node. 485 The following are examples of per-path service instructions: 487 o De-encapsulate a packet and forward its newly exposed payload 488 through a specified interface. 490 o De-encapsulate a packet and forward its newly exposed payload 491 using a specified routing table. 493 Per-path Service Instruction Identifiers identify per-path service 494 instructions. Per-path Service Instruction Identifiers are allocated 495 and distributed by the processing node (i.e., the path egress node). 496 They have node-local significance. This means that the path egress 497 node MUST allocate a unique Per-path Service Instruction Identifier 498 for each per-path service instruction that it instantiates. 500 7. The IPv6 Data Plane 502 SRv6+ ingress nodes generate IPv6 header chains that represent SRv6+ 503 paths. An IPv6 header chain contains an IPv6 header. It can also 504 contain one or more extension headers. 506 An extension header chain that represents an SRv6+ path can contain 507 any valid combination of IPv6 extension headers. The following 508 bullet points describe how SRv6+ leverages IPv6 extension headers: 510 o If an SRv6+ path contains multiple segments, the IPv6 header chain 511 that represents it MUST contain a Routing header. The SRv6+ path 512 MUST be encoded in the Routing header as an ordered sequence of 513 SIDs. 515 o If an SRv6+ path is augmented by a per-path service instruction, 516 the IPv6 header chain that represents it MUST contain a 517 Destination Options header. The Destination Options header MUST 518 immediately precede an upper-layer header and it MUST include a 519 Per-Path Service Instruction Identifier. 521 o If an SRv6+ path contains a segment that is augmented by a per- 522 segment service instruction, the IPv6 chain that represents it 523 MUST contain a Routing header and a Destination Options header. 524 The Destination Options header MUST immediately precede a Routing 525 header and it MUST include the Per-Segment Service Instruction 526 Identifier. 528 The following subsections describe how SRv6+ uses the Routing header 529 and the Destination Options header. 531 7.1. The Routing Header 533 SRv6+ defines two new Routing header types. Generically, they are 534 called the Compressed Routing Header (CRH) 535 [I-D.bonica-6man-comp-rtg-hdr]. More specifically, the 16-bit 536 version of the CRH is called the CRH-16, while the 32-bit version of 537 the CRH is called the CRH-32. 539 Both CRH versions contain the following fields: 541 o Next Header - Identifies the header immediately following the CRH. 543 o Hdr Ext Len - Length of the CRH. 545 o Routing Type - Identifies the Routing header variant (i.e., CRH-16 546 or CRH-32). 548 o Segments Left - The number of segments still to be traversed 549 before reaching the path egress node. 551 o SID List - Represents the SRv6+ path as an ordered list of SIDs. 552 SIDs are listed in reverse order, with SID[0] representing the 553 final segment, SID[1] representing the penultimate segment, and so 554 forth. SIDs are listed in reverse order so that Segments Left can 555 be used as an index to the SID List. The SID indexed by Segments 556 Left is called the current SID. 558 In the CRH-16, each SID list entry is encoded in 16-bits. In the 559 CRH-32, each SID list entry is encoded in 32-bits. In networks where 560 the smallest feasible MSV (Section 5.1) is greater than 65,635, 561 CRH-32 is required. Otherwise, CRH-16 is preferred. 563 As per [RFC8200], when an IPv6 node receives a packet, it examines 564 the packet's destination address. If the destination address 565 represents an interface belonging to the node, the node processes the 566 next header. If the node encounters and recognizes the CRH, it 567 processes the CRH as follows: 569 o If Segments Left equal 0, skip over the CRH and process the next 570 header in the packet. 572 o Decrement Segments Left. 574 o Search for the current SID in a local table that maps SID's to 575 topological instructions. If the current SID cannot be found in 576 that table, send an ICMPv6 Parameter Problem message to the 577 packet's Source Address and discard the packet. 579 o Execute the topological instruction found in the table as 580 described in Section 4. This causes the packet to be forwarded to 581 the segment egress node. 583 When the packet arrives at the segment egress node, the above- 584 described procedure is repeated. For further processing details, see 585 [I-D.bonica-6man-comp-rtg-hdr]. 587 7.2. The Destination Options Header 589 According to [RFC8200], the Destination Options header contains one 590 or more IPv6 options. It can occur twice within a packet, once 591 before a Routing header and once before an upper-layer header. The 592 Destination Options header that occurs before a Routing header is 593 processed by the first destination that appears in the IPv6 594 Destination Address field plus subsequent destinations that are 595 listed in the Routing header. The Destination Options header that 596 occurs before an upper-layer header is processed by the packet's 597 final destination only. 599 Therefore, SRv6+ defines the following new IPv6 options: 601 o The SRv6+ Per-Segment Service Instruction Option 602 [I-D.bonica-6man-seg-end-opt] 604 o The SRv6+ Per-Path Service Instruction Option 605 [I-D.bonica-6man-vpn-dest-opt] 607 The SRv6+ Per-Segment Service Instruction Option is encoded in a 608 Destination Options header that precedes the CRH. Therefore, it is 609 processed by every segment egress node. It includes a Per-Segment 610 Service Instruction Identifier and causes segment egress nodes to 611 execute per-segment service instructions. 613 The SRv6+ Per-Path Service Instruction Option is encoded in a 614 Destination Options header that precedes the upper-layer header. 615 Therefore, it is processed by the path egress node only. It includes 616 a Per-Path Service Instruction Identifier and causes the path egress 617 node to execute a per-path service instruction. 619 8. Control Plane 621 IS-IS extensions [I-D.bonica-lsr-crh-isis-extensions] have been 622 defined for the following purposes: 624 o So that SRv6+ segment ingress nodes can flood information 625 regarding adjacency segments that they originate. 627 o So that SRv6+ segment egress nodes can flood information regarding 628 node segments that they terminate. 630 BGP extensions [I-D.ssangli-idr-bgp-vpn-srv6-plus] are defined so 631 that SRv6+ path egress nodes can associate path-terminating service 632 instructions with Network Layer Reachability Information (NLRI). 634 9. Differences Between SRv6 and SRv6+ 636 9.1. Routing Header Size 638 SRv6 defines a Routing header type, called the Segment Routing Header 639 (SRH). The SRH contains a field that represents the SRv6 path as an 640 ordered sequence of SIDs. Each SID contained by that field is 128 641 bits long. 643 Likewise, SRv6+ defines two Routing Header Types, called CRH-16 and 644 CRH-32. Both contain a field that represents the SRv6 path as an 645 ordered sequence of SIDs. In the CRH-16, each SID is 16 bits long. 646 In the CRH-32, each SID is 32 bits long. 648 +------+------------------------+--------------+--------------+ 649 | SIDs | SRv6 SRH (128-bit SID) | SRv6+ CRH-16 | SRv6+ CRH-32 | 650 +------+------------------------+--------------+--------------+ 651 | 1 | 24 | 8 | 8 | 652 | 2 | 40 | 8 | 16 | 653 | 3 | 56 | 16 | 16 | 654 | 4 | 72 | 16 | 24 | 655 | 5 | 88 | 16 | 24 | 656 | 6 | 104 | 16 | 32 | 657 | 7 | 120 | 24 | 32 | 658 | 8 | 136 | 24 | 40 | 659 | 9 | 152 | 24 | 40 | 660 | 10 | 168 | 24 | N/A | 661 | 11 | 184 | 32 | N/A | 662 | 12 | 200 | 32 | N/A | 663 | 13 | 216 | 32 | N/A | 664 | 14 | 232 | 32 | N/A | 665 | 15 | 248 | 40 | N/A | 666 | 16 | 264 | 40 | N/A | 667 | 17 | 280 | 40 | N/A | 668 | 18 | 296 | 40 | N/A | 669 +------+------------------------+--------------+--------------+ 671 Table 1: Routing Header Size (in Bytes) As A Function Of Routing 672 Header Type and Number Of SIDs 674 Table 1 reflects Routing header size as a function of Routing header 675 type and number of SIDs contained by the Routing header. Due to 676 their relative immaturity, 677 [I-D.filsfils-spring-net-pgm-extension-srv6-usid], 678 [I-D.li-spring-compressed-srv6-np] and 679 [I-D.mirsky-6man-unified-id-sr] are omitted from this analysis. 681 Large Routing headers are undesirable for the following reasons: 683 o Many ASIC-based forwarders copy the entire IPv6 extension header 684 chain from buffer memory to on-chip memory. As the size of the 685 IPv6 extension header chain increases, so does the cost of this 686 copy. 688 o Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely 689 reliable, many IPv6 hosts refrain from sending packets larger than 690 the IPv6 minimum link MTU (i.e., 1280 bytes). When packets are 691 small, the overhead imposed by large Routing headers becomes 692 pronounced. 694 9.2. Decoupling of Topological and Service Instructions 696 SRv6+ decouples topological instructions from service instructions. 697 Topological instructions are invoked at the segment ingress node, as 698 a result of CRH processing, while service instructions are invoked at 699 the segment egress node, as a result of Destination Option 700 processing. Therefore, network operators can use SRv6+ mechanisms to 701 support topological instructions, service instructions, or both. 703 ---------- ---------- ---------- 704 | Ethernet | | Ethernet | | Ethernet | 705 ---------- ---------- ---------- 706 Service | VXLAN | | Dest | | Dest | 707 Instruction ---------- | | | | 708 | UDP | | Option | | Option | 709 ---------- ---------- ---------- 710 Topological | | | | | 711 Instructions | CRH | | | | CRH | 712 ---------- | | ---------- 713 | IPv6 | | IPv6 | | IPv6 | 714 ---------- ---------- ---------- 716 Option 1 Option 2 Option 3 718 Figure 2: EVPN Design Alternatives 720 Figure 2 illustrates this point by depicting design options available 721 to network operators offering Ethernet Virtual Private Network 722 [RFC7432] services over Virtual eXtensible Local Area Network (VXLAN) 723 [RFC7348]. In Option 1, the network operator encodes topological 724 instructions in the CRH, while encoding service instructions in a 725 VXLAN header. In Option 2, the network operator encodes service 726 instructions in a Destination Options header, while allowing traffic 727 to traverse the least cost path between the ingress and egress 728 Provider Edge (PE) routers. In Option 3, the network operator 729 encodes topological instructions in the CRH, and encodes service 730 instructions in a Destination Options header. 732 9.3. Authentication 734 The IPv6 Authentication Header (AH) [RFC4302] can be used to 735 authenticate SRv6+ packets. However, AH processing is not defined in 736 SRv6. 738 9.4. Traffic Engineering Capability 740 SRv6+ supports traffic engineering solutions that rely exclusively 741 upon adjacency segments. For example, consider an SRv6+ network 742 whose diameter is 12 hops and whose minimum feasible MSV is 65,525. 743 In that network, in the worst case, SRv6+ overhead is 72 bytes (i.e., 744 a 40-byte IPv6 header and a 32-byte CRH-16). 746 SRv6 also supports traffic engineering solutions that rely 747 exclusively upon adjacency segments (i.e., END.X SIDs). However, 748 SRv6 overhead may be prohibitive. For example, consider an SRv6 749 network whose diameter is 12 hops. In the worst case, SRv6 overhead 750 is 240 bytes (i.e., a 40 byte IPv6 header and a 200-byte SRH). 752 9.5. IP Addressing Architecture 754 In SRv6, an IPv6 address can represent either of the following: 756 o A network interface 758 o An instruction instantiated on a node (i.e., an SRv6 SID) 760 In SRv6+ an IPv6 address always represents a network interface, as 761 per [RFC4291]. 763 10. Compliance 765 In order to be compliant with this specification, an SRv6+ 766 implementation MUST: 768 o Be able to process IPv6 options as described in Section 4.2 of 769 [RFC8200]. 771 o Be able to process the Routing header as described in Section 4.4 772 of [RFC8200]. 774 o Be able to process the Destination Options header as described in 775 Section 4.6 of [RFC8200]. 777 o Support the CRH-16 and the CRH-32 779 Additionally, an SRv6+ implementation MAY: 781 o Recognize the Per-Segment Service Instruction Option. 783 o Recognize the Per-Path Service Instruction Option. 785 11. Operational Considerations 787 11.1. Ping and Traceroute 789 Ping and Traceroute [RFC2151] both operate correctly in SRv6+ (i.e., 790 in the presence of the CRH). 792 11.2. ICMPv6 Rate Limitting 794 As per [RFC4443], SRv6+ nodes rate limit the ICMPv6 messages that 795 they emit. 797 12. IANA Considerations 799 SID values 0-15 are reserved for future use. They may be assigned by 800 IANA, based on IETF Consensus. 802 IANA is requested to establish a "Registry of SRv6+ Reserved SIDs". 803 Values 0-15 are reserved for future use. 805 13. Security Considerations 807 SRv6+ domains MUST NOT span security domains. In order to enforce 808 this requirement, security domain edge routers MUST do one of the 809 following: 811 o Discard all inbound SRv6+ packets whose IPv6 destination address 812 represents domain infrastructure. 814 o Authenticate [RFC4302] [RFC4303] all inbound SRv6+ packets whose 815 IPv6 destination address represents domain infrastructure. 817 14. Acknowledgements 819 The authors wish to acknowledge Dr. Vanessa Ameen, Reji Thomas, Parag 820 Kaneriya, Rejesh Shetty, Nancy Shaw, and John Scudder. 822 15. References 824 15.1. Normative References 826 [I-D.bonica-6man-comp-rtg-hdr] 827 Bonica, R., Kamite, Y., Niwa, T., Alston, A., Henriques, 828 D., So, N., Xu, F., Chen, G., Zhu, Y., Yang, G., and Y. 829 Zhou, "The IPv6 Compressed Routing Header (CRH)", draft- 830 bonica-6man-comp-rtg-hdr-05 (work in progress), July 2019. 832 [I-D.bonica-6man-seg-end-opt] 833 Bonica, R., Halpern, J., Kamite, Y., Niwa, T., So, N., Xu, 834 F., Chen, G., Zhu, Y., Yang, G., and Y. Zhou, "The Per- 835 Segment Service Instruction (PSSI) Option", draft-bonica- 836 6man-seg-end-opt-04 (work in progress), July 2019. 838 [I-D.bonica-6man-vpn-dest-opt] 839 Bonica, R., Kamite, Y., Lenart, C., So, N., Xu, F., 840 Presbury, G., Chen, G., Zhu, Y., Yang, G., and Y. Zhou, 841 "The Per-Path Service Instruction (PPSI) Option", draft- 842 bonica-6man-vpn-dest-opt-06 (work in progress), July 2019. 844 [I-D.bonica-lsr-crh-isis-extensions] 845 Kaneriya, P., Shetty, R., Hegde, S., and R. Bonica, "IS-IS 846 Extensions To Support The IPv6 Compressed Routing Header 847 (CRH)", draft-bonica-lsr-crh-isis-extensions-00 (work in 848 progress), May 2019. 850 [I-D.ssangli-idr-bgp-vpn-srv6-plus] 851 Ramachandra, S. and R. Bonica, "BGP based Virtual Private 852 Network (VPN) Services over SRv6+ enabled IPv6 networks", 853 draft-ssangli-idr-bgp-vpn-srv6-plus-02 (work in progress), 854 July 2019. 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, 858 DOI 10.17487/RFC2119, March 1997, 859 . 861 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 862 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 863 2006, . 865 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 866 Control Message Protocol (ICMPv6) for the Internet 867 Protocol Version 6 (IPv6) Specification", STD 89, 868 RFC 4443, DOI 10.17487/RFC4443, March 2006, 869 . 871 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 872 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 873 May 2017, . 875 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 876 (IPv6) Specification", STD 86, RFC 8200, 877 DOI 10.17487/RFC8200, July 2017, 878 . 880 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 881 Decraene, B., Litkowski, S., and R. Shakir, "Segment 882 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 883 July 2018, . 885 15.2. Informative References 887 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 888 Filsfils, C., Camarillo, P., Cai, D., Jiang, Z., 889 daniel.voyer@bell.ca, d., Shawky, A., Leymann, N., 890 Steinberg, D., Zandi, S., Dawra, G., Meilik, I., Uttaro, 891 J., Jalil, L., So, N., Fiumano, M., and M. Khaddam, 892 "Network Programming extension: SRv6 uSID instruction", 893 draft-filsfils-spring-net-pgm-extension-srv6-usid-01 (work 894 in progress), July 2019. 896 [I-D.ietf-6man-segment-routing-header] 897 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 898 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 899 Routing Header (SRH)", draft-ietf-6man-segment-routing- 900 header-22 (work in progress), August 2019. 902 [I-D.ietf-spring-segment-routing-mpls] 903 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 904 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 905 data plane", draft-ietf-spring-segment-routing-mpls-22 906 (work in progress), May 2019. 908 [I-D.ietf-spring-srv6-network-programming] 909 Filsfils, C., Camarillo, P., Leddy, J., 910 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 911 Network Programming", draft-ietf-spring-srv6-network- 912 programming-01 (work in progress), July 2019. 914 [I-D.li-spring-compressed-srv6-np] 915 Li, Z., Li, C., Peng, S., Wang, Z., and B. Liu, 916 "Compressed SRv6 Network Programming", draft-li-spring- 917 compressed-srv6-np-00 (work in progress), July 2019. 919 [I-D.mirsky-6man-unified-id-sr] 920 Cheng, W., Mirsky, G., Peng, S., Aihua, L., Wan, X., and 921 C. Wei, "Unified Identifier in IPv6 Segment Routing 922 Networks", draft-mirsky-6man-unified-id-sr-03 (work in 923 progress), July 2019. 925 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ 926 IP Tools and Utilities", FYI 30, RFC 2151, 927 DOI 10.17487/RFC2151, June 1997, 928 . 930 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 931 Label Switching Architecture", RFC 3031, 932 DOI 10.17487/RFC3031, January 2001, 933 . 935 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 936 DOI 10.17487/RFC4302, December 2005, 937 . 939 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 940 RFC 4303, DOI 10.17487/RFC4303, December 2005, 941 . 943 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 944 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 945 eXtensible Local Area Network (VXLAN): A Framework for 946 Overlaying Virtualized Layer 2 Networks over Layer 3 947 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 948 . 950 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 951 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 952 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 953 2015, . 955 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 956 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 957 DOI 10.17487/RFC8201, July 2017, 958 . 960 Authors' Addresses 962 Ron Bonica 963 Juniper Networks 964 Herndon, Virginia 20171 965 USA 967 Email: rbonica@juniper.net 968 Shraddha Hegde 969 Juniper Networks 970 Embassy Business Park 971 Bangalore, KA 560093 972 India 974 Email: shraddha@juniper.net 976 Yuji Kamite 977 NTT Communications Corporation 978 3-4-1 Shibaura, Minato-ku 979 Tokyo 108-8118 980 Japan 982 Email: : y.kamite@ntt.com 984 Andrew Alston 985 Liquid Telecom 986 Nairobi 987 Kenya 989 Email: Andrew.Alston@liquidtelecom.com 991 Daniam Henriques 992 Liquid Telecom 993 Johannesburg 994 South Africa 996 Email: daniam.henriques@liquidtelecom.com 998 Joel Halpern 999 Ericsson 1000 P. O. Box 6049 1001 Leesburg, Virginia 20178 1002 USA 1004 Email: joel.halpern@ericsson.com 1005 Jen Linkova 1006 Google 1007 Mountain View, California 94043 1008 USA 1010 Email: furry@google.com 1012 Gang Chen 1013 Baidu 1014 No.10 Xibeiwang East Road Haidian District 1015 Beijing 100193 1016 P.R. China 1018 Email: phdgang@gmail.com