idnits 2.17.00 (12 Aug 2021) /tmp/idnits57140/draft-ietf-6man-segment-routing-header-13.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 (May 23, 2018) is 1459 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 222 -- Looks like a reference, but probably isn't: '8' on line 635 -- Looks like a reference, but probably isn't: '9' on line 635 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 == 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: draft-ietf-spring-segment-routing-mpls has been published as RFC 8660 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi 3 Internet-Draft Individual 4 Intended status: Standards Track C. Filsfils, Ed. 5 Expires: November 24, 2018 Cisco Systems, Inc. 6 J. Leddy 7 Comcast 8 S. Matsushima 9 Softbank 10 D. Voyer, Ed. 11 Bell Canada 12 May 23, 2018 14 IPv6 Segment Routing Header (SRH) 15 draft-ietf-6man-segment-routing-header-13 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", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 24, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Segment Routing Extension Header . . . . . . . . . . . . . . 4 66 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 7 68 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8 69 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 9 71 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 9 72 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 10 73 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 10 75 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 10 76 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11 77 4.3. Segment Endpoint Node . . . . . . . . . . . . . . . . . . 11 78 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 11 79 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 12 80 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 13 81 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 13 82 4.4. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 13 83 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 13 84 5.1. Abstract Representation of an SRH . . . . . . . . . . . . 13 85 5.2. Example Topology . . . . . . . . . . . . . . . . . . . . 14 86 5.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 15 87 5.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 15 88 5.3.2. Transit Packet Through SR Domain . . . . . . . . . . 15 89 5.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 15 90 5.5. SR End Node . . . . . . . . . . . . . . . . . . . . . . . 16 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17 93 6.1.1. Source routing threats . . . . . . . . . . . . . . . 17 94 6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 17 95 6.1.3. Service stealing threat . . . . . . . . . . . . . . . 18 96 6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 18 97 6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 18 98 6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 19 99 6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 20 100 6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 20 101 6.2.3. Pre-shared key management . . . . . . . . . . . . . . 21 102 6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 22 103 6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 22 104 6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 22 105 6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 23 106 6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 23 107 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 108 7.1. Segment Routing Header Flags Register . . . . . . . . . . 24 109 7.2. Segment Routing Header TLVs Register . . . . . . . . . . 24 110 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 111 8.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 24 112 8.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 25 113 8.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 25 114 8.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 25 115 8.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 25 116 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 117 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 118 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 119 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 120 11.2. Informative References . . . . . . . . . . . . . . . . . 27 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 123 1. Introduction 125 Segment Routing can be applied to the IPv6 data plane using a new 126 type of Routing Extension Header (SRH). This document describes the 127 Segment Routing Extension Header and how it is used by Segment 128 Routing capable nodes. 130 The Segment Routing Architecture [I-D.ietf-spring-segment-routing] 131 describes Segment Routing and its instantiation in two data planes 132 MPLS and IPv6. 134 SR with the MPLS data plane is defined in 135 [I-D.ietf-spring-segment-routing-mpls]. 137 SR with the IPv6 data plane is defined in 138 [I-D.filsfils-spring-srv6-network-programming]. 140 The encoding of MPLS labels and label stacking are defined in 141 [RFC3032]. 143 The encoding of IPv6 segments in the Segment Routing Extension header 144 is defined in this document. 146 Terminology used within this document is defined in detail in 147 [I-D.ietf-spring-segment-routing]. Specifically, these terms: 148 Segment Routing, SR Domain, SRv6, Segment ID (SID), SRv6 SID, Active 149 Segment, and SR Policy. 151 2. Segment Routing Extension Header 153 Routing Headers are defined in [RFC8200]. The Segment Routing Header 154 has a new Routing Type (suggested value 4) to be assigned by IANA. 156 The Segment Routing Header (SRH) is defined as follows: 158 0 1 2 3 159 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Last Entry | Flags | Tag | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | 166 | Segment List[0] (128 bits IPv6 address) | 167 | | 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | | 171 | | 172 ... 173 | | 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | | 177 | Segment List[n] (128 bits IPv6 address) | 178 | | 179 | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 // // 182 // Optional Type Length Value objects (variable) // 183 // // 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 where: 188 o Next Header: Defined in [RFC8200] 189 o Hdr Ext Len: Defined in [RFC8200] 191 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 193 o Segments Left: Defined in [RFC8200] 195 o Last Entry: contains the index (zero based), in the Segment List, 196 of the last element of the Segment List. 198 o Flags: 8 bits of flags. Following flags are defined: 200 0 1 2 3 4 5 6 7 201 +-+-+-+-+-+-+-+-+ 202 | U |H| U | 203 +-+-+-+-+-+-+-+-+ 205 U: Unused and for future use. SHOULD be 0 on transmission and 206 MUST be ignored on receipt. 208 H-flag: HMAC flag. If set, the HMAC TLV is present and is 209 encoded as the last TLV of the SRH. In other words, the last 210 36 octets of the SRH represent the HMAC information. See 211 Section 2.1.2 for details on the HMAC TLV. 213 o Tag: tag a packet as part of a class or group of packets, e.g., 214 packets sharing the same set of properties. When tag is not used 215 at source it SHOULD be set to zero on transmission. When tag is 216 not used during SRH Processing it MUST be ignored. The allocation 217 and use of tag is outside the scope of this document. 219 o Segment List[n]: 128 bit IPv6 addresses representing the nth 220 segment in the Segment List. The Segment List is encoded starting 221 from the last segment of the SR Policy. I.e., the first element 222 of the segment list (Segment List [0]) contains the last segment 223 of the SR Policy, the second element contains the penultimate 224 segment of the SR Policy and so on. 226 o Type Length Value (TLV) are described in Section 2.1. 228 2.1. SRH TLVs 230 This section defines TLVs of the Segment Routing Header. 232 0 1 233 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 235 | Type | Length | Variable length data 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 238 Type: An 8 bit value. Unrecognized Types MUST be ignored on receipt. 240 Length: The length of the Variable length data. It is RECOMMENDED 241 that the total length of new TLVs be multiple of 8 bytes to avoid the 242 use of Padding TLVs. 244 Variable length data: Length bytes of data that is specific to the 245 Type. 247 Type Length Value (TLV) contain optional information that may be used 248 by the node identified in the Destination Address (DA) of the packet. 249 The information carried in the TLVs is not intended to be used by the 250 routing layer. Typically, TLVs carry information that is consumed by 251 other components (e.g.: OAM) than the routing function. 253 Each TLV has its own length, format and semantic. The code-point 254 allocated (by IANA) to each TLV Type defines both the format and the 255 semantic of the information carried in the TLV. Multiple TLVs may be 256 encoded in the same SRH. 258 TLVs may change en route at each segment. To identify when a TLV 259 type may change en route the most significant bit of the Type has the 260 following significance: 262 0: TLV data does not change en route 264 1: TLV data does change en route 266 Identifying which TLVs change en route, without having to understand 267 the Type, is required for Authentication Header Integrity Check Value 268 (ICV) computation. Any TLV that changes en route is considered 269 mutable for the purpose of ICV computation, the Type Length and 270 Variable Length Data is ignored for the purpose of ICV Computation as 271 defined in [RFC4302]. 273 The "Length" field of the TLV is used to skip the TLV while 274 inspecting the SRH in case the node doesn't support or recognize the 275 Type. The "Length" defines the TLV length in octets, not including 276 the "Type" and "Length" fields. 278 The following TLVs are defined in this document: 280 Padding TLV 282 HMAC TLV 284 Additional TLVs may be defined in the future. 286 2.1.1. Padding TLVs 288 There are two types of padding TLVs, pad0 and padN, the following 289 applies to both: 291 Padding TLVs are optional and more than one Padding TLV MUST NOT 292 appear in the SRH. 294 The Padding TLVs are used to align the SRH total length on the 8 295 octet boundary. 297 When present, a single Pad0 or PadN TLV MUST appear as the last 298 TLV before the HMAC TLV (if HMAC TLV is present). 300 When present, a PadN TLV MUST have a length from 0 to 5 in order 301 to align the SRH total length on a 8-octet boundary. 303 Padding TLVs are ignored by a node processing the SRH TLV, even if 304 more than one is present. 306 Padding TLVs are ignored during ICV calculation. 308 2.1.1.1. PAD0 310 0 1 2 3 4 5 6 7 311 +-+-+-+-+-+-+-+-+ 312 | Type | 313 +-+-+-+-+-+-+-+-+ 315 Type: to be assigned by IANA (Suggested value 128) 317 A single Pad0 TLV MUST be used when a single byte of padding is 318 required. If more than one byte of padding is required a Pad0 TLV 319 MUST NOT be used, the PadN TLV MUST be used. 321 2.1.1.2. PADN 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type | Length | Padding (variable) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 // Padding (variable) // 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Type: to be assigned by IANA (suggested value 129). 332 Length: 0 to 5 334 Padding: Length octets of padding. Padding bits have no 335 semantics. They SHOULD be set to 0 on transmission and MUST be 336 ignored on receipt. 338 The PadN TLV MUST be used when more than one byte of padding is 339 required. 341 2.1.2. HMAC TLV 343 HMAC TLV is optional and contains the HMAC information. The HMAC TLV 344 has the following format: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | RESERVED | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | HMAC Key ID (4 octets) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | // 354 | HMAC (32 octets) // 355 | // 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 where: 360 o Type: to be assigned by IANA (suggested value 5). 362 o Length: 38. 364 o RESERVED: 2 octets. SHOULD be unset on transmission and MUST be 365 ignored on receipt. 367 o HMAC Key ID: 4 octets. 369 o HMAC: 32 octets. 371 o HMAC and HMAC Key ID usage is described in Section 6 373 The Following applies to the HMAC TLV: 375 o When present, the HMAC TLV MUST be encoded as the last TLV of the 376 SRH. 378 o If the HMAC TLV is present, the SRH H-Flag (Figure 2) MUST be set. 379 Nodes processing SRH SHOULD process the HMAC TLV only when the 380 H-Flag is set, and local policy. 382 o When the H-flag is set in the SRH, the router inspecting the SRH 383 MUST find the HMAC TLV in the last 38 octets of the SRH. 385 3. SR Nodes 387 There are different types of nodes that may be involved in segment 388 routing networks: source SR nodes originate packets with a segment in 389 the destination address of the IPv6 header, transit nodes that 390 forward packets destined to a remote segment, and segment endpoint 391 nodes that process a local segment in the destination address of an 392 IPv6 header. 394 3.1. Source SR Node 396 A Source SR Node is any node that originates an IPv6 packet with a 397 segment (i.e. SRv6 SID) in the destination address of the IPv6 398 header. The packet leaving the source SR Node may or may not contain 399 an SRH. This includes either: 401 A host originating an IPv6 packet. 403 An SR domain ingress router encapsulating a received packet in an 404 outer IPv6 header, followed by an optional SRH. 406 The mechanism through which a segment in the destination address of 407 the IPv6 header and the Segment List in the SRH, is derived is 408 outside the scope of this document. For example, the Segment List 409 may be obtained through local SR Policy computation, local 410 configuration, interaction with a controller instantiating an SR 411 Policy, or any other mechanism. 413 3.2. Transit Node 415 A transit node is any node forwarding an IPv6 packet where the 416 destination address of that packet is not locally configured as a 417 segment nor a local interface. A transit node is not required to be 418 capable of processing a segment nor SRH. 420 3.3. SR Segment Endpoint Node 422 A SR segment endpoint node is any node receiving an IPv6 packet where 423 the destination address of that packet is locally configured as a 424 segment or local interface. 426 4. Packet Processing 428 This section describes SRv6 packet processing at the Source, Transit 429 and Segment Endpoint nodes. 431 4.1. Source SR Node 433 A Source node steers a packet into an SR Policy and the SRH is 434 created as follows: 436 Next Header and Hdr Ext Len fields are set as specified in 437 [RFC8200]. 439 Routing Type field is set as TBD (to be allocated by IANA, 440 suggested value 4). 442 The DA of the packet is set with the value of the first segment. 444 The first element of the SRH Segment List is the ultimate segment. 445 The second element is the penultimate segment and so on. 447 The Segments Left field is set to n-1 where n is the number of 448 elements in the SR Policy. 450 The Last Entry field is set to n-1 where n is the number of 451 elements in the SR Policy. 453 HMAC TLV may be set according to Section 6. 455 If the segment list contains a single segment and there is no need 456 for information in flag or TLV, then the SRH MAY be omitted. 458 The packet is forwarded toward the packet's Destination Address 459 (the first segment). 461 4.1.1. Reduced SRH 463 When a source does not require the entire SID list to be preserved in 464 the SRH, a reduced SRH may be used. 466 A reduced SRH does not contain the first segment of the related SR 467 Policy (the first segment is the one already in the DA of the IPv6 468 header), and the Last Entry field is set to n-2 where n is the number 469 of elements in the SR Policy. 471 4.2. Transit Node 473 As specified in [RFC8200], the only node allowed to inspect the 474 Routing Extension Header (and therefore the SRH), is the node 475 corresponding to the DA of the packet. Any other transit node MUST 476 NOT inspect the underneath routing header and MUST forward the packet 477 toward the DA according to its IPv6 routing table. 479 When a SID is in the destination address of an IPv6 header of a 480 packet, it's routed through an IPv6 network as an IPv6 address. 481 SIDs, or the prefix(es) covering SIDs, and their reachability may be 482 distributed by means outside the scope of this document. For 483 example, [RFC5308] or [RFC5340] may be used to advertise a prefix 484 covering the SIDs on a node. 486 4.3. Segment Endpoint Node 488 Without constraining the details of an implementation, the Segment 489 Endpoint Node creates Forwarding Information Base (FIB) entries for 490 its local SIDs. 492 When an SRv6-capable node receives an IPv6 packet, it performs a 493 longest-prefix-match lookup on the packets destination address. This 494 lookup can return any of the following: 496 A FIB entry that represents a locally instantiated SRv6 SID 497 A FIB entry that represents a local interface, not locally 498 instantiated as an SRv6 SID 499 A FIB entry that represents a non-local route 500 No Match 502 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID 504 This document, and section, defines a single SRv6 SID called END. 505 Future documents may define additional SRv6 SIDs. In which case, the 506 entire content of this section will be defined in that document. 508 If the FIB entry represents a locally instantiated SRv6 SID, process 509 the next header of the IPv6 header as defined in section 4 of 510 [RFC8200] until the upper-layer header, or "No Next Header" is 511 reached. 513 When an SRH is processed { 514 If Segments Left is equal to zero { 515 Skip SRH Processing 516 } 517 Else { 518 If Segments Left is greater than (Last Entry+1) { 519 Send an ICMP Parameter Problem, Code 0, message to the 520 Source Address, pointing to the Segments Left field, and 521 discard the packet. 522 } 523 Else { 524 Decrement Segments Left by 1. 525 Copy Segment List[Segments Left] from the SRH to the 526 destination address of the IPv6 header. 527 If the IPv6 Hop Limit is less than or equal to 1 { 528 Send an ICMP Time Exceeded -- Hop Limit Exceeded in 529 Transit message to the Source Address and discard 530 the packet. 531 } 532 Else { 533 Decrement the Hop Limit by 1 534 Resubmit the packet to the IPv6 module for transmission 535 to the new destination. 536 } 537 } 538 } 539 } 541 If the upper-layer header or No Next Header is reached { 542 Send an ICMP destination unreachable to 543 the Source Address and discard the packet. 544 } 546 4.3.2. FIB Entry is a Local Interface 548 If the FIB entry represents a local interface, not locally 549 instantiated as an SRv6 SID, the SRH is processed as follows: 551 If Segments Left is zero, the node must ignore the Routing header 552 and proceed to process the next header in the packet, whose type 553 is identified by the Next Header field in the Routing header. 555 If Segments Left is non-zero, the node must discard the packet and 556 send an ICMP Parameter Problem, Code 0, message to the packet's 557 Source Address, pointing to the unrecognized Routing Type. 559 4.3.3. FIB Entry Is A Non-Local Route 561 Processing is not changed by this document. 563 4.3.4. FIB Entry Is A No Match 565 Processing is not changed by this document. 567 4.4. Load Balancing and ECMP 569 Within an SR domain, an SR source node encapsulates a packet in an 570 outer IPv6 header for transport to an endpoint. The SR source node 571 MUST impose a flow label computed based on the inner packet. The 572 computation of the flow label is as recommended in [RFC6438] for the 573 sending Tunnel End Point. 575 At any transit node within an SR domain, the flow label MUST be used 576 as defined in [RFC6438] to calculate the ECMP hash toward the 577 destination address. If flow label is not used, the transit node may 578 hash all packets between a pair of SR Edge nodes to the same link. 580 At an SR segment endpoint node, the flow label MUST be used as 581 defined in [RFC6438] to calculate any ECMP hash used to forward the 582 processed packet to the next segment. 584 5. Illustrations 586 This section provides illustrations of SRv6 packet processing at 587 source, transit and endpoint nodes. 589 5.1. Abstract Representation of an SRH 591 For a node k, its IPv6 address is represented as Ak, its SRv6 SID is 592 represented as Sk. 594 IPv6 headers are represented as the tuple of (source, destination). 595 For example, a packet with source address A1 and destination address 596 A2 is represented as (A1,A2). The payload of the packet is omitted. 598 An SR Policy is a list of segments. A list of segments is 599 represented as where S1 is the first SID to visit, S2 is 600 the second SID to visit and S3 is the last SID to visit. 602 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 604 o Source Address is SA, Destination Addresses is DA, and next-header 605 is SRH. 607 o SRH with SID list with SegmentsLeft = SL. 609 o Note the difference between the <> and () symbols. 610 represents a SID list where the leftmost segment is the first 611 segment. Whereas, (S3, S2, S1; SL) represents the same SID list 612 but encoded in the SRH Segment List format where the leftmost 613 segment is the last segment. When referring to an SR policy in a 614 high-level use-case, it is simpler to use the 615 notation. When referring to an illustration of detailed behavior, 616 the (S3, S2, S1; SL) notation is more convenient. 618 At its SR Policy headend, the Segment List results in SRH 619 (S3,S2,S1; SL=2) represented fully as: 621 Segments Left=2 622 Last Entry=2 623 Flags=0 624 Tag=0 625 Segment List[0]=S3 626 Segment List[1]=S2 627 Segment List[2]=S1 629 5.2. Example Topology 631 The following topology is used in examples below: 633 + * * * * * * * * * * * * * * * * * * * * + 635 * [8] [9] * 636 | | 637 * | | * 638 [1]----[3]--------[5]----------------[6]---------[4]---[2] 639 * | | * 640 | | 641 * | | * 642 +--------[7]-------+ 643 * * 645 + * * * * * * * SR Domain * * * * * * * + 647 o 3 and 4 are SR Domain edge routers 649 o 5, 6, and 7 are all SR Domain routers 651 o 8 and 9 are hosts within the SR Domain 653 o 1 and 2 are hosts outside the SR Domain 655 5.3. Source SR Node 657 5.3.1. Intra SR Domain Packet 659 When host 8 sends a packet to host 9 via an SR Policy the 660 packet is 662 P1: (A8,S7)(A9,S7; SL=1) 664 5.3.1.1. Reduced Variant 666 When host 8 sends a packet to host 9 via an SR Policy and it 667 wants to use a reduced SRH, the packet is 669 P2: (A8,S7)(A9; SL=1) 671 5.3.2. Transit Packet Through SR Domain 673 When host 1 sends a packet to host 2, the packet is 675 P3: (A1,A2) 677 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 678 egress router 4 via an SR Policy . Router 3 encapsulates the 679 received packet P3 in an outer header with an SRH. The packet is 681 P4: (A3, S7)(S4, S7; SL=1)(A1, A2) 683 If the SR Policy contains only one segment (the egress router 4), the 684 ingress Router 3 encapsulates P3 into an outer header (A3, S4). The 685 packet is 687 P5: (A3, S4)(A1, A2) 689 5.3.2.1. Reduced Variant 691 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 692 egress router 4 via an SR Policy . If router 3 wants to use 693 a reduced SRH, Router 3 encapsulates the received packet P3 in an 694 outer header with a reduced SRH. The packet is 696 P6: (A3, S7)(S4; SL=1)(A1, A2) 698 5.4. Transit Node 700 Nodes 5 acts as transit nodes for packet P1, and sends packet 702 P1: (A8,S7)(A9,S7;SL=1) 703 on the interface toward node 7. 705 5.5. SR End Node 707 Node 7 receives packet P1 and, using the logic in section 4.3.1, 708 sends packet 710 P7: (A8,A9)(A9,S7; SL=0) 712 on the interface toward router 6. 714 6. Security Considerations 716 This section analyzes the security threat model, the security issues 717 and proposed solutions related to the new Segment Routing Header. 719 The Segment Routing Header (SRH) is simply another type of the 720 routing header as described in [RFC8200] and is: 722 o Added by an SR edge router when entering the segment routing 723 domain or by the originating host itself. The source host can 724 even be outside the SR domain; 726 o inspected and acted upon when reaching the destination address of 727 the IP header per [RFC8200]. 729 Per [RFC8200], routers on the path that simply forward an IPv6 packet 730 (i.e. the IPv6 destination address is none of theirs) will never 731 inspect and process the content of the SRH. Routers whose FIB 732 contains a locally instantiated SRv6 SID equal to the destination 733 address field of the IPv6 packet MUST parse the SRH and, if supported 734 and if the local configuration allows it, MUST act accordingly to the 735 SRH content. 737 As specified in [RFC8200], the default behavior of a non SR-capable 738 router upon receipt of an IPv6 packet with SRH destined to an address 739 of its, is to: 741 o ignore the SRH completely if the Segment Left field is 0 and 742 proceed to process the next header in the IPv6 packet; 744 o discard the IPv6 packet if Segment Left field is greater than 0, 745 it MAY send a Parameter Problem ICMP message back to the Source 746 Address. 748 6.1. Threat model 750 6.1.1. Source routing threats 752 Using an SRH is similar to source routing, therefore it has some 753 well-known security issues as described in [RFC4942] section 2.1.1 754 and [RFC5095]: 756 o amplification attacks: where a packet could be forged in such a 757 way to cause looping among a set of SR-enabled routers causing 758 unnecessary traffic, hence a Denial of Service (DoS) against 759 bandwidth; 761 o reflection attack: where a hacker could force an intermediate node 762 to appear as the immediate attacker, hence hiding the real 763 attacker from naive forensic; 765 o bypass attack: where an intermediate node could be used as a 766 stepping stone (for example in a De-Militarized Zone) to attack 767 another host (for example in the datacenter or any back-end 768 server). 770 6.1.2. Applicability of RFC 5095 to SRH 772 First of all, the reader must remember this specific part of section 773 1 of [RFC5095], "A side effect is that this also eliminates benign 774 RH0 use-cases; however, such applications may be facilitated by 775 future Routing Header specifications.". In short, it is not 776 forbidden to create new secure type of Routing Header; for example, 777 [RFC6554] (RPL) also creates a new Routing Header type for a specific 778 application confined in a single network. 780 In the segment routing architecture described in 781 [I-D.ietf-spring-segment-routing] there are basically two kinds of 782 nodes (routers and hosts): 784 o nodes within the SR domain, which is within one single 785 administrative domain, i.e., where all nodes are trusted anyway 786 else the damage caused by those nodes could be worse than 787 amplification attacks: traffic interception, man-in-the-middle 788 attacks, more server DoS by dropping packets, and so on. 790 o nodes outside of the SR domain, which is outside of the 791 administrative segment routing domain hence they cannot be trusted 792 because there is no physical security for those nodes, i.e., they 793 can be replaced by hostile nodes or can be coerced in wrong 794 behaviors. 796 The main use case for SR consists of the single administrative domain 797 where only trusted nodes with SR enabled and configured participate 798 in SR: this is the same model as in [RFC6554]. All non-trusted nodes 799 do not participate as either SR processing is not enabled by default 800 or because they only process SRH from nodes within their domain. 802 Moreover, all SR nodes ignore SRH created by outsiders based on 803 topology information (received on a peering or internal interface) or 804 on presence and validity of the HMAC field. Therefore, if 805 intermediate nodes ONLY act on valid and authorized SRH (such as 806 within a single administrative domain), then there is no security 807 threat similar to RH-0. Hence, the [RFC5095] attacks are not 808 applicable. 810 6.1.3. Service stealing threat 812 Segment routing is used for added value services, there is also a 813 need to prevent non-participating nodes to use those services; this 814 is called 'service stealing prevention'. 816 6.1.4. Topology disclosure 818 The SRH may also contains SIDs of some intermediate SR-nodes in the 819 path towards the destination, this obviously reveals those addresses 820 to the potentially hostile attackers if those attackers are able to 821 intercept packets containing SRH. On the other hand, if the attacker 822 can do a traceroute whose probes will be forwarded along the SR 823 Policy, then there is little learned by intercepting the SRH itself. 825 6.1.5. ICMP Generation 827 Per Section 4.4 of [RFC8200], when destination nodes (i.e. where the 828 destination address is one of theirs) receive a Routing Header with 829 unsupported Routing Type, the required behavior is: 831 o If Segments Left is zero, the node must ignore the Routing header 832 and proceed to process the next header in the packet. 834 o If Segments Left is non-zero, the node must discard the packet and 835 send an ICMP Parameter Problem, Code 0, message to the packet's 836 Source Address, pointing to the unrecognized Routing Type. 838 This required behavior could be used by an attacker to force the 839 generation of ICMP message by any node. The attacker could send 840 packets with SRH (with Segment Left not set to 0) destined to a node 841 not supporting SRH. Per [RFC8200], the destination node could 842 generate an ICMP message, causing a local CPU utilization and if the 843 source of the offending packet with SRH was spoofed could lead to a 844 reflection attack without any amplification. 846 It must be noted that this is a required behavior for any unsupported 847 Routing Type and not limited to SRH packets. So, it is not specific 848 to SRH and the usual rate limiting for ICMP generation is required 849 anyway for any IPv6 implementation and has been implemented and 850 deployed for many years. 852 6.2. Security fields in SRH 854 This section summarizes the use of specific fields in the SRH. They 855 are based on a key-hashed message authentication code (HMAC). 857 The security-related fields in the SRH are instantiated by the HMAC 858 TLV, containing: 860 o HMAC Key-id, 32 bits wide; 862 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 863 0). 865 The HMAC field is the output of the HMAC computation (per [RFC2104]) 866 using a pre-shared key identified by HMAC Key-id and of the text 867 which consists of the concatenation of: 869 o the source IPv6 address; 871 o Last Entry field; 873 o an octet of bit flags; 875 o HMAC Key-id; 877 o all addresses in the Segment List. 879 The purpose of the HMAC TLV is to verify the validity, the integrity 880 and the authorization of the SRH itself. If an outsider of the SR 881 domain does not have access to a current pre-shared secret, then it 882 cannot compute the right HMAC field and the first SR router on the 883 path processing the SRH and configured to check the validity of the 884 HMAC will simply reject the packet. 886 The HMAC TLV is located at the end of the SRH simply because only the 887 router on the ingress of the SR domain needs to process it, then all 888 other SR nodes can ignore it (based on local policy) because they 889 trust the upstream router. This is to speed up forwarding operations 890 because SR routers which do not validate the SRH do not need to parse 891 the SRH until the end. 893 The HMAC Key-id field allows for the simultaneous existence of 894 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 895 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 896 has neither syntax nor semantic except as an index to the right 897 combination of pre-shared key and hash algorithm and except that a 898 value of 0 means that there is no HMAC field. Having an HMAC Key-id 899 field allows for pre-shared key roll-over when two pre-shared keys 900 are supported for a while when all SR nodes converged to a fresher 901 pre-shared key. It could also allow for interoperation among 902 different SR domains if allowed by local policy and assuming a 903 collision-free HMAC Key Id allocation. 905 When a specific SRH is linked to a time-related service (such as 906 turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are 907 identical, then it is important to refresh the shared-secret 908 frequently as the HMAC validity period expires only when the HMAC 909 Key-id and its associated shared-secret expires. 911 6.2.1. Selecting a hash algorithm 913 The HMAC field in the HMAC TLV is 256 bit wide. Therefore, the HMAC 914 MUST be based on a hash function whose output is at least 256 bits. 915 If the output of the hash function is 256, then this output is simply 916 inserted in the HMAC field. If the output of the hash function is 917 larger than 256 bits, then the output value is truncated to 256 by 918 taking the least-significant 256 bits and inserting them in the HMAC 919 field. 921 SRH implementations can support multiple hash functions but MUST 922 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 924 NOTE: SHA-1 is currently used by some early implementations used for 925 quick interoperations testing, the 160-bit hash value must then be 926 right-hand padded with 96 bits set to 0. The authors understand that 927 this is not secure but is ok for limited tests. 929 6.2.2. Performance impact of HMAC 931 While adding an HMAC to each and every SR packet increases the 932 security, it has a performance impact. Nevertheless, it must be 933 noted that: 935 o the HMAC field is used only when SRH is added by a device (such as 936 a home set-up box) which is outside of the segment routing domain. 937 If the SRH is added by a router in the trusted segment routing 938 domain, then, there is no need for an HMAC field, hence no 939 performance impact. 941 o when present, the HMAC field MUST only be checked and validated by 942 the first router of the segment routing domain, this router is 943 named 'validating SR router'. Downstream routers may not inspect 944 the HMAC field. 946 o this validating router can also have a cache of to improve the performance. It is not the 948 same use case as in IPsec where HMAC value was unique per packet, 949 in SRH, the HMAC value is unique per flow. 951 o Last point, hash functions such as SHA-2 have been optimized for 952 security and performance and there are multiple implementations 953 with good performance. 955 With the above points in mind, the performance impact of using HMAC 956 is minimized. 958 6.2.3. Pre-shared key management 960 The field HMAC Key-id allows for: 962 o key roll-over: when there is a need to change the key (the hash 963 pre-shared secret), then multiple pre-shared keys can be used 964 simultaneously. The validating routing can have a table of for the currently active and future 966 keys. 968 o different algorithms: by extending the previous table to , the validating router 970 can also support simultaneously several hash algorithms (see 971 section Section 6.2.1) 973 The pre-shared secret distribution can be done: 975 o in the configuration of the validating routers, either by static 976 configuration or any SDN oriented approach; 978 o dynamically using a trusted key distribution such as [RFC6407] 980 The intent of this document is NOT to define yet-another-key- 981 distribution-protocol. 983 6.3. Deployment Models 985 6.3.1. Nodes within the SR domain 987 An SR domain is defined as a set of interconnected routers where all 988 routers at the perimeter are configured to add and act on SRH. Some 989 routers inside the SR domain can also act on SRH or simply forward 990 IPv6 packets. 992 The routers inside an SR domain can be trusted to generate SRH and to 993 process SRH received on interfaces that are part of the SR domain. 994 These nodes MUST drop all SRH packets received on an interface that 995 is not part of the SR domain, destined to a locally instantiated SID, 996 and containing an SRH whose HMAC field cannot be validated by local 997 policies. This includes obviously packet with an SRH generated by a 998 non-cooperative SR domain. 1000 If the validation fails, then these packets MUST be dropped, ICMP 1001 error messages (parameter problem) SHOULD be generated (but rate 1002 limited) and SHOULD be logged. 1004 6.3.2. Nodes outside of the SR domain 1006 Nodes outside of the SR domain cannot be trusted for physical 1007 security; hence, they need to request by some trusted means (outside 1008 the scope of this document) a complete SRH for each new connection 1009 (i.e. new destination address). The received SRH MUST include an 1010 HMAC TLV which is computed correctly (see Section 6.2). 1012 When an outside node sends a packet with an SRH and towards an SR 1013 domain ingress node, the packet MUST contain the HMAC TLV (with a 1014 Key-id and HMAC fields) and the the destination address MUST be an 1015 address of an SR domain ingress node . 1017 The ingress SR router, i.e., the router with a SID equal to the 1018 destination address, MUST verify the HMAC TLV. 1020 If the validation is successful, then the packet is simply forwarded 1021 as usual for an SR packet. As long as the packet travels within the 1022 SR domain, no further HMAC check needs to be done. Subsequent 1023 routers in the SR domain MAY verify the HMAC TLV when they process 1024 the SRH (i.e. when they are the destination). 1026 If the validation fails, then this packet MUST be dropped, an ICMP 1027 error message (parameter problem) SHOULD be generated (but rate 1028 limited) and SHOULD be logged. 1030 6.3.3. SR path exposure 1032 As the intermediate SR nodes addresses appears in the SRH, if this 1033 SRH is visible to an outsider then he/she could reuse this knowledge 1034 to launch an attack on the intermediate SR nodes or get some insider 1035 knowledge on the topology. This is especially applicable when the 1036 path between the source node and the first SR domain ingress router 1037 is on the public Internet. 1039 The first remark is to state that 'security by obscurity' is never 1040 enough; in other words, the security policy of the SR domain MUST 1041 assume that the internal topology and addressing is known by the 1042 attacker. A simple traceroute will also give the same information 1043 (with even more information as all intermediate nodes between SID 1044 will also be exposed). IPsec Encapsulating Security Payload 1045 [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP 1046 header must appear after any routing header (including SRH). 1048 To prevent a user to leverage the gained knowledge by intercepting 1049 SRH, it it recommended to apply an infrastructure Access Control List 1050 (iACL) at the edge of the SR domain. This iACL will drop all packets 1051 from outside the SR-domain whose destination is any address of any 1052 router interface or SID inside the domain. This security policy 1053 should be tuned for local operations. 1055 6.3.4. Impact of BCP-38 1057 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 1058 whether the source address of packets received on an interface is 1059 valid for this interface. The use of loose source routing such as 1060 SRH forces packets to follow a path which differs from the expected 1061 routing. Therefore, if BCP-38 was implemented in all routers inside 1062 the SR domain, then SR packets could be received by an interface 1063 which is not expected one and the packets could be dropped. 1065 As an SR domain is usually a subset of one administrative domain, and 1066 as BCP-38 is only deployed at the ingress routers of this 1067 administrative domain and as packets arriving at those ingress 1068 routers have been normally forwarded using the normal routing 1069 information, then there is no reason why this ingress router should 1070 drop the SRH packet based on BCP-38. Routers inside the domain 1071 commonly do not apply BCP-38; so, this is not a problem. 1073 7. IANA Considerations 1075 This document makes the following registrations in the Internet 1076 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1077 maintained by IANA: 1079 Suggested Description Reference 1080 Value 1081 ---------------------------------------------------------- 1082 4 Segment Routing Header (SRH) This document 1084 This document request IANA to create and maintain a new Registry: 1085 "Segment Routing Header TLVs" 1087 7.1. Segment Routing Header Flags Register 1089 This document requests the creation of a new IANA managed registry to 1090 identify SRH Flags Bits. The registration procedure is "Expert 1091 Review" as defined in [RFC8126]. Suggested registry name is "Segment 1092 Routing Header Flags". Flags is 8 bits, the following bits are 1093 defined in this document: 1095 Suggested Description Reference 1096 Bit 1097 ----------------------------------------------------- 1098 4 HMAC This document 1100 7.2. Segment Routing Header TLVs Register 1102 This document requests the creation of a new IANA managed registry to 1103 identify SRH TLVs. The registration procedure is "Expert Review" as 1104 defined in [RFC8126]. Suggested registry name is "Segment Routing 1105 Header TLVs". A TLV is identified through an unsigned 8 bit 1106 codepoint value. The following codepoints are defined in this 1107 document: 1109 Suggested Description Reference 1110 Value 1111 ----------------------------------------------------- 1112 5 HMAC TLV This document 1113 128 Pad0 TLV This document 1114 129 PadN TLV This document 1116 8. Implementation Status 1118 This section is to be removed prior to publishing as an RFC. 1120 8.1. Linux 1122 Name: Linux Kernel v4.14 1124 Status: Production 1126 Implementation: adds SRH, performs END processing, supports HMAC TLV 1127 Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and 1128 [I-D.filsfils-spring-srv6-interop] 1130 8.2. Cisco Systems 1132 Name: IOS XR and IOS XE 1134 Status: Pre-production 1136 Implementation: adds SRH, performs END processing, no TLV processing 1138 Details: [I-D.filsfils-spring-srv6-interop] 1140 8.3. FD.io 1142 Name: VPP/Segment Routing for IPv6 1144 Status: Production 1146 Implementation: adds SRH, performs END processing, no TLV processing 1148 Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and 1149 [I-D.filsfils-spring-srv6-interop] 1151 8.4. Barefoot 1153 Name: Barefoot Networks Tofino NPU 1155 Status: Prototype 1157 Implementation: performs END processing, no TLV processing 1159 Details: [I-D.filsfils-spring-srv6-interop] 1161 8.5. Juniper 1163 Name: Juniper Networks Trio and vTrio NPU's 1165 Status: Prototype & Experimental 1167 Implementation: SRH insertion mode, Process SID where SID is an 1168 interface address, no TLV processing 1170 9. Contributors 1172 Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung, 1173 Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, 1174 Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre 1175 Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta 1176 Maglione, James Connolly, Aloys Augustin contributed to the content 1177 of this document. 1179 10. Acknowledgements 1181 The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, 1182 Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, 1183 and David Lebrun for their comments to this document. 1185 11. References 1187 11.1. Normative References 1189 [FIPS180-4] 1190 National Institute of Standards and Technology, "FIPS 1191 180-4 Secure Hash Standard (SHS)", March 2012, 1192 . 1195 [I-D.ietf-spring-segment-routing] 1196 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1197 Litkowski, S., and R. Shakir, "Segment Routing 1198 Architecture", draft-ietf-spring-segment-routing-15 (work 1199 in progress), January 2018. 1201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1202 Requirement Levels", BCP 14, RFC 2119, 1203 DOI 10.17487/RFC2119, March 1997, 1204 . 1206 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1207 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1208 . 1210 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1211 of Type 0 Routing Headers in IPv6", RFC 5095, 1212 DOI 10.17487/RFC5095, December 2007, 1213 . 1215 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1216 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1217 October 2011, . 1219 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1220 (IPv6) Specification", STD 86, RFC 8200, 1221 DOI 10.17487/RFC8200, July 2017, 1222 . 1224 11.2. Informative References 1226 [I-D.filsfils-spring-srv6-interop] 1227 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 1228 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 1229 "SRv6 interoperability report", draft-filsfils-spring- 1230 srv6-interop-00 (work in progress), March 2018. 1232 [I-D.filsfils-spring-srv6-network-programming] 1233 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 1234 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1235 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 1236 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 1237 M. Sharif, "SRv6 Network Programming", draft-filsfils- 1238 spring-srv6-network-programming-04 (work in progress), 1239 March 2018. 1241 [I-D.ietf-spring-segment-routing-mpls] 1242 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1243 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1244 data plane", draft-ietf-spring-segment-routing-mpls-13 1245 (work in progress), April 2018. 1247 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1248 Hashing for Message Authentication", RFC 2104, 1249 DOI 10.17487/RFC2104, February 1997, 1250 . 1252 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1253 Defeating Denial of Service Attacks which employ IP Source 1254 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1255 May 2000, . 1257 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1258 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1259 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1260 . 1262 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1263 DOI 10.17487/RFC4302, December 2005, 1264 . 1266 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1267 Co-existence Security Considerations", RFC 4942, 1268 DOI 10.17487/RFC4942, September 2007, 1269 . 1271 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1272 DOI 10.17487/RFC5308, October 2008, 1273 . 1275 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1276 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1277 . 1279 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1280 for Equal Cost Multipath Routing and Link Aggregation in 1281 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1282 . 1284 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1285 Routing Header for Source Routes with the Routing Protocol 1286 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1287 DOI 10.17487/RFC6554, March 2012, 1288 . 1290 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1291 Writing an IANA Considerations Section in RFCs", BCP 26, 1292 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1293 . 1295 Authors' Addresses 1297 Stefano Previdi 1298 Individual 1299 Italy 1301 Email: stefano@previdi.net 1303 Clarence Filsfils (editor) 1304 Cisco Systems, Inc. 1305 Brussels 1306 BE 1308 Email: cfilsfil@cisco.com 1310 John Leddy 1311 Comcast 1312 4100 East Dry Creek Road 1313 Centennial, CO 80122 1314 US 1316 Email: John_Leddy@comcast.com 1317 Satoru Matsushima 1318 Softbank 1320 Email: satoru.matsushima@g.softbank.co.jp 1322 Daniel Voyer (editor) 1323 Bell Canada 1325 Email: daniel.voyer@bell.ca