idnits 2.17.1 draft-ietf-6man-segment-routing-header-14.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 (June 28, 2018) is 2100 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 658 -- Looks like a reference, but probably isn't: '9' on line 658 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == Outdated reference: A later version (-02) exists of draft-filsfils-spring-srv6-interop-00 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-04 == 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: December 30, 2018 Individual 6 J. Leddy 7 Comcast 8 S. Matsushima 9 Softbank 10 D. Voyer, Ed. 11 Bell Canada 12 June 28, 2018 14 IPv6 Segment Routing Header (SRH) 15 draft-ietf-6man-segment-routing-header-14 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 December 30, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . 8 71 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 9 73 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 9 74 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 9 75 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 9 77 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 10 78 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 10 79 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11 80 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 11 81 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 13 82 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 13 83 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 13 84 4.3.5. Load Balancing and ECMP . . . . . . . . . . . . . . . 13 85 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 14 86 5.1. Abstract Representation of an SRH . . . . . . . . . . . . 14 87 5.2. Example Topology . . . . . . . . . . . . . . . . . . . . 15 88 5.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 15 89 5.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 15 90 5.3.2. Transit Packet Through SR Domain . . . . . . . . . . 16 91 5.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 16 92 5.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 16 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 94 6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17 95 6.1.1. Source routing threats . . . . . . . . . . . . . . . 17 96 6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 18 97 6.1.3. Service stealing threat . . . . . . . . . . . . . . . 19 98 6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 19 99 6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 19 100 6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 19 101 6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 21 102 6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 21 103 6.2.3. Pre-shared key management . . . . . . . . . . . . . . 22 104 6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 22 105 6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 22 106 6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 22 107 6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 23 108 6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 23 109 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 110 7.1. Segment Routing Header Flags Register . . . . . . . . . . 24 111 7.2. Segment Routing Header TLVs Register . . . . . . . . . . 24 112 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 113 8.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 25 114 8.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 25 115 8.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 25 116 8.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 25 117 8.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 26 118 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 119 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 120 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 121 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 122 11.2. Informative References . . . . . . . . . . . . . . . . . 27 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 125 1. Introduction 127 Segment Routing can be applied to the IPv6 data plane using a new 128 type of Routing Extension Header (SRH). This document describes the 129 Segment Routing Extension Header and how it is used by Segment 130 Routing capable nodes. 132 The Segment Routing Architecture [I-D.ietf-spring-segment-routing] 133 describes Segment Routing and its instantiation in two data planes 134 MPLS and IPv6. 136 SR with the MPLS data plane is defined in 137 [I-D.ietf-spring-segment-routing-mpls]. 139 SR with the IPv6 data plane is defined in 140 [I-D.filsfils-spring-srv6-network-programming]. 142 The encoding of MPLS labels and label stacking are defined in 143 [RFC3032]. 145 The encoding of IPv6 segments in the Segment Routing Extension Header 146 is defined in this document. 148 Terminology used within this document is defined in detail in 149 [I-D.ietf-spring-segment-routing]. Specifically, these terms: 150 Segment Routing, SR Domain, SRv6, Segment ID (SID), SRv6 SID, Active 151 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] 191 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 HMAC TLV is OPTIONAL and contains the HMAC information. The HMAC TLV 340 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: 4 octets. 365 o HMAC: 32 octets. 367 o HMAC and HMAC Key ID usage is described in Section 6 369 The Following applies to the HMAC TLV: 371 o Local policy determines when to check for an HMAC and potentially 372 a requirement on where the HMAC TLV must appear (e.g. first TLV). 373 This local policy is outside the scope of this document. It may 374 be based on the active segment at an SR Segment endpoint node, the 375 result of an ACL that considers incoming interface, or other 376 packet fields. 378 3. SR Nodes 380 There are different types of nodes that may be involved in segment 381 routing networks: source SR nodes originate packets with a segment in 382 the destination address of the IPv6 header, transit nodes that 383 forward packets destined to a remote segment, and SR segment endpoint 384 nodes that process a local segment in the destination address of an 385 IPv6 header. 387 3.1. Source SR Node 389 A Source SR Node is any node that originates an IPv6 packet with a 390 segment (i.e. SRv6 SID) in the destination address of the IPv6 391 header. The packet leaving the source SR Node may or may not contain 392 an SRH. This includes either: 394 A host originating an IPv6 packet. 396 An SR domain ingress router encapsulating a received packet in an 397 outer IPv6 header, followed by an optional SRH. 399 The mechanism through which a segment in the destination address of 400 the IPv6 header and the Segment List in the SRH, is derived is 401 outside the scope of this document. 403 3.2. Transit Node 405 A transit node is any node forwarding an IPv6 packet where the 406 destination address of that packet is not locally configured as a 407 segment nor a local interface. A transit node is not required to be 408 capable of processing a segment nor SRH. 410 3.3. SR Segment Endpoint Node 412 A SR segment endpoint node is any node receiving an IPv6 packet where 413 the destination address of that packet is locally configured as a 414 segment or local interface. 416 4. Packet Processing 418 This section describes SRv6 packet processing at the SR source, 419 Transit and SR segment endpoint nodes. 421 4.1. Source SR Node 423 A Source node steers a packet into an SR Policy. If the SR Policy 424 results in a segment list containing a single segment, and there is 425 no need to add information to SRH flag or TLV, the DA is set to the 426 single segment list entry and the SRH MAY be omitted. 428 When needed, the SRH is created as follows: 430 Next Header and Hdr Ext Len fields are set as specified in 431 [RFC8200]. 433 Routing Type field is set as TBD (to be allocated by IANA, 434 suggested value 4). 436 The DA of the packet is set with the value of the first segment. 438 The first element of the SRH Segment List is the ultimate segment. 439 The second element is the penultimate segment and so on. 441 The Segments Left field is set to n-1 where n is the number of 442 elements in the SR Policy. 444 The Last Entry field is set to n-1 where n is the number of 445 elements in the SR Policy. 447 HMAC TLV may be set according to Section 6. 449 The packet is forwarded toward the packet's Destination Address 450 (the first segment). 452 4.1.1. Reduced SRH 454 When a source does not require the entire SID list to be preserved in 455 the SRH, a reduced SRH may be used. 457 A reduced SRH does not contain the first segment of the related SR 458 Policy (the first segment is the one already in the DA of the IPv6 459 header), and the Last Entry field is set to n-2 where n is the number 460 of elements in the SR Policy. 462 4.2. Transit Node 464 As specified in [RFC8200], the only node allowed to inspect the 465 Routing Extension Header (and therefore the SRH), is the node 466 corresponding to the DA of the packet. Any other transit node MUST 467 NOT inspect the underneath routing header and MUST forward the packet 468 toward the DA according to its IPv6 routing table. 470 When a SID is in the destination address of an IPv6 header of a 471 packet, it's routed through an IPv6 network as an IPv6 address. 472 SIDs, or the prefix(es) covering SIDs, and their reachability may be 473 distributed by means outside the scope of this document. For 474 example, [RFC5308] or [RFC5340] may be used to advertise a prefix 475 covering the SIDs on a node. 477 4.3. SR Segment Endpoint Node 479 Without constraining the details of an implementation, the SR segment 480 endpoint node creates Forwarding Information Base (FIB) entries for 481 its local SIDs. 483 When an SRv6-capable node receives an IPv6 packet, it performs a 484 longest-prefix-match lookup on the packets destination address. This 485 lookup can return any of the following: 487 A FIB entry that represents a locally instantiated SRv6 SID 488 A FIB entry that represents a local interface, not locally 489 instantiated as an SRv6 SID 490 A FIB entry that represents a non-local route 491 No Match 493 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID 495 This document, and section, defines a single SRv6 SID called END. 496 Future documents may define additional SRv6 SIDs. In which case, the 497 entire content of this section will be defined in that document. 499 If the FIB entry represents a locally instantiated SRv6 SID, process 500 the next header of the IPv6 header as defined in section 4 of 501 [RFC8200] 503 The following sections describe the actions to take while processing 504 next header fields. 506 4.3.1.1. SRH Processing 507 When an SRH is processed { 508 If Segments Left is equal to zero { 509 Proceed to process the next header in the packet, whose type 510 is identified by the Next Header field in the Routing header. 511 } 512 Else { 513 If local policy requires TLV processing { 514 Perform TLV processing (see TLV Processing) 515 } 516 max_last_entry = ( Hdr Ext Len / 2 ) - 1 518 If ((Last Entry > max_last_entry) or 519 (Segments Left is greater than (Last Entry+1)) { 520 Send an ICMP Parameter Problem, Code 0, message to the 521 Source Address, pointing to the Segments Left field, and 522 discard the packet. 523 } 524 Else { 525 Decrement Segments Left by 1. 526 Copy Segment List[Segments Left] from the SRH to the 527 destination address of the IPv6 header. 528 If the IPv6 Hop Limit is less than or equal to 1 { 529 Send an ICMP Time Exceeded -- Hop Limit Exceeded in 530 Transit message to the Source Address and discard 531 the packet. 532 } 533 Else { 534 Decrement the Hop Limit by 1 535 Resubmit the packet to the IPv6 module for transmission 536 to the new destination. 537 } 538 } 539 } 540 } 542 4.3.1.1.1. TLV Processing 544 Local policy determines how TLV's are to be processed when the Active 545 Segment is a local END SID. The definition of local policy is 546 outside the scope of this document. 548 For illustration purpose only, two example local policies that may be 549 associated with an END SID are provided below. 551 Example 1: 552 For any packet received from interface I2 553 Skip TLV processing 555 Example 2: 556 For any packet received from interface I1 557 If first TLV is HMAC { 558 Process the HMAC TLV 559 } 560 Else { 561 Discard the packet 562 } 564 4.3.1.2. Upper-layer Header or No Next Header 566 Send an ICMP destination unreachable to 567 the Source Address and discard the packet. 569 4.3.2. FIB Entry is a Local Interface 571 If the FIB entry represents a local interface, not locally 572 instantiated as an SRv6 SID, the SRH is processed as follows: 574 If Segments Left is zero, the node must ignore the Routing header 575 and proceed to process the next header in the packet, whose type 576 is identified by the Next Header field in the Routing Header. 578 If Segments Left is non-zero, the node must discard the packet and 579 send an ICMP Parameter Problem, Code 0, message to the packet's 580 Source Address, pointing to the unrecognized Routing Type. 582 4.3.3. FIB Entry Is A Non-Local Route 584 Processing is not changed by this document. 586 4.3.4. FIB Entry Is A No Match 588 Processing is not changed by this document. 590 4.3.5. Load Balancing and ECMP 592 Within an SR domain, an SR source node encapsulates a packet in an 593 outer IPv6 header for transport to an endpoint. The SR source node 594 MUST impose a flow label computed based on the inner packet. The 595 computation of the flow label is as recommended in [RFC6438] for the 596 sending Tunnel End Point. 598 At any transit node within an SR domain, the flow label MUST be used 599 as defined in [RFC6438] to calculate the ECMP hash toward the 600 destination address. If flow label is not used, the transit node may 601 hash all packets between a pair of SR Edge nodes to the same link. 603 At an SR segment endpoint node, the flow label MUST be used as 604 defined in [RFC6438] to calculate any ECMP hash used to forward the 605 processed packet to the next segment. 607 5. Illustrations 609 This section provides illustrations of SRv6 packet processing at SR 610 source, transit and SR segment endpoint nodes. 612 5.1. Abstract Representation of an SRH 614 For a node k, its IPv6 address is represented as Ak, its SRv6 SID is 615 represented as Sk. 617 IPv6 headers are represented as the tuple of (source, destination). 618 For example, a packet with source address A1 and destination address 619 A2 is represented as (A1,A2). The payload of the packet is omitted. 621 An SR Policy is a list of segments. A list of segments is 622 represented as where S1 is the first SID to visit, S2 is 623 the second SID to visit and S3 is the last SID to visit. 625 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 627 o Source Address is SA, Destination Addresses is DA, and next-header 628 is SRH. 630 o SRH with SID list with SegmentsLeft = SL. 632 o Note the difference between the <> and () symbols. 633 represents a SID list where the leftmost segment is the first 634 segment. Whereas, (S3, S2, S1; SL) represents the same SID list 635 but encoded in the SRH Segment List format where the leftmost 636 segment is the last segment. When referring to an SR policy in a 637 high-level use-case, it is simpler to use the 638 notation. When referring to an illustration of detailed behavior, 639 the (S3, S2, S1; SL) notation is more convenient. 641 At its SR Policy headend, the Segment List results in SRH 642 (S3,S2,S1; SL=2) represented fully as: 644 Segments Left=2 645 Last Entry=2 646 Flags=0 647 Tag=0 648 Segment List[0]=S3 649 Segment List[1]=S2 650 Segment List[2]=S1 652 5.2. Example Topology 654 The following topology is used in examples below: 656 + * * * * * * * * * * * * * * * * * * * * + 658 * [8] [9] * 659 | | 660 * | | * 661 [1]----[3]--------[5]----------------[6]---------[4]---[2] 662 * | | * 663 | | 664 * | | * 665 +--------[7]-------+ 666 * * 668 + * * * * * * * SR Domain * * * * * * * + 670 o 3 and 4 are SR Domain edge routers 672 o 5, 6, and 7 are all SR Domain routers 674 o 8 and 9 are hosts within the SR Domain 676 o 1 and 2 are hosts outside the SR Domain 678 5.3. Source SR Node 680 5.3.1. Intra SR Domain Packet 682 When host 8 sends a packet to host 9 via an SR Policy the 683 packet is 685 P1: (A8,S7)(A9,S7; SL=1) 687 5.3.1.1. Reduced Variant 689 When host 8 sends a packet to host 9 via an SR Policy and it 690 wants to use a reduced SRH, the packet is 691 P2: (A8,S7)(A9; SL=1) 693 5.3.2. Transit Packet Through SR Domain 695 When host 1 sends a packet to host 2, the packet is 697 P3: (A1,A2) 699 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 700 egress router 4 via an SR Policy . Router 3 encapsulates the 701 received packet P3 in an outer header with an SRH. The packet is 703 P4: (A3, S7)(S4, S7; SL=1)(A1, A2) 705 If the SR Policy contains only one segment (the egress router 4), the 706 ingress Router 3 encapsulates P3 into an outer header (A3, S4). The 707 packet is 709 P5: (A3, S4)(A1, A2) 711 5.3.2.1. Reduced Variant 713 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 714 egress router 4 via an SR Policy . If router 3 wants to use 715 a reduced SRH, Router 3 encapsulates the received packet P3 in an 716 outer header with a reduced SRH. The packet is 718 P6: (A3, S7)(S4; SL=1)(A1, A2) 720 5.4. Transit Node 722 Nodes 5 acts as transit nodes for packet P1, and sends packet 724 P1: (A8,S7)(A9,S7;SL=1) 726 on the interface toward node 7. 728 5.5. SR Segment Endpoint Node 730 Node 7 receives packet P1 and, using the logic in section 4.3.1, 731 sends packet 733 P7: (A8,A9)(A9,S7; SL=0) 735 on the interface toward router 6. 737 6. Security Considerations 739 This section analyzes the security threat model, the security issues 740 and proposed solutions related to the new Segment Routing Header. 742 The Segment Routing Header (SRH) is simply another type of the 743 Routing Header as described in [RFC8200] and is: 745 o Added by an SR edge router when entering the segment routing 746 domain or by the originating host itself. The source host can 747 even be outside the SR domain; 749 o inspected and acted upon when reaching the destination address of 750 the IP header per [RFC8200]. 752 Per [RFC8200], routers on the path that simply forward an IPv6 packet 753 (i.e. the IPv6 destination address is none of theirs) will never 754 inspect and process the content of the SRH. Routers whose FIB 755 contains a locally instantiated SRv6 SID equal to the destination 756 address field of the IPv6 packet MUST parse the SRH if present, and 757 if supported and if the local configuration allows it, MUST act 758 accordingly to the SRH content. 760 As specified in [RFC8200], the default behavior of a non SR-capable 761 router upon receipt of an IPv6 packet with SRH destined to an address 762 of its, is to: 764 o ignore the SRH completely if the Segment Left field is 0 and 765 proceed to process the next header in the IPv6 packet; 767 o discard the IPv6 packet if Segment Left field is greater than 0, 768 it MAY send a Parameter Problem ICMP message back to the Source 769 Address. 771 6.1. Threat model 773 6.1.1. Source routing threats 775 Using an SRH is similar to source routing, therefore it has some 776 well-known security issues as described in [RFC4942] section 2.1.1 777 and [RFC5095]: 779 o amplification attacks: where a packet could be forged in such a 780 way to cause looping among a set of SR-enabled routers causing 781 unnecessary traffic, hence a Denial of Service (DoS) against 782 bandwidth; 784 o reflection attack: where a hacker could force an intermediate node 785 to appear as the immediate attacker, hence hiding the real 786 attacker from naive forensic; 788 o bypass attack: where an intermediate node could be used as a 789 stepping stone (for example in a De-Militarized Zone) to attack 790 another host (for example in the datacenter or any back-end 791 server). 793 6.1.2. Applicability of RFC 5095 to SRH 795 First of all, the reader must remember this specific part of section 796 1 of [RFC5095], "A side effect is that this also eliminates benign 797 RH0 use-cases; however, such applications may be facilitated by 798 future Routing Header specifications.". In short, it is not 799 forbidden to create new secure type of Routing Header; for example, 800 [RFC6554] (RPL) also creates a new Routing Header type for a specific 801 application confined in a single network. 803 In the segment routing architecture described in 804 [I-D.ietf-spring-segment-routing] there are basically two kinds of 805 nodes (routers and hosts): 807 o nodes within the SR domain, which is within one single 808 administrative domain, i.e., where all nodes are trusted anyway 809 else the damage caused by those nodes could be worse than 810 amplification attacks: traffic interception, man-in-the-middle 811 attacks, more server DoS by dropping packets, and so on. 813 o nodes outside of the SR domain, which is outside of the 814 administrative segment routing domain hence they cannot be trusted 815 because there is no physical security for those nodes, i.e., they 816 can be replaced by hostile nodes or can be coerced in wrong 817 behaviors. 819 The main use case for SR consists of the single administrative domain 820 where only trusted nodes with SR enabled and configured participate 821 in SR: this is the same model as in [RFC6554]. All non-trusted nodes 822 do not participate as either SR processing is not enabled by default 823 or because they only process SRH from nodes within their domain. 825 Moreover, all SR nodes ignore SRH created by outsiders based on 826 topology information (received on a peering or internal interface) or 827 on presence and validity of the HMAC field. Therefore, if 828 intermediate nodes ONLY act on valid and authorized SRH (such as 829 within a single administrative domain), then there is no security 830 threat similar to RH-0. Hence, the [RFC5095] attacks are not 831 applicable. 833 6.1.3. Service stealing threat 835 Segment routing is used for added value services, there is also a 836 need to prevent non-participating nodes to use those services; this 837 is called 'service stealing prevention'. 839 6.1.4. Topology disclosure 841 The SRH may also contains SIDs of some intermediate SR-nodes in the 842 path towards the destination, this obviously reveals those addresses 843 to the potentially hostile attackers if those attackers are able to 844 intercept packets containing SRH. On the other hand, if the attacker 845 can do a traceroute whose probes will be forwarded along the SR 846 Policy, then there is little learned by intercepting the SRH itself. 848 6.1.5. ICMP Generation 850 Per Section 4.4 of [RFC8200], when destination nodes (i.e. where the 851 destination address is one of theirs) receive a Routing Header with 852 unsupported Routing Type, the required behavior is: 854 o If Segments Left is zero, the node must ignore the Routing Header 855 and proceed to process the next header in the packet. 857 o If Segments Left is non-zero, the node must discard the packet and 858 send an ICMP Parameter Problem, Code 0, message to the packet's 859 Source Address, pointing to the unrecognized Routing Type. 861 This required behavior could be used by an attacker to force the 862 generation of ICMP message by any node. The attacker could send 863 packets with SRH (with Segment Left not set to 0) destined to a node 864 not supporting SRH. Per [RFC8200], the destination node could 865 generate an ICMP message, causing a local CPU utilization and if the 866 source of the offending packet with SRH was spoofed could lead to a 867 reflection attack without any amplification. 869 It must be noted that this is a required behavior for any unsupported 870 Routing Type and not limited to SRH packets. So, it is not specific 871 to SRH and the usual rate limiting for ICMP generation is required 872 anyway for any IPv6 implementation and has been implemented and 873 deployed for many years. 875 6.2. Security fields in SRH 877 This section summarizes the use of specific fields in the SRH. They 878 are based on a key-hashed message authentication code (HMAC). 880 The security-related fields in the SRH are instantiated by the HMAC 881 TLV, containing: 883 o HMAC Key-id, 32 bits wide; 885 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 886 0). 888 The HMAC field is the output of the HMAC computation (per [RFC2104]) 889 using a pre-shared key identified by HMAC Key-id and of the text 890 which consists of the concatenation of: 892 o the source IPv6 address; 894 o Last Entry field; 896 o an octet of bit flags; 898 o HMAC Key-id; 900 o all addresses in the Segment List. 902 The purpose of the HMAC TLV is to verify the validity, the integrity 903 and the authorization of the SRH itself. If an outsider of the SR 904 domain does not have access to a current pre-shared secret, then it 905 cannot compute the right HMAC field and the first SR router on the 906 path processing the SRH and configured to check the validity of the 907 HMAC will simply reject the packet. 909 The HMAC TLV is located at the end of the SRH simply because only the 910 router on the ingress of the SR domain needs to process it, then all 911 other SR nodes can ignore it (based on local policy) because they 912 trust the upstream router. This is to speed up forwarding operations 913 because SR routers which do not validate the SRH do not need to parse 914 the SRH until the end. 916 The HMAC Key-id field allows for the simultaneous existence of 917 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 918 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 919 has neither syntax nor semantic except as an index to the right 920 combination of pre-shared key and hash algorithm and except that a 921 value of 0 means that there is no HMAC field. Having an HMAC Key-id 922 field allows for pre-shared key roll-over when two pre-shared keys 923 are supported for a while when all SR nodes converged to a fresher 924 pre-shared key. It could also allow for interoperation among 925 different SR domains if allowed by local policy and assuming a 926 collision-free HMAC Key Id allocation. 928 When a specific SRH is linked to a time-related service (such as 929 turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are 930 identical, then it is important to refresh the shared-secret 931 frequently as the HMAC validity period expires only when the HMAC 932 Key-id and its associated shared-secret expires. 934 6.2.1. Selecting a hash algorithm 936 The HMAC field in the HMAC TLV is 256 bit wide. Therefore, the HMAC 937 MUST be based on a hash function whose output is at least 256 bits. 938 If the output of the hash function is 256, then this output is simply 939 inserted in the HMAC field. If the output of the hash function is 940 larger than 256 bits, then the output value is truncated to 256 by 941 taking the least-significant 256 bits and inserting them in the HMAC 942 field. 944 SRH implementations can support multiple hash functions but MUST 945 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 947 NOTE: SHA-1 is currently used by some early implementations used for 948 quick interoperations testing, the 160-bit hash value must then be 949 right-hand padded with 96 bits set to 0. The authors understand that 950 this is not secure but is ok for limited tests. 952 6.2.2. Performance impact of HMAC 954 While adding an HMAC to each and every SR packet increases the 955 security, it has a performance impact. Nevertheless, it must be 956 noted that: 958 o the HMAC field is used only when SRH is added by a device (such as 959 a home set-top box) which is outside of the segment routing 960 domain. If the SRH is added by a router in the trusted segment 961 routing domain, then, there is no need for an HMAC field, hence no 962 performance impact. 964 o when present, the HMAC field need only be checked and validated by 965 the first router of the segment routing domain, this router is 966 named 'validating SR router'. 968 o this validating SR router can also have a cache of to improve the performance. It is not the 970 same use case as in IPsec where HMAC value was unique per packet, 971 in SRH, the HMAC value is unique per flow. 973 o hash functions such as SHA-2 have been optimized for security and 974 performance and there are multiple implementations with good 975 performance. 977 With the above points in mind, the performance impact of using HMAC 978 is minimized. 980 6.2.3. Pre-shared key management 982 The field HMAC Key-id allows for: 984 o key roll-over: when there is a need to change the key (the hash 985 pre-shared secret), then multiple pre-shared keys can be used 986 simultaneously. The validating SR router can have a table of 987 for the currently active and 988 future keys. 990 o different algorithms: by extending the previous table to , the validating SR 992 router can also support several hash algorithms (see section 993 Section 6.2.1) 995 The pre-shared secret distribution can be done: 997 o in the configuration of the validating SR routers, either by 998 static configuration or any SDN oriented approach; 1000 o dynamically using a trusted key distribution such as [RFC6407] 1002 The intent of this document is NOT to define yet-another-key- 1003 distribution-protocol. 1005 6.3. Deployment Models 1007 6.3.1. Nodes within the SR domain 1009 SR Source Nodes within an SR Domain are trusted to generate IPv6 1010 packets with SRH. SR segment endpoint nodes receiving packets on 1011 interface that are part of the SR Domain may process any packet 1012 destined to a local segment, containing an SRH. 1014 6.3.2. Nodes outside of the SR domain 1016 Nodes outside the SR Domain cannot be trusted. SR Domain Ingress 1017 routers SHOULD discard packets destined to SIDs within the SR Domain 1018 (regardless of the presence of an SRH) to avoid attacks on the SR 1019 Domain. This is accomplished via infrastructure Access Lists (iACLs) 1020 applied on domain ingress nodes. However the SR Domain may be 1021 extended to nodes outside of it via use of the SRH HMAC. 1023 Nodes outside the SR Domain may request, by some trusted means 1024 outside the scope of this document, a complete SRH including an HMAC 1025 TLV which is computed correctly for the SRH (see Section 6.2). 1027 SR Domain ingress routers permit traffic destined to select SIDs with 1028 local policy requiring HMAC TLV processing for those select SIDs, 1029 i.e. these SIDs provide a gateway to the SR Domain for a set of 1030 segment lists. 1032 If HMAC validation is successful, the packet is forwarded to the next 1033 segment. Within the SR Domain no further HMAC check need be 1034 performed. However, other segments in the SR domain MAY verify the 1035 HMAC TLV when the SRH is processed, dependent on local policy. 1037 If HMAC validation fails an ICMP error message (parameter problem) 1038 SHOULD be generated (but rate limited) and SHOULD be logged. 1040 6.3.3. SR path exposure 1042 The SRH contains a Segment List. If an observer outside the SR 1043 Domain is able to inspect the SRH, they may use the segments in the 1044 Segment List to launch an attack on the SR Domain or obtain knowledge 1045 of the topology within the SR Domain. When the SR Source node is 1046 outside the SR Domain and the packet traverses the public internet to 1047 the SR Domain ingress router it is likely that others will have 1048 access to the Segment List in the SRH. 1050 IPSec Encapsulating Security Payload (ESP), [RFC4303], cannot be use 1051 to protect the SRH as the ESP header must appear after the routing 1052 header (including SRH). 1054 Exposure of segments and TLV content to observers outside the SR 1055 Domain should be considered in any deployment. There are two methods 1056 to limit exposure, and attacks on segments within the SR Domain from 1057 outside the SR Domain: 1059 Limit the number of segments and the TLV data exposed in SRH from 1060 nodes outside the SR Domain. 1062 Restrict which SIDs may accept traffic from outside the SR Domain 1063 to only those enforcing HMAC verification by using iACLs (as 1064 described in Section 6.3.2). 1066 6.3.4. Impact of BCP-38 1068 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 1069 whether the source address of packets received on an interface is 1070 valid for this interface. The use of loose source routing such as 1071 SRH forces packets to follow a path which differs from the expected 1072 routing. Therefore, if BCP-38 was implemented in all routers inside 1073 the SR domain, SR packets could be received by an interface which is 1074 not the expected one, and the packets could be dropped. 1076 As BCP-38 is only deployed at the ingress routers of an 1077 administrative domain, and as Packets arriving at those ingress 1078 routers have been forwarded using the routing information, then there 1079 is no reason why this ingress router should drop the SRH packet based 1080 on BCP-38. Routers inside the domain commonly do not apply BCP-38; 1081 so, this is not a problem. 1083 7. IANA Considerations 1085 This document makes the following registrations in the Internet 1086 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1087 maintained by IANA: 1089 Suggested Description Reference 1090 Value 1091 ---------------------------------------------------------- 1092 4 Segment Routing Header (SRH) This document 1094 This document request IANA to create and maintain a new Registry: 1095 "Segment Routing Header TLVs" 1097 7.1. Segment Routing Header Flags Register 1099 This document requests the creation of a new IANA managed registry to 1100 identify SRH Flags Bits. The registration procedure is "Expert 1101 Review" as defined in [RFC8126]. Suggested registry name is "Segment 1102 Routing Header Flags". Flags is 8 bits, the following bits are 1103 defined in this document: 1105 Suggested Description Reference 1106 Bit 1107 ----------------------------------------------------- 1108 4 HMAC This document 1110 7.2. Segment Routing Header TLVs Register 1112 This document requests the creation of a new IANA managed registry to 1113 identify SRH TLVs. The registration procedure is "Expert Review" as 1114 defined in [RFC8126]. Suggested registry name is "Segment Routing 1115 Header TLVs". A TLV is identified through an unsigned 8 bit 1116 codepoint value. The following codepoints are defined in this 1117 document: 1119 Suggested Description Reference 1120 Value 1121 ----------------------------------------------------- 1122 5 HMAC TLV This document 1123 128 Pad0 TLV This document 1124 129 PadN TLV This document 1126 8. Implementation Status 1128 This section is to be removed prior to publishing as an RFC. 1130 8.1. Linux 1132 Name: Linux Kernel v4.14 1134 Status: Production 1136 Implementation: adds SRH, performs END processing, supports HMAC TLV 1138 Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and 1139 [I-D.filsfils-spring-srv6-interop] 1141 8.2. Cisco Systems 1143 Name: IOS XR and IOS XE 1145 Status: Pre-production 1147 Implementation: adds SRH, performs END processing, no TLV processing 1149 Details: [I-D.filsfils-spring-srv6-interop] 1151 8.3. FD.io 1153 Name: VPP/Segment Routing for IPv6 1155 Status: Production 1157 Implementation: adds SRH, performs END processing, no TLV processing 1159 Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and 1160 [I-D.filsfils-spring-srv6-interop] 1162 8.4. Barefoot 1164 Name: Barefoot Networks Tofino NPU 1166 Status: Prototype 1167 Implementation: performs END processing, no TLV processing 1169 Details: [I-D.filsfils-spring-srv6-interop] 1171 8.5. Juniper 1173 Name: Juniper Networks Trio and vTrio NPU's 1175 Status: Prototype & Experimental 1177 Implementation: SRH insertion mode, Process SID where SID is an 1178 interface address, no TLV processing 1180 9. Contributors 1182 Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung, 1183 Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, 1184 Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre 1185 Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta 1186 Maglione, James Connolly, Aloys Augustin contributed to the content 1187 of this document. 1189 10. Acknowledgements 1191 The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, 1192 Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, 1193 and David Lebrun for their comments to this document. 1195 11. References 1197 11.1. Normative References 1199 [FIPS180-4] 1200 National Institute of Standards and Technology, "FIPS 1201 180-4 Secure Hash Standard (SHS)", March 2012, 1202 . 1205 [I-D.ietf-spring-segment-routing] 1206 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1207 Litkowski, S., and R. Shakir, "Segment Routing 1208 Architecture", draft-ietf-spring-segment-routing-15 (work 1209 in progress), January 2018. 1211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1212 Requirement Levels", BCP 14, RFC 2119, 1213 DOI 10.17487/RFC2119, March 1997, 1214 . 1216 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1217 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1218 . 1220 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1221 of Type 0 Routing Headers in IPv6", RFC 5095, 1222 DOI 10.17487/RFC5095, December 2007, 1223 . 1225 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1226 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1227 October 2011, . 1229 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1230 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1231 May 2017, . 1233 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1234 (IPv6) Specification", STD 86, RFC 8200, 1235 DOI 10.17487/RFC8200, July 2017, 1236 . 1238 11.2. Informative References 1240 [I-D.filsfils-spring-srv6-interop] 1241 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 1242 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 1243 "SRv6 interoperability report", draft-filsfils-spring- 1244 srv6-interop-00 (work in progress), March 2018. 1246 [I-D.filsfils-spring-srv6-network-programming] 1247 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 1248 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1249 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 1250 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 1251 M. Sharif, "SRv6 Network Programming", draft-filsfils- 1252 spring-srv6-network-programming-04 (work in progress), 1253 March 2018. 1255 [I-D.ietf-spring-segment-routing-mpls] 1256 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1257 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1258 data plane", draft-ietf-spring-segment-routing-mpls-14 1259 (work in progress), June 2018. 1261 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1262 Hashing for Message Authentication", RFC 2104, 1263 DOI 10.17487/RFC2104, February 1997, 1264 . 1266 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1267 Defeating Denial of Service Attacks which employ IP Source 1268 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1269 May 2000, . 1271 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1272 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1273 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1274 . 1276 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1277 DOI 10.17487/RFC4302, December 2005, 1278 . 1280 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1281 Co-existence Security Considerations", RFC 4942, 1282 DOI 10.17487/RFC4942, September 2007, 1283 . 1285 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1286 DOI 10.17487/RFC5308, October 2008, 1287 . 1289 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1290 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1291 . 1293 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1294 for Equal Cost Multipath Routing and Link Aggregation in 1295 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1296 . 1298 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1299 Routing Header for Source Routes with the Routing Protocol 1300 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1301 DOI 10.17487/RFC6554, March 2012, 1302 . 1304 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1305 Writing an IANA Considerations Section in RFCs", BCP 26, 1306 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1307 . 1309 Authors' Addresses 1311 Clarence Filsfils (editor) 1312 Cisco Systems, Inc. 1313 Brussels 1314 BE 1316 Email: cfilsfil@cisco.com 1318 Stefano Previdi 1319 Individual 1320 Italy 1322 Email: stefano@previdi.net 1324 John Leddy 1325 Comcast 1326 4100 East Dry Creek Road 1327 Centennial, CO 80122 1328 US 1330 Email: John_Leddy@comcast.com 1332 Satoru Matsushima 1333 Softbank 1335 Email: satoru.matsushima@g.softbank.co.jp 1337 Daniel Voyer (editor) 1338 Bell Canada 1340 Email: daniel.voyer@bell.ca