idnits 2.17.1 draft-bonica-6man-comp-rtg-hdr-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 (July 5, 2019) is 1749 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 619 -- Looks like a reference, but probably isn't: '1' on line 620 == Outdated reference: A later version (-06) exists of draft-bonica-spring-srv6-plus-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man R. Bonica 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Y. Kamite 5 Expires: January 6, 2020 NTT Communications Corporation 6 T. Niwa 7 KDDI 8 A. Alston 9 D. Henriques 10 Liquid Telecom 11 N. So 12 F. Xu 13 Reliance Jio 14 G. Chen 15 Baidu 16 Y. Zhu 17 G. Yang 18 China Telecom 19 Y. Zhou 20 ByteDance 21 July 5, 2019 23 The IPv6 Compressed Routing Header (CRH) 24 draft-bonica-6man-comp-rtg-hdr-05 26 Abstract 28 This document defines a new IPv6 Routing header type, called the 29 Compressed Routing Header (CRH). SRv6+ nodes use the CRH to steer 30 packets from segment to segment along SRv6+ paths. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 6, 2020. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 68 3. The Compressed Routing Header (CRH) . . . . . . . . . . . . . 3 69 4. Segment Forwarding Information Base (SFIB) . . . . . . . . . 5 70 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 5 71 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5.2. CRH Specific . . . . . . . . . . . . . . . . . . . . . . 6 73 5.2.1. Computing Minimum CRH Length . . . . . . . . . . . . 7 74 5.2.2. Strictly-Routed Topological Instructions . . . . . . 8 75 5.2.3. Loosely-Routed Topological Instructions . . . . . . . 9 76 6. Mutability . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 7. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. Management Considerations . . . . . . . . . . . . . . . . . . 9 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 12.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Appendix A. CRH Processing Examples . . . . . . . . . . . . . . 11 86 A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 13 87 A.2. Loose Source Routing Preserving The First SID . . . . . . 13 88 A.3. Strict Source Routing . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 This document defines a new IPv6 [RFC8200] Routing header type, 94 called the Compressed Routing Header (CRH). SRv6+ 95 [I-D.bonica-spring-srv6-plus] nodes use the CRH to steer packets from 96 segment to segment along SRv6+ paths. 98 For details regarding SRv6+ paths, segments, Segment Identifiers 99 (SIDs) and instructions, see [I-D.bonica-spring-srv6-plus]. 101 2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 3. The Compressed Routing Header (CRH) 111 0 1 2 3 112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Last Entry |Com| Reserved | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | SID List ........ 119 +-+-+-+-+-+-+-+-+-+-+- 121 Figure 1: Compressed Routing Header (CRH) 123 Figure 1 depicts the CRH. The CRH contains the following fields: 125 o Next Header - Defined in [RFC8200]. 127 o Hdr Ext Len - Defined in [RFC8200]. 129 o Routing Type - Defined in [RFC8200]. Value TBD by IANA. 130 (Suggested value: 5) 132 o Segments Left - Defined in [RFC8200]. 134 o Last Entry - 8 bits. Represents the zero-based index of the last 135 element of the Segment List. 137 o Com (Compression) - 2 bits. Represents the length of each entry 138 in the SID List. Values are reserved (0), sixteen bits (1), 139 thirty-two bits (2), and reserved (3). In order to maximize 140 header compression, this value should reflect the smallest 141 feasible Maximum SID Value (MSV). See Section 5.1 of 142 [I-D.bonica-spring-srv6-plus] for MSV details. 144 o Reserved - SHOULD be set to zero by the sender. MUST be ignored 145 by the receiver. 147 o SID List - Represents the SRv6+ path as an ordered list of SIDs. 148 SIDs are listed in reverse order, with SID[0] representing the 149 final segment, SID[1] representing the penultimate segment, and so 150 forth. SIDs are listed in reverse order so that Segments Left can 151 be used as an index to the SID List. The SID indexed by Segments 152 Left is called the current SID. 154 Figure 2 and Figure 3 illustrate CRH encodings with Com equal to 1 155 and 2. In all cases, the CRH MUST end on a 64-bit boundary. 156 Therefore, the CRH MAY be padded with zeros. 158 0 1 2 3 159 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Last Entry |Com| Reserved | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | SID[0] | SID[1] | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 167 | ......... 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 170 Figure 2: Sixteen-bit Encoding (Com equals 1) 172 0 1 2 3 173 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Last Entry |Com| Reserved | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 + SID[0] + 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 + SID[1] + 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 // // 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 + SID[n] + 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 3: Thirty-two bit Encoding (Com equals 2) 190 4. Segment Forwarding Information Base (SFIB) 192 A segment ingress node MUST maintain one Segment Forwarding 193 Information Base (SFIB) entry for each segment that it originates. 194 Each SFIB entry contains the following information: 196 o A SID 198 o A segment type 200 o Topological instruction parameters 202 The following are valid segment types: 204 o Strictly-routed 206 o Loosely-routed 208 The following parameters are associated with topological instructions 209 that control strictly-routed segments: 211 o An IPv6 address that identifies an interface on the segment egress 212 node. 214 o A primary interface identifier. 216 o Zero or more secondary interface identifiers. 218 Loosely-routed segments are associated with a single topological 219 instruction parameter. This parameter is an IPv6 address that 220 identifies an interface on the segment egress node. 222 5. Processing Rules 224 5.1. General 226 [RFC8200] defines rules that apply to IPv6 extension headers, in 227 general, and IPv6 Routing headers, in particular. All of these rules 228 apply to the CRH. 230 For example: 232 o Extension headers (except for the Hop-by-Hop Options header) are 233 not processed, inserted, or deleted by any node along a packet's 234 delivery path, until the packet reaches the node (or each of the 235 set of nodes, in the case of multicast) identified in the 236 Destination Address field of the IPv6 header. 238 o If, while processing a received packet, a node encounters a 239 Routing header with an unrecognized Routing Type value, the 240 required behavior of the node depends on the value of the Segments 241 Left field. If Segments Left is zero, the node must ignore the 242 Routing header and proceed to process the next header in the 243 packet, whose type is identified by the Next Header field in the 244 Routing header. If Segments Left is non-zero, the node must 245 discard the packet and send an ICMPv6 [RFC4443] Parameter Problem, 246 Code 0, message to the packet's Source Address, pointing to the 247 unrecognized Routing Type. 249 o If, after processing a Routing header of a received packet, an 250 intermediate node determines that the packet is to be forwarded 251 onto a link whose link MTU is less than the size of the packet, 252 the node must discard the packet and send an ICMPv6 Packet Too Big 253 message to the packet's Source Address. 255 5.2. CRH Specific 257 When a node recognizes and processes a CRH, it executes the following 258 procedure: 260 o If the IPv6 Source Address is a link-local address, discard the 261 packet. 263 o If the IPv6 Source Address is a multicast address, discard the 264 packet. 266 o If Segments Left equal 0, skip over the CRH and process the next 267 header in the packet. 269 o If Segments Left is greater than Last Entry plus one, discard the 270 packet and send an ICMPv6 Parameter Problem, Code 0, message to 271 the Source Address, pointing to the Segments Left field. 273 o If Com is equal to (0) or (3) Reserved, discard the packet and 274 send an ICMPv6 Parameter Problem, Code 0, message to the Source 275 Address, pointing to the Com field. 277 o Compute L, the minimum CRH length (See Section 5.2.1) 279 o If L is equal to zero or L is greater than Hdr Ext Len, discard 280 the packet and send an ICMPv6 Parameter Problem, Code 0, message 281 to the Source Address, pointing to the Last Entry field. 283 o Decrement the packet's Hop Count. 285 o If the Hop Count has expired, discard the packet and send an 286 ICMPv6 Time Expired message to the packet's source node. 288 o Decrement Segments Left 290 o Search for the current SID in the SFIB. 292 o If the above-mentioned search does not return an SFIB entry, 293 discard the packet and send an ICMPv6 Parameter Problem, Code 0, 294 message to the Source Address, pointing to the current SID. 296 o If the above-mentioned search returns an SFIB entry and the 297 segment type is strictly-routed, execute the strictly-routed 298 topological instruction described in Section 5.2.2. 300 o If the above-mentioned search returns an SFIB entry and the 301 segment type is loosely-routed, execute the loosely-routed 302 topological instruction described in Section 5.2.3. 304 The above stated rules are demonstrated in Appendix A. 306 5.2.1. Computing Minimum CRH Length 308 The algorithm described in this section accepts the following CRH 309 fields as its input parameters: 311 o Compression (Com). 313 o Last Entry. 315 It yields L, the minimum CRH length. The minimum CRH length is 316 measured in 8-octet units, not including the first 8 octets. 318 320 if (Com == 1 ) { /* Sixteen bit encoding */ 321 L = ( ( Last Entry + 1 ) / 4 ); 322 if ( ( Last Entry + 1 ) % 4 ) 323 L++; 324 } 325 elsif (Com == 2 ) { /* Thirty-two bit encoding */ 326 L = ( ( Last Entry + 1 ) / 2 ); 327 if ( ( Last Entry + 1 ) % 2 ) 328 L++; 329 } 330 else { /* Invalid Com */ 331 L = 0xFF 333 } 335 return(0) 337 339 5.2.2. Strictly-Routed Topological Instructions 341 A strictly-routed topological instruction accepts the following 342 parameters:: 344 o An IPv6 address that identifies an interface on the segment egress 345 node. 347 o A primary interface identifier. 349 o Zero or more secondary interface identifiers. 351 A strictly-routed topological instruction behaves as follows: 353 o If none of the interfaces identified by the above-mentioned 354 parameters are operational, discard the packet and send an ICMPv6 355 Destination Unreachable message (Code: 5, Source Route Failed) to 356 the packet's source node. 358 o Overwrite the packet's Destination Address with the IPv6 address 359 that was received as a parameter. 361 o If the primary interface is active, forward the packet through the 362 primary interface. 364 o If the primary interface is not active and any of the secondary 365 interfaces are active, forward the packet through one of the 366 secondary interfaces. Execute procedures so that all packets 367 belonging to a flow are forwarded through the same secondary 368 interface. 370 5.2.3. Loosely-Routed Topological Instructions 372 A loosely-routed topological instruction accepts a single parameter. 373 This parameter is an IPv6 address that identifies an interface on the 374 segment egress node. 376 A loosely-routed topological instruction behaves as follows: 378 o If the segment ingress node does not have a viable route to the 379 IPv6 address included as a parameter, discard the packet and send 380 an ICMPv6 Destination Unreachable message (Code:1 Net Unreachable) 381 to the packet's source node. 383 o Overwrite the packet's Destination Address with the destination 384 address that was included as a parameter. 386 o Forward the packet to the next hop along the least cost path to 387 the segment egress node. If there are multiple least cost paths 388 to the segment egress node (i.e., Equal Cost Multipath), execute 389 procedures so that all packets belonging to a flow are forwarded 390 through the same next hop. 392 6. Mutability 394 In the CRH, the Segments Left field is mutable. All remaining fields 395 are immutable. 397 7. Compliance 399 In order to be compliant with this specification, an implementation 400 MUST support 32-bit SID encoding. It MAY also support 16-bit SID 401 encoding. 403 8. Management Considerations 405 PING and TRACEROUTE [RFC2151] both operate correctly in the presence 406 of the CRH. 408 9. Security Considerations 410 The CRH can be used within trusted domains only. In order to enforce 411 this requirement, domain edge routers MUST do one of the following: 413 o Discard all inbound packets that are destined for infrastructure 414 interfaces and contain a CRH 416 o Authenticate [RFC4302] [RFC4303] all inbound packets that are 417 destined for infrastructure interfaces and contain a CRH 419 10. IANA Considerations 421 This document makes the following registration in the Internet 422 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 423 maintained by IANA: 425 Suggested 426 Value Description Reference 427 ------------------------------------------------------------ 428 5 Compressed Routing Header (CRH) This document 430 11. Acknowledgements 432 Thanks to Joel Halpern, Tony Li, Gerald Schmidt, Nancy Shaw and 433 Chandra Venkatraman for their comments. 435 12. References 437 12.1. Normative References 439 [I-D.bonica-spring-srv6-plus] 440 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 441 D., Halpern, J., and J. Linkova, "IPv6 Support for Segment 442 Routing: SRv6+", draft-bonica-spring-srv6-plus-01 (work in 443 progress), July 2019. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 451 DOI 10.17487/RFC4302, December 2005, 452 . 454 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 455 RFC 4303, DOI 10.17487/RFC4303, December 2005, 456 . 458 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 459 Control Message Protocol (ICMPv6) for the Internet 460 Protocol Version 6 (IPv6) Specification", STD 89, 461 RFC 4443, DOI 10.17487/RFC4443, March 2006, 462 . 464 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 465 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 466 May 2017, . 468 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 469 (IPv6) Specification", STD 86, RFC 8200, 470 DOI 10.17487/RFC8200, July 2017, 471 . 473 12.2. Informative References 475 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ 476 IP Tools and Utilities", FYI 30, RFC 2151, 477 DOI 10.17487/RFC2151, June 1997, 478 . 480 Appendix A. CRH Processing Examples 482 This appendix provides examples of CRH processing in the following 483 applications: 485 o Loose source routing (Appendix A.1) 487 o Loose source routing preserving the first SID (Appendix A.2) 489 o Strict source routing (Appendix A.3) 490 ----------- 491 2001:db8:0:2/64 |Node: I2 | 2001:db8:0:4/64 492 ----------------------|Loopback: |-------------------- 493 | ::2 |2001:db8::2| ::1 | 494 | ----------- | 495 | ::1 :: 2| 496 ----------- ----------- ----------- 497 |Node: S |2001:db8:0:1/64|Node: I1 |2001:db8:0:3/64|Node: I3 | 498 |Loopback |---------------|Loopback: |---------------|Loopback: | 499 |2001:db8::a| ::1 ::2 |2001:db8::1| ::1 ::2 |2001:db8::3| 500 ----------- ----------- ----------- 501 | ::1 502 ----------- | 503 |Node: D | 2001:db8:0:b/64 | 504 |Loopback: |--------------------- 505 |2001:db8::b| ::2 506 ----------- 508 Figure 4: Reference Topology 510 Figure 4 provides a reference topology that is used in all examples. 512 +--------------------+-----+----------------+--------------+ 513 | Instantiating Node | SID | Segment Type | IPv6 Address | 514 +--------------------+-----+----------------+--------------+ 515 | All | 1 | Loosely-routed | 2001:db8::1 | 516 | All | 2 | Loosely-routed | 2001:db8::2 | 517 | All | 3 | Loosely-routed | 2001:db8::3 | 518 | All | 10 | Loosely-routed | 2001:db8::a | 519 | All | 11 | Loosely-routed | 2001:db8::b | 520 +--------------------+-----+----------------+--------------+ 522 Table 1: Loosely Routed SIDs 524 Table 1 describes SFIB entries that are instantiated on all nodes. 525 All of these SFIB entries represent loosely-routed segments. 527 +---------------+-----+-----------------+------------+--------------+ 528 | Instantiating | SID | IPv6 Address | Primary | Secondary | 529 | Node | | | Interface | Interfaces | 530 +---------------+-----+-----------------+------------+--------------+ 531 | S | 129 | 2001:db8:0:1::2 | S -> I1 | none | 532 | S | 130 | 2001:db8:0:2::2 | S -> I2 | none | 533 | I1 | 129 | 2001:db8:0:3::2 | I1 -> I3 | none | 534 | I2 | 129 | 2001:db8:0:4::2 | I2 -> I3 | none | 535 | I3 | 129 | 2001:db8:0:b::2 | I3 -> D | none | 536 +---------------+-----+-----------------+------------+--------------+ 538 Table 2: Strictly Routed SIDs 540 Table 2 describes SFIB entries that are instantiated on specific 541 nodes. All of these SFIB entries represent strictly-routed segments. 543 A.1. Loose Source Routing 545 In this example, Node S sends a packet to Node D, specifying loose 546 source route through Node I3. In this example, the first node in the 547 path, I3, does not appear in the CRH segment list. Therefore, the 548 destination node may not be able to send return traffic through the 549 same path. 551 +-------------------------------------+-------------------+ 552 | As the packet travels from S to I3: | | 553 +-------------------------------------+-------------------+ 554 | Source Address = 2001:db8::a | Last Entry = 0 | 555 | Destination Address = 2001:db8::3 | Segments Left = 1 | 556 | | SID[0] = 11 | 557 +-------------------------------------+-------------------+ 559 +-------------------------------------+-------------------+ 560 | As the packet travels from I3 to D: | | 561 +-------------------------------------+-------------------+ 562 | Source Address = 2001:db8::a | Last Entry = 0 | 563 | Destination Address = 2001:db8::b | Segments Left = 0 | 564 | | SID[0] = 11 | 565 +-------------------------------------+-------------------+ 567 A.2. Loose Source Routing Preserving The First SID 569 In this example, Node S sends a packet to Node D, specifying loose 570 source route through Node I3. In this example, the first node in the 571 path, I3, appears in the CRH segment list. Therefore, the 572 destination node can send return traffic through the same path. 574 +-------------------------------------+-------------------+ 575 | As the packet travels from S to I3: | | 576 +-------------------------------------+-------------------+ 577 | Source Address = 2001:db8::a | Last Entry = 1 | 578 | Destination Address = 2001:db8::3 | Segments Left = 1 | 579 | | SID[0] = 11 | 580 | | SID[1] = 3 | 581 +-------------------------------------+-------------------+ 583 +-------------------------------------+-------------------+ 584 | As the packet travels from I3 to D: | | 585 +-------------------------------------+-------------------+ 586 | Source Address = 2001:db8::a | Last Entry = 1 | 587 | Destination Address = 2001:db8::b | Segments Left = 0 | 588 | | SID[0] = 11 | 589 | | SID[1] = 3 | 590 +-------------------------------------+-------------------+ 592 A.3. Strict Source Routing 594 In this example, Node S sends a packet to Node D, specifying the 595 strict source route through I1 and I3. 597 +---------------------------------------+-------------------+ 598 | As the packet travels from S to I1: | | 599 +---------------------------------------+-------------------+ 600 | Source Address = 2001:db8::a | Last Entry = 1 | 601 | Destination Address = 2001:db8:0:1::2 | Segments Left = 2 | 602 | | SID[0] = 129 | 603 | | SID[1] = 129 | 604 +---------------------------------------+-------------------+ 606 +---------------------------------------+-------------------+ 607 | As the packet travels from I1 to I3: | | 608 +---------------------------------------+-------------------+ 609 | Source Address = 2001:db8::a | Last Entry = 1 | 610 | Destination Address = 2001:db8:0:3::2 | Segments Left = 1 | 611 | | SID[0] = 129 | 612 | | SID[1] = 129 | 613 +---------------------------------------+-------------------+ 614 +---------------------------------------+-------------------+ 615 | As the packet travels from I3 to D: | | 616 +---------------------------------------+-------------------+ 617 | Source Address = 2001:db8::a | Last Entry = 1 | 618 | Destination Address = 2001:db8:0:b::2 | Segments Left = 0 | 619 | | SID[0] = 129 | 620 | | SID[1] = 129 | 621 +---------------------------------------+-------------------+ 623 Authors' Addresses 625 Ron Bonica 626 Juniper Networks 627 2251 Corporate Park Drive 628 Herndon, Virginia 20171 629 USA 631 Email: rbonica@juniper.net 633 Yuji Kamite 634 NTT Communications Corporation 635 3-4-1 Shibaura, Minato-ku 636 Tokyo 108-8118 637 Japan 639 Email: : y.kamite@ntt.com 641 Tomonobu Niwa 642 KDDI 643 3-22-7, Yoyogi, Shibuya-ku 644 Tokyo 151-0053 645 Japan 647 Email: to-niwa@kddi.com 649 Andrew Alston 650 Liquid Telecom 651 Nairobi 652 Kenya 654 Email: Andrew.Alston@liquidtelecom.com 655 Daniam Henriques 656 Liquid Telecom 657 Johannesburg 658 South Africa 660 Email: daniam.henriques@liquidtelecom.com 662 Ning So 663 Reliance Jio 664 3010 Gaylord PKWY, Suite 150 665 Frisco, Texas 75034 666 USA 668 Email: Ning.So@ril.com 670 Fengman Xu 671 Reliance Jio 672 3010 Gaylord PKWY, Suite 150 673 Frisco, Texas 75034 674 USA 676 Email: Fengman.Xu@ril.com 678 Gang Chen 679 Baidu 680 No.10 Xibeiwang East Road Haidian District 681 Beijing 100193 682 P.R. China 684 Email: phdgang@gmail.com 686 Yongqing Zhu 687 China Telecom 688 109 West Zhongshan Ave, Tianhe District 689 Guangzhou 690 P.R. China 692 Email: zhuyq.gd@chinatelecom.cn 693 Guangming Yang 694 China Telecom 695 109 West Zhongshan Ave, Tianhe District 696 Guangzhou 697 P.R. China 699 Email: yanggm.gd@chinatelecom.cn 701 Yifeng Zhou 702 ByteDance 703 Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian District 704 Beijing 100000 705 P.R. China 707 Email: yifeng.zhou@bytedance.com