idnits 2.17.1 draft-bonica-spring-sr-mapped-six-04.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 (27 September 2021) is 942 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) == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-26 ** 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 (-21) exists of draft-bonica-6man-vpn-dest-opt-16 == Outdated reference: A later version (-06) exists of draft-bonica-lsr-crh-isis-extensions-05 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-11 == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-11 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: 31 March 2022 Y. Kamite 6 NTT Communications Corporation 7 A. Alston 8 D. Henriques 9 Liquid Telecom 10 L. Jalil 11 Verizon 12 J. Halpern 13 Ericsson 14 J. Linkova 15 Google 16 G. Chen 17 Baidu 18 27 September 2021 20 Segment Routing Mapped To IPv6 (SRm6) 21 draft-bonica-spring-sr-mapped-six-04 23 Abstract 25 This document describes Segment Routing Mapped to IPv6 (SRm6). SRm6 26 is a Segment Routing (SR) solution that supports a wide variety of 27 use-cases while complying with IPv6 specifications. SRm6 is 28 optimized for ASIC-based routers that operate at high data rates. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 31 March 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Paths, Segments And Instructions . . . . . . . . . . . . . . 4 65 3. Topological Instructions . . . . . . . . . . . . . . . . . . 5 66 3.1. Adjacency Instructions . . . . . . . . . . . . . . . . . 5 67 3.2. Node Instructions . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Binding Instructions . . . . . . . . . . . . . . . . . . 6 69 4. Service Instructions . . . . . . . . . . . . . . . . . . . . 6 70 4.1. PSSI . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. PPSI . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5. Segment Identifiers (SID) . . . . . . . . . . . . . . . . . . 7 73 5.1. 16-Bit SIDs Versus 32-Bit SIDs . . . . . . . . . . . . . 8 74 5.2. Assigning SIDs . . . . . . . . . . . . . . . . . . . . . 9 75 6. Forwarding Plane . . . . . . . . . . . . . . . . . . . . . . 10 76 7. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 12 77 8. Differences Between SRm6 and SRv6 . . . . . . . . . . . . . . 12 78 8.1. Instruction Encoding . . . . . . . . . . . . . . . . . . 12 79 8.2. IPv6 Address Semantics . . . . . . . . . . . . . . . . . 12 80 8.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.4. Routing Extension Header Size . . . . . . . . . . . . . . 13 82 8.5. Authentication . . . . . . . . . . . . . . . . . . . . . 14 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 88 12.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Overview 93 Network operators deploy Segment Routing (SR) [RFC8402] so they can 94 forward packets through SR paths. An SR path provides connectivity 95 from its ingress node to its egress node. While an SR path can 96 follow the least-cost path from ingress to egress, it can also follow 97 any other path. 99 An SR path contains one or more segments. A segment provides 100 connectivity from its ingress node to its egress node. It includes a 101 topological instruction that controls its behavior. 103 The topological instruction is executed on the segment ingress node. 104 It determines the segment egress node and the method by which the 105 segment ingress node sends packets to the segment egress node. 107 SR nodes can also execute service instructions. Segment egress nodes 108 execute Per Segment Service Instructions (PSSI). Likewise, path 109 egress nodes execute Per Path Service Instructions (PPSI). Section 2 110 of this document describes the relationship between SR paths, 111 segments and instructions. 113 A Segment Identifier (SID) identifies each segment. Because there is 114 a one-to-one relationship between segments and the topological 115 instructions that control them, the SID that identifies a segment 116 also identifies the topological instruction that controls it. 118 A SID is shorter than the topological instruction that it identifies. 119 While a SID is 16 or 32 bits long, the topological instruction that 120 it identifies is at least 128 bits long. 122 To forward a packet through an SR path, the SR ingress node encodes a 123 list of SIDs in the packet header. It can also encode service 124 instructions in the packet header. 126 Because the SR ingress node is also the first segment ingress node, 127 it executes the first segment's topological instruction and sends the 128 packet to the first segment egress node. When the first segment 129 egress node receives the packet, it executes the first segment's 130 PSSI, if one is present. 132 If the SR path contains only one segment, the first segment egress 133 node is also the path egress node. In this case, that node executes 134 the PPSI, if one is present. 136 If the SR path contains multiple segments, the first segment's egress 137 node is also the second segment's ingress node. In this case, that 138 node executes the second segment's topological instruction. This 139 procedure continues until the packet arrives at the path egress node. 140 If the packet includes a PPSI, the path egress node executes it. 142 In SR, only the path ingress node maintains path information. The 143 segment ingress node maintains a topological instruction, but it does 144 not maintain path information unless it is also a path ingress node. 146 SR can use either an MPLS [RFC3031] data plane or an IPv6 [RFC8200] 147 data plane. SR-MPLS [RFC8660] uses MPLS. SRv6 [RFC8986] uses IPv6. 149 This document describes Segment Routing Mapped to IPv6 (SRm6). SRm6 150 is an SR solution that also uses IPv6. It supports a wide variety of 151 use-cases while adhering to IPv6 specifications. 153 Section 8 of this document describes the differences between SRv6 and 154 SRm6. 156 2. Paths, Segments And Instructions 158 ---- ---- ---- ---- ---- ---- 159 |Node|----|Node|----|Node|----|Node|----|Node|----|Node| 160 | A | | B | | C | | D | | E | | F | 161 ---- ---- ---- ---- ---- ---- 162 | | | | 163 -------------------| |-------------------| 164 Segment A-C |---------| Segment D-F 165 Segment C-D 166 | | 167 ------------------------------------------------- 168 SRm6 Path 170 Figure 1: Paths, Segments And Instructions 172 Figure 1 depicts an SRm6 path. The path provides connectivity from 173 its ingress node (i.e., Node A) to its egress node (i.e., Node F). 174 It contains Segments A-C, C-D and D-F. 176 In Segment A-C, Node A is the ingress node, Node B is a transit node, 177 and Node C is the egress node. So, Node A executes the segment's 178 topological instruction. If the packet includes a PSSI for the 179 segment, Node C executes it. 181 In Segment C-D, Node C is the ingress node and Node D is the egress 182 node. So, Node C executes the segment's topological instruction. If 183 the packet includes a PSSI for the segment, Node D executes it. 185 In Segment D-F, Node D is the ingress node, Node E is a transit node, 186 and Node F is the egress node. So, Node D executes the segment's 187 topological instruction. If the packet includes a PSSI for the 188 segment, Node F executes it. 190 Node F is also the path egress node. So, if the packet includes a 191 PPSI, Node F executes it. 193 Other paths that are not included in the figure also include Segments 194 A-C, C-D, and D-F. 196 3. Topological Instructions 198 SRm6 supports the following topological instruction types: 200 * Adjacency. 202 * Node. 204 * Binding. 206 3.1. Adjacency Instructions 208 Adjacency instructions send packets through a single link that 209 connects the segment ingress node to the segment egress node. An 210 adjacency instruction includes the following information: 212 * SE-ADDR: The IPv6 address of an interface on the segment egress 213 node. 215 * IFACE: An interface identifier. 217 The instruction behaves as follows: 219 * If the interface identified by IFACE is not operational, discard 220 the packet and send an ICMPv6 [RFC4443] Destination Unreachable 221 message to the packet's source node. 223 * Overwrite the packet's Destination Address with SE-ADDR. 225 * Send the packet through the interface identified by IFACE. 227 3.2. Node Instructions 229 Node instructions send packets through the least-cost path from the 230 segment ingress node to the segment egress node. A node instruction 231 includes an SE-ADDR. The SE-ADDR is the IPv6 address of an interface 232 on the segment egress node. 234 The instruction behaves as follows: 236 * If the segment ingress node does not have a viable route to SE- 237 ADDR, discard the packet and send an ICMPv6 Destination 238 Unreachable message to the packet's source node. 240 * Overwrite the packet's Destination Address with SE-ADDR. 242 * Send the packet to the next-hop along the least-cost path to SE- 243 ADDR. 245 3.3. Binding Instructions 247 Binding instructions send packets through tunnels that connect the 248 segment ingress node to the segment egress node. Because the tunnel 249 is also an SRm6 path, it is called an SRm6 tunnel. 251 A binding instruction includes the following information: 253 * SE-ADDR: The IPv6 address of an interface on the segment egress 254 node. 256 * Tunnel-SID-List: A SID list that determines the path of the SRm6 257 tunnel. 259 The instruction behaves as follows: 261 * Overwrite the packet's Destination Address with SE-ADDR. 263 * Prepend an SRm6 tunnel header to the packet. The SRm6 tunnel 264 header includes the Tunnel-SID-List. 266 * If the SRm6 tunnel is not operational, discard the packet and send 267 an ICMPv6 Destination Unreachable message to the packet's source 268 node. 270 * Send the packet through the SRm6 tunnel. 272 4. Service Instructions 274 SRm6 supports the following service instruction types: 276 * Per-Segment Service Instructions (PSSI). 278 * Per-Path Service Instructions (PPSI). 280 4.1. PSSI 282 The PSSI, if present, is executed on the segment egress node. 283 Because the path egress node is also a segment egress node, it can 284 execute a PSSI. 286 The following are examples of PSSIs: 288 * Expose a packet to a firewall policy. 290 * Expose a packet to a sampling policy. 292 4.2. PPSI 294 A PPSI, if present, is executed on the path egress node. 296 The following are examples of PPSIs: 298 * De-encapsulate a packet and forward its newly exposed payload 299 through a specified interface. 301 * De-encapsulate a packet and forward its newly exposed payload 302 using a specified routing table. 304 5. Segment Identifiers (SID) 306 A Segment Identifier (SID) is an unsigned integer that identifies a 307 segment. It can be either 16 or 32 bits long. Because there is a 308 one-to-one relationship between segments and the topological 309 instructions that control them, the SID that identifies a segment 310 also identifies the topological instruction that controls it. 312 A SID is shorter than the topological instruction that it identifies. 313 While a SID is 16 or 32 bits long, the topological instruction that 314 it identifies is at least 128 bits long. 316 SIDs have node-local significance. This means that a segment ingress 317 node identifies each segment that it originates with a unique SID. 318 However, a single SID value can be used to identify: 320 * A segment whose ingress is Node A and whose egress is Node Z. 322 * Another segment whose ingress is Node B and whose egress is also 323 node Z. 325 A single SID value can identify both segments because they originate 326 on different nodes. 328 SID values 0 through 15 are reserved for future use. 330 SIDs can be assigned in a manner that simplifies network operations. 331 See Section 5.2 for details. 333 5.1. 16-Bit SIDs Versus 32-Bit SIDs 335 The maximum 16-bit SID value is 65,535. Because SIDs 0 through 15 336 are reserved for future use, a 16-bit SID offers 65,520 usable 337 values. 339 The maximum 32-bit SID value is 4,294,967,295. Because SIDs 0 340 through 15 are reserved for future use, a 32-bit SID offers 341 4,294,967,280 usable values. 343 To minimize packet length, network operators should use 16-bit SIDs 344 whenever possible. However, when more than 65,520 SIDs are required, 345 network operators must use 32-bit SIDs. 347 Consider a network that contains 60,000 nodes. Each node connects to 348 200 or fewer neighbors through point-to-point links. In this 349 network, we will determine how many SIDs are required under the 350 following conditions: 352 * If the network contains adjacency segments only. 354 * If the network contains node segments only. 356 * If the network contains both adjacency and node segments. 358 If the network contains adjacency segments only, and each node 359 originates an adjacency segment to each of its neighbors, each node 360 originates 200 segments or fewer. Because SIDs have node-local 361 significance (i.e., they can be reused across nodes), the network 362 requires only 200 SIDs. The network operator can use 16-bit SIDs, so 363 long as each node supports 65,520 point-to-point links or fewer. 365 If the network contains node segments only, and every node originates 366 a node segment to every other node, every node originates 59,999 367 segments. Because SIDs have node-local significance, the network 368 requires only 59,999 SIDs. The network operator can use 16-bit SIDs 369 so long as the number of nodes is less than 65,520. 371 If the network contains both adjacency and node segments, each node 372 will originate 60,199 segments or fewer. This value is the sum of: 374 * The number of node segments that each node originates (i.e., 375 59,999). 377 * The number of adjacency segments that each node originates (i.e., 378 200 or fewer). 380 Because SIDs have node-local significance, only 60,199 SIDs are 381 required. The network operator can use 16-bit SIDs so long as the 382 number of nodes plus the maximum number of links per node is less 383 than 65,520. 385 5.2. Assigning SIDs 387 Network operators can establish conventions for assigning SIDs to 388 segments. These conventions can simplify network operations. 390 For example, a network operator who uses 16-bit SIDs can: 392 * Assign SIDs 16 - 1000 to adjacency segments 394 * Assign SIDs 1001 - 62,000 to node segments 396 * Assign SIDs 62,001 to 65,535 to binding segments 398 The network operator can also assign node SIDs so that all node 399 segments ending on a node have the same SID (i.e., all node 400 instructions that include the same information are identified by the 401 same SID). 403 +======================+=====================+======+ 404 | Segment Ingress Node | Segment Egress Node | SID | 405 +======================+=====================+======+ 406 | 2 | 1 | 1001 | 407 +----------------------+---------------------+------+ 408 | 3 | 1 | 1001 | 409 +----------------------+---------------------+------+ 410 | 1 | 2 | 1002 | 411 +----------------------+---------------------+------+ 412 | 3 | 2 | 1002 | 413 +----------------------+---------------------+------+ 414 | 1 | 3 | 1003 | 415 +----------------------+---------------------+------+ 416 | 2 | 3 | 1003 | 417 +----------------------+---------------------+------+ 419 Table 1: Node SID Assignments 421 Table 1 illustrates this convention for Nodes 1, 2 and 3. 423 6. Forwarding Plane 425 SRm6 Path from node B to node C 426 <------------------------> 427 SR Path SR Path 428 Ingress Egress 429 Node Node 430 +-+ +-+ +-+ +-+ 431 |A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D| 432 +-+ +-+ +-+ +-+ 433 Original Original 434 Packet Packet 435 Source Destination 436 Node Node 438 Figure 2: SRm6 Path As Tunnel 440 SRm6 is an application of IPv6 tunneling [RFC2473]. Figure 2 441 illustrates how an SRm6 ingress node receives an original packet, 442 encapsulates it in an SRm6 header, and forwards the resulting SRm6 443 packet through an SRm6 path to an SRm6 egress node. The SRm6 egress 444 node removes the SRm6 header and forwards the original packet to its 445 destination. 447 +----------------------------------//-----+ 448 | Original | | 449 | | Original Packet Payload | 450 | Header | | 451 +----------------------------------//-----+ 452 < Original Packet > 453 | 454 v 455 < SRm6 Header > < Original Packet > 456 +---------+ - - - - - +-------------------------//--------------+ 457 | IPv6 | IPv6 | | 458 | | Extension | Original Packet | 459 | Header | Headers | | 460 +---------+ - - - - - +-------------------------//--------------+ 461 < SRm6 Packet > 463 Figure 3: SRm6 Encapsulation 465 Figure 3 illustrates SRm6 encapsulation. In the figure, the SRm6 466 header contains: 468 * An IPv6 header. 470 * One or more IPv6 extension headers. 472 The following rules govern the use of extension headers in the SRm6 473 header: 475 * The SRm6 header can contain any valid combination of extension 476 headers. 478 * Extension headers are arranged in the order recommended by 479 Section 4.1 of [RFC8200]. 481 * Extension headers are processed in the order that the appear in 482 the packet, as described in Section 4.1 of [RFC8200]. 484 * If the SR path contains multiple segments, the SID list is encoded 485 in a Compressed Routing Header (CRH) 486 [I-D.bonica-6man-comp-rtg-hdr]. 488 * If the SRm6 header contains a PSSI, it is encoded in a Destination 489 Option header that precedes the CRH. Destination options will be 490 defined as needed. 492 * If the SRm6 header contains a PPSI, it is encoded in the IPv6 493 Tunnel Payload Forwarding (TPF) Option 494 [I-D.bonica-6man-vpn-dest-opt]. The TPF option appears in a 495 Destination Options header that immediately precedes the upper- 496 layer header. 498 Therefore, PSSI's are processed at each segment egress node, while 499 the PPSI is processed at the path egress node only. 501 An SRm6 header contains only the extension headers that it needs. 502 For example, an SRm6 header can contain: 504 * A CRH and a TPF Option - This packet traverses an SRm6 path that 505 contains multiple segments and executes a PPSI at the path egress 506 node. 508 * A CRH only - This packet traverses an SRm6 path that contains 509 multiple segments and does not execute a PPSI at the path egress 510 node. 512 * A TPF Option only - This packet traverses an SRm6 path that 513 contains a single segment and executes a PPSI at the path egress 514 node. 516 SRm6 inherits Hop Limit, traffic class and Flow Label processing 517 procedures from I [RFC2473]. 519 7. Control Plane 521 The following documents describe control plane extensions that 522 support the CRH and the TPF Option: 524 * IS-IS Support for CRH [I-D.bonica-lsr-crh-isis-extensions] 526 * BGP Support for the IPv6 TPF Option 527 [I-D.ssangli-idr-bgp-vpn-srv6-plus], 528 [I-D.alston-spring-crh-bgp-signalling] 530 8. Differences Between SRm6 and SRv6 532 8.1. Instruction Encoding 534 SRm6 encodes topological instructions in 16 or 32-bit SIDs that 535 appear in the CRH. It also encodes service instructions in IPv6 536 Destination Options. 538 SRv6 encodes all instructions in the low-order bits of the IPv6 539 Destination Address. 541 8.2. IPv6 Address Semantics 543 In SRm6 an IPv6 address always represents a network interface, as per 544 [RFC4291]. 546 In SRv6, an IPv6 Destination Address can represent either of the 547 following: 549 * A network interface 551 * An SRv6 SID, whose high-order bits are used for routing and low- 552 order bits represent an instruction. 554 8.3. OAM 556 SRm6 does not require any new OAM mechanisms. Because SRv6 modifies 557 IPv6 address semantics, it requires the OAM mechanisms described in 558 [I-D.ietf-6man-spring-srv6-oam]. 560 8.4. Routing Extension Header Size 562 +======+========================+=============+=============+ 563 | SIDs | SRv6 SRH (128-bit SID) | SRm6 CRH-16 | SRm6 CRH-32 | 564 +======+========================+=============+=============+ 565 | 1 | 24 | 8 | 8 | 566 +------+------------------------+-------------+-------------+ 567 | 2 | 40 | 8 | 16 | 568 +------+------------------------+-------------+-------------+ 569 | 3 | 56 | 16 | 16 | 570 +------+------------------------+-------------+-------------+ 571 | 4 | 72 | 16 | 24 | 572 +------+------------------------+-------------+-------------+ 573 | 5 | 88 | 16 | 24 | 574 +------+------------------------+-------------+-------------+ 575 | 6 | 104 | 16 | 32 | 576 +------+------------------------+-------------+-------------+ 577 | 7 | 120 | 24 | 32 | 578 +------+------------------------+-------------+-------------+ 579 | 8 | 136 | 24 | 40 | 580 +------+------------------------+-------------+-------------+ 581 | 9 | 152 | 24 | 40 | 582 +------+------------------------+-------------+-------------+ 583 | 10 | 168 | 24 | 48 | 584 +------+------------------------+-------------+-------------+ 585 | 11 | 184 | 32 | 48 | 586 +------+------------------------+-------------+-------------+ 587 | 12 | 200 | 32 | 52 | 588 +------+------------------------+-------------+-------------+ 589 | 13 | 216 | 32 | 52 | 590 +------+------------------------+-------------+-------------+ 591 | 14 | 232 | 32 | 56 | 592 +------+------------------------+-------------+-------------+ 593 | 15 | 248 | 40 | 56 | 594 +------+------------------------+-------------+-------------+ 595 | 16 | 264 | 40 | 60 | 596 +------+------------------------+-------------+-------------+ 597 | 17 | 280 | 40 | 60 | 598 +------+------------------------+-------------+-------------+ 599 | 18 | 296 | 40 | 64 | 600 +------+------------------------+-------------+-------------+ 602 Table 2: Routing Header Size (in Bytes) As A Function Of 603 Routing Header Type and Number Of SIDs 605 SRv6 and SRm6 both encode path information in a Routing extension 606 header. SRv6 uses the Segment Routing Header (SRH) [RFC8754], while 607 SRm6 uses either the 16 or 32-bit version of the CRH. Table 2 608 reports Routing header size as a function of Routing header type and 609 number of SIDs contained by the Routing header. Due to their 610 relative immaturity, 611 [I-D.filsfils-spring-net-pgm-extension-srv6-usid], 612 [I-D.li-spring-compressed-srv6-np] and 613 [I-D.mirsky-6man-unified-id-sr] are omitted from this analysis. 615 Large Routing headers are undesirable for the following reasons: 617 * Many ASIC-based forwarders copy all headers from buffer memory to 618 on-chip memory. As header sizes increase, so does the cost of 619 this copy. 621 * Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely 622 reliable, many IPv6 hosts refrain from sending packets larger than 623 the IPv6 minimum link MTU (i.e., 1280 bytes). When packets are 624 small, the overhead imposed by large Routing Headers is excessive. 626 8.5. Authentication 628 An SRm6 packet can include any valid combination of IPv6 extension 629 headers. However, the IPv6 Authentication Header (AH) [RFC4302] is 630 not defined in SRv6. 632 9. IANA Considerations 634 This document does not request any actions by IANA. 636 10. Security Considerations 638 SRm6 inherits the security consideration of IPv6 tunneling [RFC2473], 639 the Compressed Routing Header (CRH) [I-D.bonica-6man-comp-rtg-hdr], 640 and the IPv6 Tunnel Payload Forwarding (TPF) Option 641 [I-D.bonica-6man-vpn-dest-opt]. 643 11. Acknowledgements 645 The authors wish to acknowledge Dr. Vanessa Ameen, Reji Thomas, Parag 646 Kaneriya, Rejesh Shetty, Nancy Shaw, and John Scudder. 648 12. References 650 12.1. Normative References 652 [I-D.alston-spring-crh-bgp-signalling] 653 Alston, A., Henriques, D., and R. Bonica, "BGP Extensions 654 for IPv6 Compressed Routing Header (CRH)", Work in 655 Progress, Internet-Draft, draft-alston-spring-crh-bgp- 656 signalling-01, 24 July 2019, 657 . 660 [I-D.bonica-6man-comp-rtg-hdr] 661 Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. 662 Jalil, "The IPv6 Compact Routing Header (CRH)", Work in 663 Progress, Internet-Draft, draft-bonica-6man-comp-rtg-hdr- 664 26, 25 May 2021, . 667 [I-D.bonica-6man-vpn-dest-opt] 668 Bonica, R., Kamite, Y., Jalil, L., Zhou, Y., and G. Chen, 669 "The IPv6 Tunnel Payload Forwarding (TPF) Option", Work in 670 Progress, Internet-Draft, draft-bonica-6man-vpn-dest-opt- 671 16, 26 July 2021, . 674 [I-D.bonica-lsr-crh-isis-extensions] 675 Kaneriya, P., Shetty, R., Hegde, S., and R. Bonica, "IS-IS 676 Extensions To Support The IPv6 Compressed Routing Header 677 (CRH)", Work in Progress, Internet-Draft, draft-bonica- 678 lsr-crh-isis-extensions-05, 30 August 2021, 679 . 682 [I-D.ssangli-idr-bgp-vpn-srv6-plus] 683 Sangli, S. and R. Bonica, "BGP based Virtual Private 684 Network (VPN) Services over SRv6+ enabled IPv6 networks", 685 Work in Progress, Internet-Draft, draft-ssangli-idr-bgp- 686 vpn-srv6-plus-02, 22 July 2019, 687 . 690 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 691 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 692 December 1998, . 694 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 695 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 696 2006, . 698 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 699 Control Message Protocol (ICMPv6) for the Internet 700 Protocol Version 6 (IPv6) Specification", STD 89, 701 RFC 4443, DOI 10.17487/RFC4443, March 2006, 702 . 704 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 705 (IPv6) Specification", STD 86, RFC 8200, 706 DOI 10.17487/RFC8200, July 2017, 707 . 709 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 710 Decraene, B., Litkowski, S., and R. Shakir, "Segment 711 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 712 July 2018, . 714 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 715 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 716 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 717 . 719 12.2. Informative References 721 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 722 Filsfils, C., Garvia, P. C., Cai, D., Voyer, D., Meilik, 723 I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, 724 D., Liu, Y., and J. Guichard, "Network Programming 725 extension: SRv6 uSID instruction", Work in Progress, 726 Internet-Draft, draft-filsfils-spring-net-pgm-extension- 727 srv6-usid-11, 9 September 2021, 728 . 731 [I-D.ietf-6man-spring-srv6-oam] 732 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 733 Chen, "Operations, Administration, and Maintenance (OAM) 734 in Segment Routing Networks with IPv6 Data plane (SRv6)", 735 Work in Progress, Internet-Draft, draft-ietf-6man-spring- 736 srv6-oam-11, 2 June 2021, 737 . 740 [I-D.li-spring-compressed-srv6-np] 741 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 742 Guichard, J. N., Li, C., and S. Peng, "Compressed SRv6 743 Network Programming", Work in Progress, Internet-Draft, 744 draft-li-spring-compressed-srv6-np-02, 25 February 2020, 745 . 748 [I-D.mirsky-6man-unified-id-sr] 749 Weiqiang, C., Mirsky, G., Shaofu, P., Aihua, L., and G. S. 750 Mishra, "Unified Identifier in IPv6 Segment Routing 751 Networks", Work in Progress, Internet-Draft, draft-mirsky- 752 6man-unified-id-sr-10, 25 September 2021, 753 . 756 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 757 Label Switching Architecture", RFC 3031, 758 DOI 10.17487/RFC3031, January 2001, 759 . 761 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 762 DOI 10.17487/RFC4302, December 2005, 763 . 765 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 766 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 767 DOI 10.17487/RFC8201, July 2017, 768 . 770 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 771 Decraene, B., Litkowski, S., and R. Shakir, "Segment 772 Routing with the MPLS Data Plane", RFC 8660, 773 DOI 10.17487/RFC8660, December 2019, 774 . 776 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 777 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 778 (SRv6) Network Programming", RFC 8986, 779 DOI 10.17487/RFC8986, February 2021, 780 . 782 Authors' Addresses 783 Ron Bonica 784 Juniper Networks 785 Herndon, Virginia 20171 786 United States of America 788 Email: rbonica@juniper.net 790 Shraddha Hegde 791 Juniper Networks 792 Embassy Business Park 793 Bangalore 560093 794 KA 795 India 797 Email: shraddha@juniper.net 799 Yuji Kamite 800 NTT Communications Corporation 801 3-4-1 Shibaura, Minato-ku, 802 108-8118 803 Japan 805 Email: y.kamite@ntt.com 807 Andrew Alston 808 Liquid Telecom 809 Nairobi 810 Kenya 812 Email: Andrew.Alston@liquidtelecom.com 814 Daniam Henriques 815 Liquid Telecom 816 Johannesburg 817 South Africa 819 Email: daniam.henriques@liquidtelecom.com 821 Luay Jalil 822 Verizon 823 Richardson, Texas 824 United States of America 825 Email: luay.jalil@one.verizon.com 827 Joel Halpern 828 Ericsson 829 P. O. Box 6049 830 Leesburg, Virginia 20178 831 United States of America 833 Email: joel.halpern@ericsson.com 835 Jen Linkova 836 Google 837 Mountain View, California 94043 838 United States of America 840 Email: furry@google.com 842 Gang Chen 843 Baidu 844 No.10 Xibeiwang East Road Haidian District 845 Beijing 846 100193 847 P.R. China 849 Email: phdgang@gmail.com