idnits 2.17.1 draft-ietf-6man-segment-routing-header-16.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 (February 4, 2019) is 1908 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 219 -- Looks like a reference, but probably isn't: '8' on line 883 -- Looks like a reference, but probably isn't: '9' on line 883 -- 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-06 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-18 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: August 8, 2019 Huawei 6 J. Leddy 7 Individual 8 S. Matsushima 9 Softbank 10 D. Voyer, Ed. 11 Bell Canada 12 February 4, 2019 14 IPv6 Segment Routing Header (SRH) 15 draft-ietf-6man-segment-routing-header-16 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 August 8, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 8 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 5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 15 85 5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 15 86 5.2. SR Domain as a single system with delegation among 87 components . . . . . . . . . . . . . . . . . . . . . . . 16 88 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 17 89 5.4. AH ICV . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 5.5. ESP ICV . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 5.6. ICMP Error Processing . . . . . . . . . . . . . . . . . . 17 92 5.7. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 18 93 5.8. Other Deployments . . . . . . . . . . . . . . . . . . . . 18 94 6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 18 95 6.1. Abstract Representation of an SRH . . . . . . . . . . . . 18 96 6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 19 97 6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 20 98 6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 20 99 6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 20 100 6.3.3. Inter SR Domain Packet - Internal to External . . . . 21 101 6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 21 102 6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 21 103 6.6. Delegation of Function with HMAC Verification . . . . . . 21 104 6.6.1. SID List Verification . . . . . . . . . . . . . . . . 21 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 106 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 23 107 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 23 108 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 23 109 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 24 110 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 111 8.1. Segment Routing Header Flags Register . . . . . . . . . . 24 112 8.2. Segment Routing Header TLVs Register . . . . . . . . . . 24 113 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 114 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 25 115 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 25 116 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 25 117 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 25 118 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 26 119 9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 26 120 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 121 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 122 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 123 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 124 12.2. Informative References . . . . . . . . . . . . . . . . . 27 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 127 1. Introduction 129 Segment Routing can be applied to the IPv6 data plane using a new 130 type of Routing Extension Header (SRH). This document describes the 131 Segment Routing Extension Header and how it is used by Segment 132 Routing capable nodes. 134 The Segment Routing Architecture [RFC8402] describes Segment Routing 135 and its instantiation in two data planes MPLS and IPv6. 137 SR with the MPLS data plane is defined in 138 [I-D.ietf-spring-segment-routing-mpls]. 140 SR with the IPv6 data plane is defined in 141 [I-D.filsfils-spring-srv6-network-programming]. 143 The encoding of MPLS labels and label stacking are defined in 144 [RFC3032]. 146 The encoding of IPv6 segments in the Segment Routing Extension Header 147 is defined in this document. 149 Terminology used within this document is defined in detail in 150 [RFC8402]. Specifically, these terms: Segment Routing, SR Domain, 151 SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy. 153 2. Segment Routing Extension Header 155 Routing Headers are defined in [RFC8200]. The Segment Routing Header 156 has a new Routing Type (suggested value 4) to be assigned by IANA. 158 The Segment Routing Header (SRH) is defined as follows: 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Last Entry | Flags | Tag | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 | Segment List[0] (128 bits IPv6 address) | 169 | | 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 | | 174 ... 175 | | 176 | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | 179 | Segment List[n] (128 bits IPv6 address) | 180 | | 181 | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 // // 184 // Optional Type Length Value objects (variable) // 185 // // 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 where: 190 o Next Header: Defined in [RFC8200] 192 o Hdr Ext Len: Defined in [RFC8200] 193 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 195 o Segments Left: Defined in [RFC8200] 197 o Last Entry: contains the index (zero based), in the Segment List, 198 of the last element of the Segment List. 200 o Flags: 8 bits of flags. Following flags are defined: 202 0 1 2 3 4 5 6 7 203 +-+-+-+-+-+-+-+-+ 204 |U U U U U U U U| 205 +-+-+-+-+-+-+-+-+ 207 U: Unused and for future use. MUST be 0 on transmission and 208 ignored on receipt. 210 o Tag: tag a packet as part of a class or group of packets, e.g., 211 packets sharing the same set of properties. When tag is not used 212 at source it MUST be set to zero on transmission. When tag is not 213 used during SRH Processing it SHOULD be ignored. The allocation 214 and use of tag is outside the scope of this document. 216 o Segment List[n]: 128 bit IPv6 addresses representing the nth 217 segment in the Segment List. The Segment List is encoded starting 218 from the last segment of the SR Policy. I.e., the first element 219 of the segment list (Segment List [0]) contains the last segment 220 of the SR Policy, the second element contains the penultimate 221 segment of the SR Policy and so on. 223 o Type Length Value (TLV) are described in Section 2.1. 225 2.1. SRH TLVs 227 This section defines TLVs of the Segment Routing Header. 229 0 1 230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 232 | Type | Length | Variable length data 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 235 Type: An 8 bit value. Unrecognized Types MUST be ignored on receipt. 237 Length: The length of the Variable length data. It is RECOMMENDED 238 that the total length of new TLVs be multiple of 8 bytes to avoid the 239 use of Padding TLVs. 241 Variable length data: Length bytes of data that is specific to the 242 Type. 244 Type Length Value (TLV) contain OPTIONAL information that may be used 245 by the node identified in the Destination Address (DA) of the packet. 247 Each TLV has its own length, format and semantic. The code-point 248 allocated (by IANA) to each TLV Type defines both the format and the 249 semantic of the information carried in the TLV. Multiple TLVs may be 250 encoded in the same SRH. 252 TLVs may change en route at each segment. To identify when a TLV 253 type may change en route the most significant bit of the Type has the 254 following significance: 256 0: TLV data does not change en route 258 1: TLV data does change en route 260 Identifying which TLVs change en route, without having to understand 261 the Type, is required for Authentication Header Integrity Check Value 262 (ICV) computation. Any TLV that changes en route is considered 263 mutable for the purpose of ICV computation, the Type Length and 264 Variable Length Data is ignored for the purpose of ICV Computation as 265 defined in [RFC4302]. 267 The "Length" field of the TLV is used to skip the TLV while 268 inspecting the SRH in case the node doesn't support or recognize the 269 Type. The "Length" defines the TLV length in octets, not including 270 the "Type" and "Length" fields. 272 The following TLVs are defined in this document: 274 Padding TLV 276 HMAC TLV 278 Additional TLVs may be defined in the future. 280 2.1.1. Padding TLVs 282 There are two types of padding TLVs, pad0 and padN, the following 283 applies to both: 285 Padding TLVs are used to pad the TLVs to a multiple of 8 octets. 287 More than one Padding TLV MUST NOT appear in the SRH. 289 The Padding TLVs are used to align the SRH total length on the 8 290 octet boundary. 292 When present, a single Pad0 or PadN TLV MUST appear as the last 293 TLV. 295 When present, a PadN TLV MUST have a length from 0 to 5 in order 296 to align the SRH total length on a 8-octet boundary. 298 Padding TLVs are ignored by a node processing the SRH TLV, even if 299 more than one is present. 301 Padding TLVs are ignored during ICV calculation. 303 2.1.1.1. PAD0 305 0 1 2 3 4 5 6 7 306 +-+-+-+-+-+-+-+-+ 307 | Type | 308 +-+-+-+-+-+-+-+-+ 310 Type: to be assigned by IANA (Suggested value 128) 312 A single Pad0 TLV MUST be used when a single byte of padding is 313 required. If more than one byte of padding is required a Pad0 TLV 314 MUST NOT be used, the PadN TLV MUST be used. 316 2.1.1.2. PADN 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type | Length | Padding (variable) | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 // Padding (variable) // 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Type: to be assigned by IANA (suggested value 129). 328 Length: 0 to 5 330 Padding: Length octets of padding. Padding bits have no 331 semantics. They MUST be set to 0 on transmission and ignored on 332 receipt. 334 The PadN TLV MUST be used when more than one byte of padding is 335 required. 337 2.1.2. HMAC TLV 339 The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL 340 and has the following format: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type | Length | RESERVED | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | HMAC Key ID (4 octets) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | // 350 | HMAC (32 octets) // 351 | // 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 where: 356 o Type: to be assigned by IANA (suggested value 5). 358 o Length: 38. 360 o RESERVED: 2 octets. MUST be 0 on transmission and ignored on 361 receipt. 363 o HMAC Key ID: A 4 octet opaque number which uniquely identifies the 364 pre-shared key and algorithm used to generate the HMAC. If 0, the 365 HMAC is not included. 367 o HMAC: 32 octets of keyed HMAC, not present if Key ID is 0. 369 The HMAC TLV is used to verify the source of a packet is permitted to 370 use the current segment in the destination address of the packet, and 371 ensure the segment list is not modified in transit. 373 2.1.2.1. HMAC Generation and Verification 375 Local policy determines when to check for an HMAC and potentially 376 provides an alternate composition of Text, and a requirement on where 377 the HMAC TLV must appear (e.g. first TLV). This local policy is 378 outside the scope of this document. It may be based on the active 379 segment at an SR Segment endpoint node, the result of an ACL that 380 considers incoming interface, HMAC Key ID, or other packet fields. 382 The HMAC field is the output of the HMAC computation as defined in 383 [RFC2104], using: 385 o key: the pre-shared key identified by HMAC Key ID 387 o HMAC algorithm: identified by the HMAC Key ID 389 o Text: a concatenation of the following fields from the IPv6 header 390 and the SRH, as it would be received at the node verifying the 391 HMAC: 393 * IPv6 header: source address (16 octets) 395 * SRH: Last Entry (1 octet) 397 * SRH: Flags (1 octet) 399 * SRH: HMAC Key-id (4 octets) 401 * SRH: all addresses in the Segment List (variable octets) 403 The HMAC digest is truncated to 32 octets and placed in the HMAC 404 field of the HMAC TLV. 406 For HMAC algorithms producing digests less than 32 octets, the digest 407 is placed in the lowest order octets of the HMAC field. Remaining 408 octets MUST be set to zero. 410 If HMAC verification is successful, the packet is forwarded to the 411 next segment. 413 If HMAC verification fails, an ICMP error message (parameter problem, 414 error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate 415 limited) and SHOULD be logged. 417 2.1.2.2. HMAC Pre-Shared Key Algorithm 419 The HMAC Key ID field allows for the simultaneous existence of 420 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 421 well as pre-shared keys. 423 The HMAC Key ID field is opaque, i.e., it has neither syntax nor 424 semantic except as an identifier of the right combination of pre- 425 shared key and hash algorithm, and except that a value of 0 means 426 that there is no HMAC field. 428 At the HMAC TLV verification node the Key ID uniquely identifies the 429 pre-shared key and HMAC algorithm. 431 At the HMAC TLV generating node the Key ID and destination address 432 uniquely identify the pre-shared key and HMAC algorithm. Utilizing 433 the destination address with the Key ID allows for overlapping key 434 IDs amongst different HMAC verification nodes. The Text for the HMAC 435 computation is set to the IPv6 header fields and SRH fields as they 436 would appear at the verification node, not necessarily the same as 437 the source node sending a packet with the HMAC TLV. 439 Pre-shared key roll-over is supported by having two key IDs in use 440 while the HMAC TLV generating node and verifying node converge to a 441 new key. 443 SRH implementations can support multiple hash functions but MUST 444 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 446 The selection of pre-shared key and algorithm, and their distribution 447 is outside the scope of this document, some options may include: 449 o in the configuration of the HMAC generating or verifying nodes, 450 either by static configuration or any SDN oriented approach 452 o dynamically using a trusted key distribution protocol such as 453 [RFC6407] 455 3. SR Nodes 457 There are different types of nodes that may be involved in segment 458 routing networks: source SR nodes originate packets with a segment in 459 the destination address of the IPv6 header, transit nodes that 460 forward packets destined to a remote segment, and SR segment endpoint 461 nodes that process a local segment in the destination address of an 462 IPv6 header. 464 3.1. Source SR Node 466 A Source SR Node is any node that originates an IPv6 packet with a 467 segment (i.e. SRv6 SID) in the destination address of the IPv6 468 header. The packet leaving the source SR Node may or may not contain 469 an SRH. This includes either: 471 A host originating an IPv6 packet. 473 An SR domain ingress router encapsulating a received packet in an 474 outer IPv6 header, followed by an optional SRH. 476 The mechanism through which a segment in the destination address of 477 the IPv6 header and the Segment List in the SRH, is derived is 478 outside the scope of this document. 480 3.2. Transit Node 482 A transit node is any node forwarding an IPv6 packet where the 483 destination address of that packet is not locally configured as a 484 segment nor a local interface. A transit node is not required to be 485 capable of processing a segment nor SRH. 487 3.3. SR Segment Endpoint Node 489 A SR segment endpoint node is any node receiving an IPv6 packet where 490 the destination address of that packet is locally configured as a 491 segment or local interface. 493 4. Packet Processing 495 This section describes SRv6 packet processing at the SR source, 496 Transit and SR segment endpoint nodes. 498 4.1. Source SR Node 500 A Source node steers a packet into an SR Policy. If the SR Policy 501 results in a segment list containing a single segment, and there is 502 no need to add information to SRH flag or TLV, the DA is set to the 503 single segment list entry and the SRH MAY be omitted. 505 When needed, the SRH is created as follows: 507 Next Header and Hdr Ext Len fields are set as specified in 508 [RFC8200]. 510 Routing Type field is set as TBD (to be allocated by IANA, 511 suggested value 4). 513 The DA of the packet is set with the value of the first segment. 515 The first element of the SRH Segment List is the ultimate segment. 516 The second element is the penultimate segment and so on. 518 The Segments Left field is set to n-1 where n is the number of 519 elements in the SR Policy. 521 The Last Entry field is set to n-1 where n is the number of 522 elements in the SR Policy. 524 HMAC TLV may be set according to Section 7. 526 The packet is forwarded toward the packet's Destination Address 527 (the first segment). 529 4.1.1. Reduced SRH 531 When a source does not require the entire SID list to be preserved in 532 the SRH, a reduced SRH may be used. 534 A reduced SRH does not contain the first segment of the related SR 535 Policy (the first segment is the one already in the DA of the IPv6 536 header), and the Last Entry field is set to n-2 where n is the number 537 of elements in the SR Policy. 539 4.2. Transit Node 541 As specified in [RFC8200], the only node allowed to inspect the 542 Routing Extension Header (and therefore the SRH), is the node 543 corresponding to the DA of the packet. Any other transit node MUST 544 NOT inspect the underneath routing header and MUST forward the packet 545 toward the DA according to its IPv6 routing table. 547 When a SID is in the destination address of an IPv6 header of a 548 packet, it's routed through an IPv6 network as an IPv6 address. 549 SIDs, or the prefix(es) covering SIDs, and their reachability may be 550 distributed by means outside the scope of this document. For 551 example, [RFC5308] or [RFC5340] may be used to advertise a prefix 552 covering the SIDs on a node. 554 4.3. SR Segment Endpoint Node 556 Without constraining the details of an implementation, the SR segment 557 endpoint node creates Forwarding Information Base (FIB) entries for 558 its local SIDs. 560 When an SRv6-capable node receives an IPv6 packet, it performs a 561 longest-prefix-match lookup on the packets destination address. This 562 lookup can return any of the following: 564 A FIB entry that represents a locally instantiated SRv6 SID 565 A FIB entry that represents a local interface, not locally 566 instantiated as an SRv6 SID 567 A FIB entry that represents a non-local route 568 No Match 570 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID 572 This document, and section, defines a single SRv6 SID called END. 573 Future documents may define additional SRv6 SIDs. In which case, the 574 entire content of this section will be defined in that document. 576 If the FIB entry represents a locally instantiated SRv6 SID, process 577 the next header of the IPv6 header as defined in section 4 of 578 [RFC8200] 580 The following sections describe the actions to take while processing 581 next header fields. 583 4.3.1.1. SRH Processing 585 S01. When an SRH is processed { 586 S02. If Segments Left is equal to zero { 587 S03. Proceed to process the next header in the packet, 588 whose type is identified by the Next Header field in 589 the Routing header. 590 S04. } 591 S05. Else { 592 S06. If local policy requires TLV processing { 593 S07. Perform TLV processing (see TLV Processing) 594 S08. } 595 S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1 596 S10. If ((Last Entry > max_last_entry) or 597 S11. (Segments Left is greater than (Last Entry+1)) { 598 S12. Send an ICMP Parameter Problem, Code 0, message to 599 the Source Address, pointing to the Segments Left 600 field, and discard the packet. 601 S13. } 602 S14. Else { 603 S15. Decrement Segments Left by 1. 604 S16. Copy Segment List[Segments Left] from the SRH to the 605 destination address of the IPv6 header. 606 S17. If the IPv6 Hop Limit is less than or equal to 1 { 607 S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in 608 Transit message to the Source Address and discard 609 the packet. 610 S19. } 611 S20. Else { 612 S21. Decrement the Hop Limit by 1 613 S22. Resubmit the packet to the IPv6 module for transmission 614 to the new destination. 615 S23. } 616 S24. } 617 S25. } 618 S26. } 620 4.3.1.1.1. TLV Processing 622 Local policy determines how TLV's are to be processed when the Active 623 Segment is a local END SID. The definition of local policy is 624 outside the scope of this document. 626 For illustration purpose only, two example local policies that may be 627 associated with an END SID are provided below. 629 Example 1: 630 For any packet received from interface I2 631 Skip TLV processing 633 Example 2: 634 For any packet received from interface I1 635 If first TLV is HMAC { 636 Process the HMAC TLV 637 } 638 Else { 639 Discard the packet 640 } 642 4.3.1.2. Upper-layer Header or No Next Header 644 When processing the Upper-layer header of a packet matching a FIB 645 entry locally instantiated as an SRv6 END SID. 647 IF (Upper-layer Header is IPv4 or IPv6) and local policy permits { 648 Perform IPv6 decapsulation 649 Resubmit the decapsulated packet to the IPv4 or IPv6 module 650 } 651 ELSE { 652 Send an ICMP parameter problem message to the Source Address and 653 discard the packet. Error code (TBD by IANA) "SR Upper-layer 654 Header Error", pointer set to the offset of the upper-layer 655 header. 656 } 658 A unique error code allows an SR Source node to recognize an error in 659 SID processing at an endpoint. 661 4.3.2. FIB Entry is a Local Interface 663 If the FIB entry represents a local interface, not locally 664 instantiated as an SRv6 SID, the SRH is processed as follows: 666 If Segments Left is zero, the node must ignore the Routing header 667 and proceed to process the next header in the packet, whose type 668 is identified by the Next Header field in the Routing Header. 670 If Segments Left is non-zero, the node must discard the packet and 671 send an ICMP Parameter Problem, Code 0, message to the packet's 672 Source Address, pointing to the unrecognized Routing Type. 674 4.3.3. FIB Entry Is A Non-Local Route 676 Processing is not changed by this document. 678 4.3.4. FIB Entry Is A No Match 680 Processing is not changed by this document. 682 5. Intra SR Domain Deployment Model 684 The use of the SIDs exclusively within the SR Domain and solely for 685 packets of the SR Domain is an important deployment model. 687 This enables the SR Domain to act as a single routing system. 689 This section covers: 691 o securing the SR Domain from external attempt to use its SIDs 693 o SR Domain as a single system with delegation between components 695 o handling packets of the SR Domain 697 5.1. Securing the SR Domain 699 Nodes outside the SR Domain are not trusted: they cannot directly use 700 the SID's of the domain. This is enforced by two levels of access 701 control lists: 703 1. Any packet entering the SR Domain and destined to a SID within 704 the SR Domain is dropped. This may be realized with the 705 following logic, other methods with equivalent outcome are 706 considered compliant: 708 * allocate all the SID's from a block S/s 710 * configure each external interface of each edge node of the 711 domain with an inbound infrastructure access list (IACL) which 712 drops any incoming packet with a destination address in S/s 714 * Failure to implement this method of ingress filtering exposes 715 the SR Domain to source routing attacks as described and 716 referenced in [RFC5095] 718 2. The distributed protection in #1 is complemented with per node 719 protection, dropping packets to SIDs from source addresses 720 outside the SR Domain. This may be realized with the following 721 logic, other methods with equivalent outcome are considered 722 compliant: 724 * assign all interface addresses from prefix A/a 726 * at node k, all SIDs local to k are assigned from prefix Sk/sk 728 * configure each internal interface of each SR node k in the SR 729 Domain with an inbound IACL which drops any incoming packet 730 with a destination address in Sk/sk if the source address is 731 not in A/a. 733 5.2. SR Domain as a single system with delegation among components 735 All intra SR Domain packets are of the SR Domain. The IP v6 header 736 is originated by a node of the SR Domain, and is destined to a node 737 of the SR Domain. 739 All inter domain packets are encapsulated for the part of the packet 740 journey that is within the SR Domain. The outer IPv6 header is 741 originated by a node of the SR Domain, and is destined to a node of 742 the SR Domain. 744 As a consequence, any packet within the SR Domain is of the SR 745 Domain. 747 The SR Domain is a system in which the operator may want to 748 distribute or delegate different operations of the outer most header 749 to different nodes within the system. 751 An operator of an SR domain may choose to delegate SRH addition to a 752 host node within the SR domain, and validation of the contents of any 753 SRH to a more trusted router or switch attached to the host. 754 Consider a top of rack switch (T) connected to host (H) via interface 755 (I). H receives an SRH (SRH1) with a computed HMAC via some SDN 756 method outside the scope of this document. H classifies traffic it 757 sources and adds SRH1 to traffic requiring a specific SLA. T is 758 configured with an IACL on I requiring verification of the SRH for 759 any packet destined to the SID block of the SR Domain (S/s). T 760 checks and verifies that SRH1 is valid, contains an HMAC TLV and 761 verifies the HMAC. 763 5.3. MTU Considerations 765 Within the SR Domain, well known mitigation techniques are 766 RECOMMENDED, such as deploying a greater MTU value within the SR 767 Domain than at the ingress edges. 769 5.4. AH ICV 771 Within the domain, an SR source node which includes SRH and AH 772 extension headers can predict the content of the SRH and calculate 773 the ICV at the SR source node, ensuring it can be confirmed at the 774 destination. 776 5.5. ESP ICV 778 Within the domain, an SR source node may include SRH and ESP 779 extension headers. Only the data following the ESP header is 780 included in ICV computation. SRH precedes ESP. 782 5.6. ICMP Error Processing 784 ICMP error packets generated within the SR Domain are sent to source 785 nodes within the SR Domain. The invoking packet in the ICMP error 786 message may contain an SRH. Since the destination address of a 787 packet with an SRH changes as each segment is processed, it may not 788 be the destination used by the socket or application that generated 789 the invoking packet. 791 For the source of an invoking packet to process the ICMP error 792 message, the correct destination address must be determined. The 793 following logic is used to determine the destination address for use 794 by protocol error handlers. 796 o Walk all extension headers of the invoking IPv6 packet to the 797 routing extension header preceding the upper layer header. 799 * If routing header is type 4 (SRH) 801 + Use the 0th segment in the segment list as the destination 802 address of the invoking packet. 804 ICMP errors are then processed by upper layer transports as defined 805 in [RFC4443]. 807 For IP packets encapsulated in an outer IPv6 header, ICMP error 808 handling is as defined in [RFC2473]. 810 5.7. Load Balancing and ECMP 812 For any inter domain packet, the SR Source node MUST impose a flow 813 label computed based on the inner packet. The computation of the 814 flow label is as recommended in [RFC6438] for the sending Tunnel End 815 Point. 817 At any transit node within an SR domain, the flow label MUST be used 818 as defined in [RFC6438] to calculate the ECMP hash toward the 819 destination address. If flow label is not used, the transit node may 820 hash all packets between a pair of SR Edge nodes to the same link. 822 At an SR segment endpoint node, the flow label MUST be used as 823 defined in [RFC6438] to calculate any ECMP hash used to forward the 824 processed packet to the next segment. 826 5.8. Other Deployments 828 Other deployment models and their implications on security, MTU, 829 HMAC, ICMP error processing and interaction with other extension 830 headers are outside the scope of this document. 832 6. Illustrations 834 This section provides illustrations of SRv6 packet processing at SR 835 source, transit and SR segment endpoint nodes. 837 6.1. Abstract Representation of an SRH 839 For a node k, its IPv6 address is represented as Ak, its SRv6 SID is 840 represented as Sk. 842 IPv6 headers are represented as the tuple of (source, destination). 843 For example, a packet with source address A1 and destination address 844 A2 is represented as (A1,A2). The payload of the packet is omitted. 846 An SR Policy is a list of segments. A list of segments is 847 represented as where S1 is the first SID to visit, S2 is 848 the second SID to visit and S3 is the last SID to visit. 850 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 852 o Source Address is SA, Destination Addresses is DA, and next-header 853 is SRH. 855 o SRH with SID list with SegmentsLeft = SL. 857 o Note the difference between the <> and () symbols. 858 represents a SID list where the leftmost segment is the first 859 segment. Whereas, (S3, S2, S1; SL) represents the same SID list 860 but encoded in the SRH Segment List format where the leftmost 861 segment is the last segment. When referring to an SR policy in a 862 high-level use-case, it is simpler to use the 863 notation. When referring to an illustration of detailed behavior, 864 the (S3, S2, S1; SL) notation is more convenient. 866 At its SR Policy headend, the Segment List results in SRH 867 (S3,S2,S1; SL=2) represented fully as: 869 Segments Left=2 870 Last Entry=2 871 Flags=0 872 Tag=0 873 Segment List[0]=S3 874 Segment List[1]=S2 875 Segment List[2]=S1 877 6.2. Example Topology 879 The following topology is used in examples below: 881 + * * * * * * * * * * * * * * * * * * * * + 883 * [8] [9] * 884 | | 885 * | | * 886 [1]----[3]--------[5]----------------[6]---------[4]---[2] 887 * | | * 888 | | 889 * | | * 890 +--------[7]-------+ 891 * * 893 + * * * * * * * SR Domain * * * * * * * + 895 Figure 3 897 o 3 and 4 are SR Domain edge routers 899 o 5, 6, and 7 are all SR Domain routers 901 o 8 and 9 are hosts within the SR Domain 903 o 1 and 2 are hosts outside the SR Domain 904 o The SR domain is secured as per Section 5.1 and no external packet 905 can enter the domain with a destination address equal to a segment 906 of the domain. 908 6.3. Source SR Node 910 6.3.1. Intra SR Domain Packet 912 When host 8 sends a packet to host 9 via an SR Policy the 913 packet is 915 P1: (A8,S7)(A9,S7; SL=1) 917 6.3.1.1. Reduced Variant 919 When host 8 sends a packet to host 9 via an SR Policy and it 920 wants to use a reduced SRH, the packet is 922 P2: (A8,S7)(A9; SL=1) 924 6.3.2. Inter SR Domain Packet - Transit 926 When host 1 sends a packet to host 2, the packet is 928 P3: (A1,A2) 930 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 931 egress router 4 via an SR Policy . Router 3 encapsulates the 932 received packet P3 in an outer header with an SRH. The packet is 934 P4: (A3, S7)(S4, S7; SL=1)(A1, A2) 936 If the SR Policy contains only one segment (the egress router 4), the 937 ingress Router 3 encapsulates P3 into an outer header (A3, S4). The 938 packet is 940 P5: (A3, S4)(A1, A2) 942 6.3.2.1. Reduced Variant 944 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 945 egress router 4 via an SR Policy . If router 3 wants to use 946 a reduced SRH, Router 3 encapsulates the received packet P3 in an 947 outer header with a reduced SRH. The packet is 949 P6: (A3, S7)(S4; SL=1)(A1, A2) 951 6.3.3. Inter SR Domain Packet - Internal to External 953 When host 8 sends a packet to host 1, the packet is encapsulated for 954 the portion of its journey within the SR Domain. From 8 to 3 the 955 packet is 957 P7: (A8,S3)(A8,A1) 959 In the opposite direction, the packet generated from 1 to 8 is 961 P8: (A1,A8) 963 At node 3 P8 is encapsulated for the portion of its journey within 964 the SR domain. Resulting in 966 P9: (A3,S8)(A1,A8) 968 At node 9 the outer IPv6 header is removed by S6 processing then 969 processed again when received by A8. 971 6.4. Transit Node 973 Nodes 5 acts as transit nodes for packet P1, and sends packet 975 P1: (A8,S7)(A9,S7;SL=1) 977 on the interface toward node 7. 979 6.5. SR Segment Endpoint Node 981 Node 7 receives packet P1 and, using the logic in Section 4.3.1, 982 sends packet 984 P7: (A8,A9)(A9,S7; SL=0) 986 on the interface toward router 6. 988 6.6. Delegation of Function with HMAC Verification 990 This section describes how a function may be delegated within the SR 991 Domain to non SR source nodes. In the following sections consider a 992 host 8 connected to a top of rack 5. 994 6.6.1. SID List Verification 996 An operator may prefer to add the SRH at source 8, while 5 verifies 997 the SID list is valid. 999 For illustration purpose, an SDN controller provides 8 an SRH 1000 terminating at node 9, with segment list , and HMAC TLV 1001 computed for the SRH. The HMAC key is shared with 5, node 8 does not 1002 know the key. Node 5 is configured with an IACL applied to the 1003 interface connected to 8, requiring HMAC verification for any packet 1004 destined to S/s. 1006 Node 8 originates packets with the received SRH with HMAC TLV. 1008 P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC) 1010 Node 5 receives and verifies the HMAC for the SRH, then forwards the 1011 packet to the next segment 1013 P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC) 1015 Node 6 receives 1017 P17:(A8,S6)(A9,S6,S7,S5;SL=1;HMAC) 1019 Node 9 receives 1021 P18:(A8,A9)(A9,S6,S7,S5;SL=0;HMAC) 1023 This use of an HMAC is particularly valuable within an enterprise 1024 based SR Domain [SRN]. 1026 7. Security Considerations 1028 This section reviews security considerations related to the SRH, 1029 given the SRH processing and deployment models discussed in this 1030 document. 1032 As describe in Section 5, it is necessary to filter packets ingress 1033 to the SR Domain destined to segments within the SR Domain. This 1034 ingress filtering is via an IACL at SR Domain ingress border nodes. 1035 Additional protection is applied via an IACL at each SR Segment 1036 Endpoint node, filtering packets not from within the SR Domain, 1037 destined to SIDs in the SR Domain. ACLs are easily supported for 1038 small numbers of prefixes, making summarization important, and when 1039 the prefixes requiring filtering is kept to a seldom changing set. 1041 Additionally, ingress filtering of IPv6 source addresses as 1042 recommended in BCP38 SHOULD be used. 1044 7.1. Source Routing Attacks 1046 [RFC5095] deprecates the Type 0 Routing header due to a number of 1047 significant attacks that are referenced in that document. Such 1048 attacks include bypassing filtering devices, reaching otherwise 1049 unreachable Internet systems, network topology discovery, bandwidth 1050 exhaustion, and defeating anycast. 1052 Because this document specifies that the SRH is for use within an SR 1053 domain protected by ingress filtering via IACLs; such attacks cannot 1054 be mounted from outside an SR Domain. As specified in this document, 1055 SR Domain ingress edge nodes drop packets entering the SR Domain 1056 destined to segments within the SR Domain. 1058 Additionally, this document specifies the use of IACL on SR Segment 1059 Endpoint nodes within the SR Domain to limit the source addresses 1060 permitted to send packets to a SID in the SR Domain. 1062 Such attacks may, however, be mounted from within the SR Domain, from 1063 nodes permitted to source traffic to SIDs in the domain. As such, 1064 these attacks and other known attacks on an IP network (e.g. DOS/ 1065 DDOS, topology discovery, man-in-the-middle, traffic interception/ 1066 siphoning), can occur from compromised nodes within an SR Domain. 1068 7.2. Service Theft 1070 Service theft is defined as the use of a service offered by the SR 1071 Domain by a node not authorized to use the service. 1073 Service theft is not a concern within the SR Domain as all SR Source 1074 nodes and SR segment endpoint nodes within the domain are able to 1075 utilize the services of the Domain. If a node outside the SR Domain 1076 learns of segments or a topological service within the SR domain, 1077 IACL filtering denies access to those segments. 1079 7.3. Topology Disclosure 1081 The SRH may contains SIDs of some intermediate SR-nodes in the path 1082 towards the destination, this reveals those addresses to attackers if 1083 they are able to intercept packets containing SRH. 1085 This is applicable within an SR Domain but the disclosure is less 1086 relevant as an attacker has other means of learning topology. 1088 7.4. ICMP Generation 1090 The generation of ICMPv6 error messages may be used to attempt 1091 denial-of-service attacks by sending an error-causing destination 1092 address or SRH in back-to-back packets. An implementation that 1093 correctly follows Section 2.4 of [RFC4443] would be protected by the 1094 ICMPv6 rate-limiting mechanism. 1096 8. IANA Considerations 1098 This document makes the following registrations in the Internet 1099 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1100 maintained by IANA: 1102 Suggested Description Reference 1103 Value 1104 ---------------------------------------------------------- 1105 4 Segment Routing Header (SRH) This document 1107 This document request IANA to create and maintain a new Registry: 1108 "Segment Routing Header TLVs" 1110 8.1. Segment Routing Header Flags Register 1112 This document requests the creation of a new IANA managed registry to 1113 identify SRH Flags Bits. The registration procedure is "Expert 1114 Review" as defined in [RFC8126]. Suggested registry name is "Segment 1115 Routing Header Flags". Flags is 8 bits, the following bits are 1116 defined in this document: 1118 Suggested Description Reference 1119 Bit 1120 ----------------------------------------------------- 1121 4 HMAC This document 1123 8.2. Segment Routing Header TLVs Register 1125 This document requests the creation of a new IANA managed registry to 1126 identify SRH TLVs. The registration procedure is "Expert Review" as 1127 defined in [RFC8126]. Suggested registry name is "Segment Routing 1128 Header TLVs". A TLV is identified through an unsigned 8 bit 1129 codepoint value. The following codepoints are defined in this 1130 document: 1132 Suggested Description Reference 1133 Value 1134 ----------------------------------------------------- 1135 5 HMAC TLV This document 1136 128 Pad0 TLV This document 1137 129 PadN TLV This document 1139 9. Implementation Status 1141 This section is to be removed prior to publishing as an RFC. 1143 9.1. Linux 1145 Name: Linux Kernel v4.14 1147 Status: Production 1149 Implementation: adds SRH, performs END processing, supports HMAC TLV 1151 Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and 1152 [I-D.filsfils-spring-srv6-interop] 1154 9.2. Cisco Systems 1156 Name: IOS XR and IOS XE 1158 Status: Pre-production 1160 Implementation: adds SRH, performs END processing, no TLV processing 1162 Details: [I-D.filsfils-spring-srv6-interop] 1164 9.3. FD.io 1166 Name: VPP/Segment Routing for IPv6 1168 Status: Production 1170 Implementation: adds SRH, performs END processing, no TLV processing 1172 Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and 1173 [I-D.filsfils-spring-srv6-interop] 1175 9.4. Barefoot 1177 Name: Barefoot Networks Tofino NPU 1179 Status: Prototype 1180 Implementation: performs END processing, no TLV processing 1182 Details: [I-D.filsfils-spring-srv6-interop] 1184 9.5. Juniper 1186 Name: Juniper Networks Trio and vTrio NPU's 1188 Status: Prototype & Experimental 1190 Implementation: SRH insertion mode, Process SID where SID is an 1191 interface address, no TLV processing 1193 9.6. Huawei 1195 Name: Huawei Systems VRP Platform 1197 Status: Production 1199 Implementation: adds SRH, performs END processing, no TLV processing 1201 10. Contributors 1203 Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung, 1204 Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, 1205 Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre 1206 Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta 1207 Maglione, James Connolly, Aloys Augustin contributed to the content 1208 of this document. 1210 11. Acknowledgements 1212 The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, 1213 Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, 1214 and David Lebrun for their comments to this document. 1216 12. References 1218 12.1. Normative References 1220 [FIPS180-4] 1221 National Institute of Standards and Technology, "FIPS 1222 180-4 Secure Hash Standard (SHS)", March 2012, 1223 . 1226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1227 Requirement Levels", BCP 14, RFC 2119, 1228 DOI 10.17487/RFC2119, March 1997, 1229 . 1231 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1232 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1233 December 1998, . 1235 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1236 of Type 0 Routing Headers in IPv6", RFC 5095, 1237 DOI 10.17487/RFC5095, December 2007, 1238 . 1240 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1241 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1242 October 2011, . 1244 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1245 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1246 May 2017, . 1248 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1249 (IPv6) Specification", STD 86, RFC 8200, 1250 DOI 10.17487/RFC8200, July 2017, 1251 . 1253 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1254 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1255 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1256 July 2018, . 1258 12.2. Informative References 1260 [I-D.filsfils-spring-srv6-interop] 1261 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 1262 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 1263 "SRv6 interoperability report", draft-filsfils-spring- 1264 srv6-interop-01 (work in progress), September 2018. 1266 [I-D.filsfils-spring-srv6-network-programming] 1267 Filsfils, C., Camarillo, P., Leddy, J., 1268 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1269 Network Programming", draft-filsfils-spring-srv6-network- 1270 programming-06 (work in progress), October 2018. 1272 [I-D.ietf-spring-segment-routing-mpls] 1273 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1274 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1275 data plane", draft-ietf-spring-segment-routing-mpls-18 1276 (work in progress), December 2018. 1278 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1279 Hashing for Message Authentication", RFC 2104, 1280 DOI 10.17487/RFC2104, February 1997, 1281 . 1283 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1284 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1285 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1286 . 1288 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1289 DOI 10.17487/RFC4302, December 2005, 1290 . 1292 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1293 Control Message Protocol (ICMPv6) for the Internet 1294 Protocol Version 6 (IPv6) Specification", STD 89, 1295 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1296 . 1298 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1299 DOI 10.17487/RFC5308, October 2008, 1300 . 1302 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1303 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1304 . 1306 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1307 for Equal Cost Multipath Routing and Link Aggregation in 1308 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1309 . 1311 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1312 Writing an IANA Considerations Section in RFCs", BCP 26, 1313 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1314 . 1316 [SRN] and , "Software Resolved Networks: Rethinking Enterprise 1317 Networks with IPv6 Segment Routing", 2018, 1318 . 1321 Authors' Addresses 1323 Clarence Filsfils (editor) 1324 Cisco Systems, Inc. 1325 Brussels 1326 BE 1328 Email: cfilsfil@cisco.com 1330 Stefano Previdi 1331 Huawei 1332 Italy 1334 Email: stefano@previdi.net 1336 John Leddy 1337 Individual 1338 US 1340 Email: john@leddy.net 1342 Satoru Matsushima 1343 Softbank 1345 Email: satoru.matsushima@g.softbank.co.jp 1347 Daniel Voyer (editor) 1348 Bell Canada 1350 Email: daniel.voyer@bell.ca