idnits 2.17.1 draft-ietf-6man-segment-routing-header-15.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 (October 22, 2018) is 2005 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 213 -- Looks like a reference, but probably isn't: '8' on line 890 -- Looks like a reference, but probably isn't: '9' on line 890 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == Outdated reference: A later version (-02) exists of draft-filsfils-spring-srv6-interop-01 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track S. Previdi 5 Expires: April 25, 2019 Huawei 6 J. Leddy 7 Individual 8 S. Matsushima 9 Softbank 10 D. Voyer, Ed. 11 Bell Canada 12 October 22, 2018 14 IPv6 Segment Routing Header (SRH) 15 draft-ietf-6man-segment-routing-header-15 17 Abstract 19 Segment Routing can be applied to the IPv6 data plane using a new 20 type of Routing Extension Header. This document describes the 21 Segment Routing Extension Header and how it is used by Segment 22 Routing capable nodes. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in BCP 29 14 [RFC2119] [RFC8174] when, and only when, they appear in all 30 capitals, as shown here. 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 April 25, 2019. 49 Copyright Notice 51 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Segment Routing Extension Header . . . . . . . . . . . . . . 4 68 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 6 70 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 7 71 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 10 73 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11 74 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11 75 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 11 76 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11 77 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 12 78 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12 79 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12 80 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 12 81 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 14 82 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 15 83 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 15 84 4.3.5. Load Balancing and ECMP . . . . . . . . . . . . . . . 15 85 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 15 86 5.1. Abstract Representation of an SRH . . . . . . . . . . . . 15 87 5.2. Example Topology . . . . . . . . . . . . . . . . . . . . 16 88 5.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 17 89 5.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 17 90 5.3.2. Transit Packet Through SR Domain . . . . . . . . . . 17 91 5.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 18 92 5.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 18 93 6. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 18 94 6.1. Nodes Within the SR domain . . . . . . . . . . . . . . . 18 95 6.2. Nodes Outside the SR Domain . . . . . . . . . . . . . . . 18 96 6.2.1. SR Source Nodes Not Directly Connected . . . . . . . 19 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 99 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 21 100 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 21 101 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 22 102 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 22 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 104 8.1. Segment Routing Header Flags Register . . . . . . . . . . 23 105 8.2. Segment Routing Header TLVs Register . . . . . . . . . . 23 106 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 107 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 24 108 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 24 109 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 24 111 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 24 112 9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 25 113 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 114 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 116 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 117 12.2. Informative References . . . . . . . . . . . . . . . . . 26 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 120 1. Introduction 122 Segment Routing can be applied to the IPv6 data plane using a new 123 type of Routing Extension Header (SRH). This document describes the 124 Segment Routing Extension Header and how it is used by Segment 125 Routing capable nodes. 127 The Segment Routing Architecture [RFC8402] describes Segment Routing 128 and its instantiation in two data planes MPLS and IPv6. 130 SR with the MPLS data plane is defined in 131 [I-D.ietf-spring-segment-routing-mpls]. 133 SR with the IPv6 data plane is defined in 134 [I-D.filsfils-spring-srv6-network-programming]. 136 The encoding of MPLS labels and label stacking are defined in 137 [RFC3032]. 139 The encoding of IPv6 segments in the Segment Routing Extension Header 140 is defined in this document. 142 Terminology used within this document is defined in detail in 143 [RFC8402]. Specifically, these terms: Segment Routing, SR Domain, 144 SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy. 146 2. Segment Routing Extension Header 148 Routing Headers are defined in [RFC8200]. The Segment Routing Header 149 has a new Routing Type (suggested value 4) to be assigned by IANA. 151 The Segment Routing Header (SRH) is defined as follows: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Last Entry | Flags | Tag | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 | Segment List[0] (128 bits IPv6 address) | 162 | | 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | 166 | | 167 ... 168 | | 169 | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 | Segment List[n] (128 bits IPv6 address) | 173 | | 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 // // 177 // Optional Type Length Value objects (variable) // 178 // // 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 where: 183 o Next Header: Defined in [RFC8200] 185 o Hdr Ext Len: Defined in [RFC8200] 187 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 189 o Segments Left: Defined in [RFC8200] 191 o Last Entry: contains the index (zero based), in the Segment List, 192 of the last element of the Segment List. 194 o Flags: 8 bits of flags. Following flags are defined: 196 0 1 2 3 4 5 6 7 197 +-+-+-+-+-+-+-+-+ 198 |U U U U U U U U| 199 +-+-+-+-+-+-+-+-+ 201 U: Unused and for future use. MUST be 0 on transmission and 202 ignored on receipt. 204 o Tag: tag a packet as part of a class or group of packets, e.g., 205 packets sharing the same set of properties. When tag is not used 206 at source it MUST be set to zero on transmission. When tag is not 207 used during SRH Processing it SHOULD be ignored. The allocation 208 and use of tag is outside the scope of this document. 210 o Segment List[n]: 128 bit IPv6 addresses representing the nth 211 segment in the Segment List. The Segment List is encoded starting 212 from the last segment of the SR Policy. I.e., the first element 213 of the segment list (Segment List [0]) contains the last segment 214 of the SR Policy, the second element contains the penultimate 215 segment of the SR Policy and so on. 217 o Type Length Value (TLV) are described in Section 2.1. 219 2.1. SRH TLVs 221 This section defines TLVs of the Segment Routing Header. 223 0 1 224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 226 | Type | Length | Variable length data 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 229 Type: An 8 bit value. Unrecognized Types MUST be ignored on receipt. 231 Length: The length of the Variable length data. It is RECOMMENDED 232 that the total length of new TLVs be multiple of 8 bytes to avoid the 233 use of Padding TLVs. 235 Variable length data: Length bytes of data that is specific to the 236 Type. 238 Type Length Value (TLV) contain OPTIONAL information that may be used 239 by the node identified in the Destination Address (DA) of the packet. 241 Each TLV has its own length, format and semantic. The code-point 242 allocated (by IANA) to each TLV Type defines both the format and the 243 semantic of the information carried in the TLV. Multiple TLVs may be 244 encoded in the same SRH. 246 TLVs may change en route at each segment. To identify when a TLV 247 type may change en route the most significant bit of the Type has the 248 following significance: 250 0: TLV data does not change en route 252 1: TLV data does change en route 254 Identifying which TLVs change en route, without having to understand 255 the Type, is required for Authentication Header Integrity Check Value 256 (ICV) computation. Any TLV that changes en route is considered 257 mutable for the purpose of ICV computation, the Type Length and 258 Variable Length Data is ignored for the purpose of ICV Computation as 259 defined in [RFC4302]. 261 The "Length" field of the TLV is used to skip the TLV while 262 inspecting the SRH in case the node doesn't support or recognize the 263 Type. The "Length" defines the TLV length in octets, not including 264 the "Type" and "Length" fields. 266 The following TLVs are defined in this document: 268 Padding TLV 270 HMAC TLV 272 Additional TLVs may be defined in the future. 274 2.1.1. Padding TLVs 276 There are two types of padding TLVs, pad0 and padN, the following 277 applies to both: 279 Padding TLVs are used to pad the TLVs to a multiple of 8 octets. 281 More than one Padding TLV MUST NOT appear in the SRH. 283 The Padding TLVs are used to align the SRH total length on the 8 284 octet boundary. 286 When present, a single Pad0 or PadN TLV MUST appear as the last 287 TLV. 289 When present, a PadN TLV MUST have a length from 0 to 5 in order 290 to align the SRH total length on a 8-octet boundary. 292 Padding TLVs are ignored by a node processing the SRH TLV, even if 293 more than one is present. 295 Padding TLVs are ignored during ICV calculation. 297 2.1.1.1. PAD0 299 0 1 2 3 4 5 6 7 300 +-+-+-+-+-+-+-+-+ 301 | Type | 302 +-+-+-+-+-+-+-+-+ 304 Type: to be assigned by IANA (Suggested value 128) 306 A single Pad0 TLV MUST be used when a single byte of padding is 307 required. If more than one byte of padding is required a Pad0 TLV 308 MUST NOT be used, the PadN TLV MUST be used. 310 2.1.1.2. PADN 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type | Length | Padding (variable) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 // Padding (variable) // 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Type: to be assigned by IANA (suggested value 129). 322 Length: 0 to 5 324 Padding: Length octets of padding. Padding bits have no 325 semantics. They MUST be set to 0 on transmission and ignored on 326 receipt. 328 The PadN TLV MUST be used when more than one byte of padding is 329 required. 331 2.1.2. HMAC TLV 333 The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL 334 and has the following format: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | RESERVED | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | HMAC Key ID (4 octets) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | // 344 | HMAC (32 octets) // 345 | // 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 where: 350 o Type: to be assigned by IANA (suggested value 5). 352 o Length: 38. 354 o RESERVED: 2 octets. MUST be 0 on transmission and ignored on 355 receipt. 357 o HMAC Key ID: A 4 octet opaque number which uniquely identifies the 358 pre-shared key and algorithm used to generate the HMAC. If 0, the 359 HMAC is not included. 361 o HMAC: 32 octets of keyed HMAC, not present if Key ID is 0. 363 The HMAC TLV is used to verify the source of a packet is permitted to 364 use the current segment in the destination address of the packet, and 365 ensure the segment list is not modified in transit. 367 2.1.2.1. HMAC generation 369 The HMAC field is the output of the HMAC computation as defined in 370 [RFC2104], using: 372 o key: the pre-shared key identified by HMAC Key ID 374 o HMAC algorithm: identified by the HMAC Key ID 376 o Text: a concatenation of the following fields from the IPv6 header 377 and the SRH, as it would be received at the node verifying the 378 HMAC: 380 * IPv6 header: source address (16 octets) 382 * IPv6 header: destination address (16 octets) 383 * SRH: Segments Left (1 octet) 385 * SRH: Last Entry (1 octet) 387 * SRH: Flags (1 octet) 389 * SRH: HMAC Key-id (4 octets) 391 * SRH: all addresses in the Segment List (variable octets) 393 The HMAC digest is truncated to 32 octets and placed in the HMAC 394 field of the HMAC TLV. 396 For HMAC algorithms producing digests less than 32 octets, the digest 397 is placed in the lowest order octets of the HMAC field. Remaining 398 octets MUST be set to zero. 400 2.1.2.2. HMAC Verification 402 Local policy determines when to check for an HMAC and potentially a 403 requirement on where the HMAC TLV must appear (e.g. first TLV). 404 This local policy is outside the scope of this document. It may be 405 based on the active segment at an SR Segment endpoint node, the 406 result of an ACL that considers incoming interface, or other packet 407 fields. 409 If HMAC verification is successful, the packet is forwarded to the 410 next segment. 412 If HMAC verification fails, an ICMP error message (parameter problem, 413 error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate 414 limited) and SHOULD be logged. 416 2.1.2.3. HMAC Pre-Shared Key Algorithm 418 The HMAC Key ID field allows for the simultaneous existence of 419 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 420 well as pre-shared keys. 422 The HMAC Key ID field is opaque, i.e., it has neither syntax nor 423 semantic except as an identifier of the right combination of pre- 424 shared key and hash algorithm, and except that a value of 0 means 425 that there is no HMAC field. 427 At the HMAC TLV verification node the Key ID uniquely identifies the 428 pre-shared key and HMAC algorithm. 430 At the HMAC TLV generating node the Key ID and destination address 431 uniquely identify the pre-shared key and HMAC algorithm. Utilizing 432 the destination address with the Key ID allows for overlapping key 433 IDs amongst different HMAC verification nodes. The Text for the HMAC 434 computation is set to the IPv6 header fields and SRH fields as they 435 would appear at the verification node, not necessarily the same as 436 the source node sending a packet with the HMAC TLV. 438 Pre-shared key roll-over is supported by having two key IDs in use 439 while the HMAC TLV generating node and verifying node converge to a 440 new key. 442 SRH implementations can support multiple hash functions but MUST 443 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 445 The selection of pre-shared key and algorithm, and their distribution 446 is outside the scope of this document, some options may include: 448 o in the configuration of the HMAC generating or verifying nodes, 449 either by static configuration or any SDN oriented approach 451 o dynamically using a trusted key distribution protocol such as 452 [RFC6407] 454 3. SR Nodes 456 There are different types of nodes that may be involved in segment 457 routing networks: source SR nodes originate packets with a segment in 458 the destination address of the IPv6 header, transit nodes that 459 forward packets destined to a remote segment, and SR segment endpoint 460 nodes that process a local segment in the destination address of an 461 IPv6 header. 463 3.1. Source SR Node 465 A Source SR Node is any node that originates an IPv6 packet with a 466 segment (i.e. SRv6 SID) in the destination address of the IPv6 467 header. The packet leaving the source SR Node may or may not contain 468 an SRH. This includes either: 470 A host originating an IPv6 packet. 472 An SR domain ingress router encapsulating a received packet in an 473 outer IPv6 header, followed by an optional SRH. 475 The mechanism through which a segment in the destination address of 476 the IPv6 header and the Segment List in the SRH, is derived is 477 outside the scope of this document. 479 3.2. Transit Node 481 A transit node is any node forwarding an IPv6 packet where the 482 destination address of that packet is not locally configured as a 483 segment nor a local interface. A transit node is not required to be 484 capable of processing a segment nor SRH. 486 3.3. SR Segment Endpoint Node 488 A SR segment endpoint node is any node receiving an IPv6 packet where 489 the destination address of that packet is locally configured as a 490 segment or local interface. 492 4. Packet Processing 494 This section describes SRv6 packet processing at the SR source, 495 Transit and SR segment endpoint nodes. 497 4.1. Source SR Node 499 A Source node steers a packet into an SR Policy. If the SR Policy 500 results in a segment list containing a single segment, and there is 501 no need to add information to SRH flag or TLV, the DA is set to the 502 single segment list entry and the SRH MAY be omitted. 504 When needed, the SRH is created as follows: 506 Next Header and Hdr Ext Len fields are set as specified in 507 [RFC8200]. 509 Routing Type field is set as TBD (to be allocated by IANA, 510 suggested value 4). 512 The DA of the packet is set with the value of the first segment. 514 The first element of the SRH Segment List is the ultimate segment. 515 The second element is the penultimate segment and so on. 517 The Segments Left field is set to n-1 where n is the number of 518 elements in the SR Policy. 520 The Last Entry field is set to n-1 where n is the number of 521 elements in the SR Policy. 523 HMAC TLV may be set according to Section 7. 525 The packet is forwarded toward the packet's Destination Address 526 (the first segment). 528 4.1.1. Reduced SRH 530 When a source does not require the entire SID list to be preserved in 531 the SRH, a reduced SRH may be used. 533 A reduced SRH does not contain the first segment of the related SR 534 Policy (the first segment is the one already in the DA of the IPv6 535 header), and the Last Entry field is set to n-2 where n is the number 536 of elements in the SR Policy. 538 4.2. Transit Node 540 As specified in [RFC8200], the only node allowed to inspect the 541 Routing Extension Header (and therefore the SRH), is the node 542 corresponding to the DA of the packet. Any other transit node MUST 543 NOT inspect the underneath routing header and MUST forward the packet 544 toward the DA according to its IPv6 routing table. 546 When a SID is in the destination address of an IPv6 header of a 547 packet, it's routed through an IPv6 network as an IPv6 address. 548 SIDs, or the prefix(es) covering SIDs, and their reachability may be 549 distributed by means outside the scope of this document. For 550 example, [RFC5308] or [RFC5340] may be used to advertise a prefix 551 covering the SIDs on a node. 553 4.3. SR Segment Endpoint Node 555 Without constraining the details of an implementation, the SR segment 556 endpoint node creates Forwarding Information Base (FIB) entries for 557 its local SIDs. 559 When an SRv6-capable node receives an IPv6 packet, it performs a 560 longest-prefix-match lookup on the packets destination address. This 561 lookup can return any of the following: 563 A FIB entry that represents a locally instantiated SRv6 SID 564 A FIB entry that represents a local interface, not locally 565 instantiated as an SRv6 SID 566 A FIB entry that represents a non-local route 567 No Match 569 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID 571 This document, and section, defines a single SRv6 SID called END. 572 Future documents may define additional SRv6 SIDs. In which case, the 573 entire content of this section will be defined in that document. 575 If the FIB entry represents a locally instantiated SRv6 SID, process 576 the next header of the IPv6 header as defined in section 4 of 577 [RFC8200] 579 The following sections describe the actions to take while processing 580 next header fields. 582 4.3.1.1. SRH Processing 584 When an SRH is processed { 585 If Segments Left is equal to zero { 586 Proceed to process the next header in the packet, whose type 587 is identified by the Next Header field in the Routing header. 588 } 589 Else { 590 If local policy requires TLV processing { 591 Perform TLV processing (see TLV Processing) 592 } 593 max_last_entry = ( Hdr Ext Len / 2 ) - 1 595 If ((Last Entry > max_last_entry) or 596 (Segments Left is greater than (Last Entry+1)) { 597 Send an ICMP Parameter Problem, Code 0, message to the 598 Source Address, pointing to the Segments Left field, and 599 discard the packet. 600 } 601 Else { 602 Decrement Segments Left by 1. 603 Copy Segment List[Segments Left] from the SRH to the 604 destination address of the IPv6 header. 605 If the IPv6 Hop Limit is less than or equal to 1 { 606 Send an ICMP Time Exceeded -- Hop Limit Exceeded in 607 Transit message to the Source Address and discard 608 the packet. 609 } 610 Else { 611 Decrement the Hop Limit by 1 612 Resubmit the packet to the IPv6 module for transmission 613 to the new destination. 614 } 615 } 616 } 617 } 619 4.3.1.1.1. TLV Processing 621 Local policy determines how TLV's are to be processed when the Active 622 Segment is a local END SID. The definition of local policy is 623 outside the scope of this document. 625 For illustration purpose only, two example local policies that may be 626 associated with an END SID are provided below. 628 Example 1: 629 For any packet received from interface I2 630 Skip TLV processing 632 Example 2: 633 For any packet received from interface I1 634 If first TLV is HMAC { 635 Process the HMAC TLV 636 } 637 Else { 638 Discard the packet 639 } 641 4.3.1.2. Upper-layer Header or No Next Header 643 Send an ICMP parameter problem message to the Source Address and 644 discard the packet. Error code (TBD by IANA) "SR Upper-layer Header 645 Error", pointer set to the offset of the upper-layer header. 647 A unique error code allows an SR Source node to recognize an error in 648 SID processing at an endpoint. 650 4.3.2. FIB Entry is a Local Interface 652 If the FIB entry represents a local interface, not locally 653 instantiated as an SRv6 SID, the SRH is processed as follows: 655 If Segments Left is zero, the node must ignore the Routing header 656 and proceed to process the next header in the packet, whose type 657 is identified by the Next Header field in the Routing Header. 659 If Segments Left is non-zero, the node must discard the packet and 660 send an ICMP Parameter Problem, Code 0, message to the packet's 661 Source Address, pointing to the unrecognized Routing Type. 663 4.3.3. FIB Entry Is A Non-Local Route 665 Processing is not changed by this document. 667 4.3.4. FIB Entry Is A No Match 669 Processing is not changed by this document. 671 4.3.5. Load Balancing and ECMP 673 Within an SR domain, an SR source node encapsulates a packet in an 674 outer IPv6 header for transport to an endpoint. The SR source node 675 MUST impose a flow label computed based on the inner packet. The 676 computation of the flow label is as recommended in [RFC6438] for the 677 sending Tunnel End Point. 679 At any transit node within an SR domain, the flow label MUST be used 680 as defined in [RFC6438] to calculate the ECMP hash toward the 681 destination address. If flow label is not used, the transit node may 682 hash all packets between a pair of SR Edge nodes to the same link. 684 At an SR segment endpoint node, the flow label MUST be used as 685 defined in [RFC6438] to calculate any ECMP hash used to forward the 686 processed packet to the next segment. 688 5. Illustrations 690 This section provides illustrations of SRv6 packet processing at SR 691 source, transit and SR segment endpoint nodes. 693 5.1. Abstract Representation of an SRH 695 For a node k, its IPv6 address is represented as Ak, its SRv6 SID is 696 represented as Sk. 698 IPv6 headers are represented as the tuple of (source, destination). 699 For example, a packet with source address A1 and destination address 700 A2 is represented as (A1,A2). The payload of the packet is omitted. 702 An SR Policy is a list of segments. A list of segments is 703 represented as where S1 is the first SID to visit, S2 is 704 the second SID to visit and S3 is the last SID to visit. 706 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 708 o Source Address is SA, Destination Addresses is DA, and next-header 709 is SRH. 711 o SRH with SID list with SegmentsLeft = SL. 713 o Note the difference between the <> and () symbols. 714 represents a SID list where the leftmost segment is the first 715 segment. Whereas, (S3, S2, S1; SL) represents the same SID list 716 but encoded in the SRH Segment List format where the leftmost 717 segment is the last segment. When referring to an SR policy in a 718 high-level use-case, it is simpler to use the 719 notation. When referring to an illustration of detailed behavior, 720 the (S3, S2, S1; SL) notation is more convenient. 722 At its SR Policy headend, the Segment List results in SRH 723 (S3,S2,S1; SL=2) represented fully as: 725 Segments Left=2 726 Last Entry=2 727 Flags=0 728 Tag=0 729 Segment List[0]=S3 730 Segment List[1]=S2 731 Segment List[2]=S1 733 5.2. Example Topology 735 The following topology is used in examples below: 737 + * * * * * * * * * * * * * * * * * * * * + 739 * [8] [9] * 740 | | 741 * | | * 742 [1]----[3]--------[5]----------------[6]---------[4]---[2] 743 * | | * 744 | | 745 * | | * 746 +--------[7]-------+ 747 * * 749 + * * * * * * * SR Domain * * * * * * * + 751 Figure 3 753 o 3 and 4 are SR Domain edge routers 755 o 5, 6, and 7 are all SR Domain routers 757 o 8 and 9 are hosts within the SR Domain 758 o 1 and 2 are hosts outside the SR Domain 760 5.3. Source SR Node 762 5.3.1. Intra SR Domain Packet 764 When host 8 sends a packet to host 9 via an SR Policy the 765 packet is 767 P1: (A8,S7)(A9,S7; SL=1) 769 5.3.1.1. Reduced Variant 771 When host 8 sends a packet to host 9 via an SR Policy and it 772 wants to use a reduced SRH, the packet is 774 P2: (A8,S7)(A9; SL=1) 776 5.3.2. Transit Packet Through SR Domain 778 When host 1 sends a packet to host 2, the packet is 780 P3: (A1,A2) 782 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 783 egress router 4 via an SR Policy . Router 3 encapsulates the 784 received packet P3 in an outer header with an SRH. The packet is 786 P4: (A3, S7)(S4, S7; SL=1)(A1, A2) 788 If the SR Policy contains only one segment (the egress router 4), the 789 ingress Router 3 encapsulates P3 into an outer header (A3, S4). The 790 packet is 792 P5: (A3, S4)(A1, A2) 794 5.3.2.1. Reduced Variant 796 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 797 egress router 4 via an SR Policy . If router 3 wants to use 798 a reduced SRH, Router 3 encapsulates the received packet P3 in an 799 outer header with a reduced SRH. The packet is 801 P6: (A3, S7)(S4; SL=1)(A1, A2) 803 5.4. Transit Node 805 Nodes 5 acts as transit nodes for packet P1, and sends packet 807 P1: (A8,S7)(A9,S7;SL=1) 809 on the interface toward node 7. 811 5.5. SR Segment Endpoint Node 813 Node 7 receives packet P1 and, using the logic in section 4.3.1, 814 sends packet 816 P7: (A8,A9)(A9,S7; SL=0) 818 on the interface toward router 6. 820 6. Deployment Models 822 6.1. Nodes Within the SR domain 824 SR Source Nodes within an SR Domain are trusted to generate IPv6 825 packets with SRH. SR segment endpoint nodes receiving packets on 826 interface that are part of the SR Domain may process any packet 827 destined to a local segment, containing an SRH. 829 A SR Source Node connected to the SR Domain via a secure tunnel, e.g. 830 IPSec tunnel mode [RFC4303] or Ethernet pseudowire [RFC4448], may be 831 considered trusted and directly connected. Some types of tunnels may 832 result in additional processing overhead that should be considered in 833 a deployment. 835 6.2. Nodes Outside the SR Domain 837 Nodes outside the SR Domain cannot be trusted. SR Domain Ingress 838 routers SHOULD discard packets destined to SIDs within the SR Domain 839 (regardless of the presence of an SRH) to avoid attacks on the SR 840 Domain as described and referenced in [RFC5095]. As an additional 841 layer of protection, SR Segment Endpoint nodes SHOULD discard packets 842 destined to local SIDs from source addresses not part of the SR 843 Domain. 845 For example, using the example topology from section 5, all SIDs in 846 the SR Domain (SIDS S1-S9) are assigned within a single IPv6 prefix, 847 Prefix-S. All SIDs assigned to a node k are assigned within a single 848 IPv6 prefix Prefix-Sk, all addresses permitted to source packets 849 destined to SIDs in the SR Domain are assigned within a single IPv6 850 prefix Prefix-A. 852 An Infrastructure Access List (IACL), applied to the external 853 interfaces of SR Domain ingress nodes 3 and 4, that discards packets 854 destined to a SID covered by Prefix-S is used to discard packets 855 destined to SIDs within the SR Domain. 857 An IACL, applied to each interface of SR Segment Endpoint Nodes k, 858 that discards packets destined to a SID covered by Prefix-Sk with a 859 source address not covered by Prefix-A. 861 Failure to implement a method of ingress filtering, as defined above, 862 exposes the SR domain to source routing attacks from nodes outside 863 the SR Domain, as described and referenced in [RFC5095]. 865 6.2.1. SR Source Nodes Not Directly Connected 867 Nodes outside the SR Domain may request, by some trusted means 868 outside the scope of this document, a complete SRH including an HMAC 869 TLV which is computed correctly for the SRH. 871 SR Domain ingress routers permit traffic destined to select SIDs with 872 local policy requiring HMAC TLV processing for those select SIDs, 873 i.e. those SIDs provide a gateway to the SR Domain for a set of 874 segment lists. 876 If HMAC verification is successful, the packet is forwarded to the 877 next segment. Within the SR Domain no further HMAC check need be 878 performed. 880 If HMAC verification fails, an ICMP error message (parameter problem, 881 error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate 882 limited) and SHOULD be logged. 884 For example, extending the topology defined in Figure 3, consider 885 node 3 offering access to a premium SLA service to node 20. Node 20 886 is a trusted SR Source not directly connected to the SR Domain. 888 + * * * * * * * * * * * * * * * * * * * * + 890 * [8] [9] * 891 | | 892 * | | * 893 [20]--[11]--[3]--------[5]----------------[6]---------[4]---[2] 894 * | | * 895 | | 896 * | | * 897 +--------[7]-------+ 898 * * 900 + * * * * * * * SR Domain * * * * * * * + 902 In order to access the SLA service, node 20 must be able to access 903 segments within the SR Domain. To provide a secure entry point for 904 the SLA service, SIDs with local policy requiring HMAC verification 905 at node k are defined as Hk and assigned from a prefix Prefix-H. 906 Prefix-H is disjoint with Prefix-S and Prefix-A defined earlier. 908 Prefix-H is not part of the IACLs applied at the external facing 909 interfaces of node 3 and 4, allowing external nodes access to it. 911 SID H3 is a SID covered by Prefix-H at node 3. 913 Node 20 requests the premium SLA service to node 2 and is provided a 914 pre-computed SRH and HMAC with destination address H3. 916 Node 20 sends a packet with destination addresses set to H2, SRH and 917 HMAC TLV are as provided for the premium SLA service. 919 Node 3 receives the packet and verifies the HMAC as defined in 920 section 4.3, forwarding the packet to the next segment in the segment 921 list or dropping it based on the HMAC result. 923 This use of an HMAC is particularly valuable within an enterprise 924 based SR Domain to authenticate a host which is using SRv6 segment 925 routing as documented in [SRN]. In that example, the HMAC is used to 926 validate a source node is using a permitted segment list. 928 7. Security Considerations 930 This section reviews security considerations related to the SRH, 931 given the SRH processing and deployment models discussed in this 932 document. 934 As describe in Section 6, it is necessary to filter packets ingress 935 to the SR Domain destined to segments within the SR Domain. This 936 ingress filtering is via an IACL at SR Domain ingress border nodes. 937 Additional protection is applied via an IACL at each SR Segment 938 Endpoint node, filtering packets not from within the SR Domain, 939 destined to SIDs in the SR Domain. ACLs are easily supported for 940 small numbers of prefixes, making summarization important, and when 941 the prefixes requiring filtering is kept to a seldom changing set. 943 Additionally, ingress filtering of IPv6 source addresses as 944 recommended in BCP38 SHOULD be used. 946 SR Source Nodes not directly connected to the SR Domain may access 947 specific sets of segments within the SR Domain when secured with the 948 SRH HMAC TLV. The SRH HMAC TLV provides a means of verifying the 949 validity of ingress packets SRH, limiting access to the segments in 950 the SR Domain to only those source nodes with permission. 952 7.1. Source Routing Attacks 954 [RFC5095] deprecates the Type 0 Routing header due to a number of 955 significant attacks that are referenced in that document. Such 956 attacks include bypassing filtering devices, reaching otherwise 957 unreachable Internet systems, network topology discovery, bandwidth 958 exhaustion, and defeating anycast. 960 Because this document specifies that the SRH is for use within an SR 961 domain protected by ingress filtering via IACLs, and by 962 cryptographically authenticated SR source nodes not directly 963 connected to the SR Domain; such attacks cannot be mounted from 964 outside an SR Domain. As specified in this document, SR Domain 965 ingress edge nodes drop packets entering the SR Domain destined to 966 segments within the SR Domain. 968 Aditionally, this document specifies the use of IACL on SR Segment 969 Endpoint nodes within the SR Domain to limit the source addresses 970 permitted to send packets to a SID in the SR Domain. 972 Such attacks may, however, be mounted from within the SR Domain, from 973 nodes permitted to source traffic to SIDs in the domain. As such, 974 these attacks and other known attacks on an IP network (e.g. DOS/ 975 DDOS, topology discovery, man-in-the-middle, traffic interception/ 976 siphoning), can occur from compromised nodes within an SR Domain. 978 7.2. Service Theft 980 Service theft is defined as the use of a service offered by the SR 981 Domain by a node not authorized to use the service. 983 Service theft is not a concern within the SR Domain as all SR Source 984 nodes and SR segment endpoint nodes within the domain are able to 985 utilizing the services of the Domain. If a node outside the SR 986 Domain learns of segments or a topological service within the SR 987 domain, IACL filtering denies access to those segments. 989 Nodes outside the SR Domain, capable of intercepting packets from SR 990 Source nodes not directly connected to the SR Domain utilizing the 991 SRH HMAC, may steel the outer IP header SRH and HMAC TLV. If such an 992 attacker is capable of spoofing the source address of the original 993 sender it may use the IP header and HMAC to access services of the SR 994 Domain intended for the original SR Source node. 996 Frequent rekeying of the HMAC TLV helps mitigate against this attack 997 but cannot prevent it. 999 However, as described in Section 6.2.1, there exist use cases where 1000 the risk of service threat is of minimum concern and the HMAC TLV is 1001 used primarily to validate that the source is permitted to use the 1002 segment list in the SRH. 1004 7.3. Topology Disclosure 1006 The SRH may contains SIDs of some intermediate SR-nodes in the path 1007 towards the destination, this reveals those addresses to attackers if 1008 they are able to intercept packets containing SRH. 1010 This is applicable within an SR Domain but the disclosure is less 1011 relevant as an attacker has other means of learning topology. 1013 For an SR Source node not directly connected to the SR Domain this 1014 disclosure is applicable. While the segments within the SR domain 1015 disclosed in SRH are protected by ingress filtering, they may be 1016 learned by an attacker external to the SR Domain. 1018 As described in Section 6.2.1, there exist use cases where the risk 1019 of topology disclosure is of minimum concern when the HMAC TLV is 1020 used primarily to validate that the source is permitted to use the 1021 segment list in the SRH. 1023 7.4. ICMP Generation 1025 The generation of ICMPv6 error messages may be used to attempt 1026 denial-of-service attacks by sending an error-causing destination 1027 address or SRH in back-to-back packets. An implementation that 1028 correctly follows Section 2.4 of [RFC4443] would be protected by the 1029 ICMPv6 rate-limiting mechanism. 1031 8. IANA Considerations 1033 This document makes the following registrations in the Internet 1034 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1035 maintained by IANA: 1037 Suggested Description Reference 1038 Value 1039 ---------------------------------------------------------- 1040 4 Segment Routing Header (SRH) This document 1042 This document request IANA to create and maintain a new Registry: 1043 "Segment Routing Header TLVs" 1045 8.1. Segment Routing Header Flags Register 1047 This document requests the creation of a new IANA managed registry to 1048 identify SRH Flags Bits. The registration procedure is "Expert 1049 Review" as defined in [RFC8126]. Suggested registry name is "Segment 1050 Routing Header Flags". Flags is 8 bits, the following bits are 1051 defined in this document: 1053 Suggested Description Reference 1054 Bit 1055 ----------------------------------------------------- 1056 4 HMAC This document 1058 8.2. Segment Routing Header TLVs Register 1060 This document requests the creation of a new IANA managed registry to 1061 identify SRH TLVs. The registration procedure is "Expert Review" as 1062 defined in [RFC8126]. Suggested registry name is "Segment Routing 1063 Header TLVs". A TLV is identified through an unsigned 8 bit 1064 codepoint value. The following codepoints are defined in this 1065 document: 1067 Suggested Description Reference 1068 Value 1069 ----------------------------------------------------- 1070 5 HMAC TLV This document 1071 128 Pad0 TLV This document 1072 129 PadN TLV This document 1074 9. Implementation Status 1076 This section is to be removed prior to publishing as an RFC. 1078 9.1. Linux 1080 Name: Linux Kernel v4.14 1082 Status: Production 1084 Implementation: adds SRH, performs END processing, supports HMAC TLV 1086 Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and 1087 [I-D.filsfils-spring-srv6-interop] 1089 9.2. Cisco Systems 1091 Name: IOS XR and IOS XE 1093 Status: Pre-production 1095 Implementation: adds SRH, performs END processing, no TLV processing 1097 Details: [I-D.filsfils-spring-srv6-interop] 1099 9.3. FD.io 1101 Name: VPP/Segment Routing for IPv6 1103 Status: Production 1105 Implementation: adds SRH, performs END processing, no TLV processing 1107 Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and 1108 [I-D.filsfils-spring-srv6-interop] 1110 9.4. Barefoot 1112 Name: Barefoot Networks Tofino NPU 1114 Status: Prototype 1116 Implementation: performs END processing, no TLV processing 1118 Details: [I-D.filsfils-spring-srv6-interop] 1120 9.5. Juniper 1122 Name: Juniper Networks Trio and vTrio NPU's 1124 Status: Prototype & Experimental 1125 Implementation: SRH insertion mode, Process SID where SID is an 1126 interface address, no TLV processing 1128 9.6. Huawei 1130 Name: Huawei Systems VRP Platform 1132 Status: Production 1134 Implementation: adds SRH, performs END processing, no TLV processing 1136 10. Contributors 1138 Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung, 1139 Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, 1140 Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre 1141 Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta 1142 Maglione, James Connolly, Aloys Augustin contributed to the content 1143 of this document. 1145 11. Acknowledgements 1147 The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, 1148 Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, 1149 and David Lebrun for their comments to this document. 1151 12. References 1153 12.1. Normative References 1155 [FIPS180-4] 1156 National Institute of Standards and Technology, "FIPS 1157 180-4 Secure Hash Standard (SHS)", March 2012, 1158 . 1161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1162 Requirement Levels", BCP 14, RFC 2119, 1163 DOI 10.17487/RFC2119, March 1997, 1164 . 1166 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1167 of Type 0 Routing Headers in IPv6", RFC 5095, 1168 DOI 10.17487/RFC5095, December 2007, 1169 . 1171 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1172 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1173 October 2011, . 1175 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1176 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1177 May 2017, . 1179 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1180 (IPv6) Specification", STD 86, RFC 8200, 1181 DOI 10.17487/RFC8200, July 2017, 1182 . 1184 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1185 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1186 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1187 July 2018, . 1189 12.2. Informative References 1191 [I-D.filsfils-spring-srv6-interop] 1192 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 1193 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 1194 "SRv6 interoperability report", draft-filsfils-spring- 1195 srv6-interop-01 (work in progress), September 2018. 1197 [I-D.filsfils-spring-srv6-network-programming] 1198 Filsfils, C., Camarillo, P., Leddy, J., 1199 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1200 Network Programming", draft-filsfils-spring-srv6-network- 1201 programming-05 (work in progress), July 2018. 1203 [I-D.ietf-spring-segment-routing-mpls] 1204 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1205 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1206 data plane", draft-ietf-spring-segment-routing-mpls-14 1207 (work in progress), June 2018. 1209 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1210 Hashing for Message Authentication", RFC 2104, 1211 DOI 10.17487/RFC2104, February 1997, 1212 . 1214 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1215 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1216 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1217 . 1219 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1220 DOI 10.17487/RFC4302, December 2005, 1221 . 1223 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1224 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1225 . 1227 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1228 Control Message Protocol (ICMPv6) for the Internet 1229 Protocol Version 6 (IPv6) Specification", STD 89, 1230 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1231 . 1233 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 1234 "Encapsulation Methods for Transport of Ethernet over MPLS 1235 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 1236 . 1238 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1239 DOI 10.17487/RFC5308, October 2008, 1240 . 1242 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1243 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1244 . 1246 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1247 for Equal Cost Multipath Routing and Link Aggregation in 1248 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1249 . 1251 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1252 Writing an IANA Considerations Section in RFCs", BCP 26, 1253 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1254 . 1256 [SRN] and , "Software Resolved Networks: Rethinking Enterprise 1257 Networks with IPv6 Segment Routing", 2018, 1258 . 1261 Authors' Addresses 1262 Clarence Filsfils (editor) 1263 Cisco Systems, Inc. 1264 Brussels 1265 BE 1267 Email: cfilsfil@cisco.com 1269 Stefano Previdi 1270 Huawei 1271 Italy 1273 Email: stefano@previdi.net 1275 John Leddy 1276 Individual 1277 US 1279 Email: john@leddy.net 1281 Satoru Matsushima 1282 Softbank 1284 Email: satoru.matsushima@g.softbank.co.jp 1286 Daniel Voyer (editor) 1287 Bell Canada 1289 Email: daniel.voyer@bell.ca