idnits 2.17.1 draft-ietf-6man-segment-routing-header-12.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 (April 19, 2018) is 2198 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 301 == Missing Reference: 'SL' is mentioned on line 530, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' ** Downref: Normative reference to an Informational RFC: RFC 7855 ** Downref: Normative reference to an Informational RFC: RFC 8354 == 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 (-25) exists of draft-ietf-isis-segment-routing-extensions-15 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-13 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 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: October 21, 2018 Cisco Systems, Inc. 6 J. Leddy 7 Comcast 8 S. Matsushima 9 Softbank 10 D. Voyer, Ed. 11 Bell Canada 12 April 19, 2018 14 IPv6 Segment Routing Header (SRH) 15 draft-ietf-6man-segment-routing-header-12 17 Abstract 19 Segment Routing (SR) allows a node to steer a packet through a 20 controlled set of instructions, called segments, by prepending an SR 21 header to the packet. A segment can represent any instruction, 22 topological or service-based. SR allows a node to steer a flow 23 through any path (topological, or application/service based) while 24 maintaining per-flow state only at the ingress node to the SR domain. 26 Segment Routing can be applied to the IPv6 data plane with the 27 addition of a new type of Routing Extension Header. This document 28 describes the Segment Routing Extension Header Type and how it is 29 used by SR capable nodes. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on October 21, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. Data Planes supporting Segment Routing . . . . . . . . . 4 74 2.2. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . 4 75 2.3. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 5 76 3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 5 77 3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 8 79 3.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 10 80 3.2. SRH Processing . . . . . . . . . . . . . . . . . . . . . 11 81 4. SRH Functions . . . . . . . . . . . . . . . . . . . . . . . . 11 82 4.1. Endpoint Function (End) . . . . . . . . . . . . . . . . . 11 83 4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 12 84 5. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 5.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 13 86 5.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 14 87 5.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 14 88 5.4. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 14 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 15 91 6.1.1. Source routing threats . . . . . . . . . . . . . . . 15 92 6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 16 93 6.1.3. Service stealing threat . . . . . . . . . . . . . . . 17 94 6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 17 95 6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 17 96 6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 18 97 6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 19 98 6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 19 99 6.2.3. Pre-shared key management . . . . . . . . . . . . . . 20 100 6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 20 101 6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 20 102 6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 21 103 6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 21 104 6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 22 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 106 7.1. Segment Routing Header Flags Register . . . . . . . . . . 22 107 7.2. Segment Routing Header TLVs Register . . . . . . . . . . 23 108 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 109 8.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 23 110 8.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 23 111 8.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 24 112 8.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 24 113 8.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 24 114 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 115 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 117 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 118 11.2. Informative References . . . . . . . . . . . . . . . . . 26 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 121 1. Segment Routing Documents 123 Segment Routing terminology is defined in 124 [I-D.ietf-spring-segment-routing]. 126 The network programming paradigm 127 [I-D.filsfils-spring-srv6-network-programming] defines additional 128 functions associated to a Segment Routing for IPv6 (SRv6) Segment ID 129 (SID). 131 Segment Routing use cases are described in [RFC7855] and [RFC8354]. 133 Segment Routing protocol extensions are defined in 134 [I-D.ietf-isis-segment-routing-extensions], and 135 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 137 2. Introduction 139 Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing], 140 allows a node to steer a packet through a controlled set of 141 instructions, called segments, by prepending an SR header to the 142 packet. A segment can represent any instruction, topological or 143 service-based. SR allows a node to steer a flow through any path 144 (topological or service/application based) while maintaining per-flow 145 state only at the ingress node to the SR domain. Segments can be 146 derived from different components: IGP, BGP, Services, Contexts, 147 Locators, etc. The list of segment forming the path is called the 148 Segment List and is encoded in the packet header. 150 SR allows the use of strict and loose source based routing paradigms 151 without requiring any additional signaling protocols in the 152 infrastructure hence delivering an excellent scalability property. 154 The source based routing model described in 155 [I-D.ietf-spring-segment-routing] inherits from the ones proposed by 156 [RFC1940] and [RFC8200]. The source based routing model offers the 157 support for explicit routing capability. 159 2.1. Data Planes supporting Segment Routing 161 Segment Routing (SR), can be instantiated over MPLS 162 (SRMPLS)([I-D.ietf-spring-segment-routing-mpls]) and IPv6 (SRv6). 163 This document defines its instantiation over the IPv6 data-plane 164 based on the use-cases defined in [RFC8354]. 166 This document defines a new type of Routing Header (originally 167 defined in [RFC8200]) called the Segment Routing Header (SRH) in 168 order to convey the Segment List in the packet header as defined in 169 [I-D.ietf-spring-segment-routing]. Mechanisms through which segments 170 are known and advertised are outside the scope of this document. 172 2.2. SRv6 Segment 174 An SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are 175 often used as a shorter reference for "SRv6 Segment". 177 An SRv6-capable node N maintains a "My Local SID Table". This table 178 contains all the local SRv6 segments explicitly instantiated at node 179 N. N is the parent node for these SIDs. 181 A local SID of N could be an IPv6 address of a local interface of N 182 but it does not have to be. Most often, a local SID is not an 183 address of a local interface of N. The My Local SID Table is thus 184 not populated by default with all the addresses of a node. 186 Every SRv6 local SID instantiated has a specific instruction bounded 187 to it. 189 This information is stored in the My Local SID Table. The My Local 190 SID Table has three main purposes: 192 o Define which local SIDs are explicitly instantiated. 194 o Specify which instruction is bound to each of the instantiated 195 SIDs. 197 o Store the parameters associated to such instruction (i.e. OIF, 198 NextHop,...). 200 A Segment ID (SID) in the destination address of an IPv6 header, is 201 routed through an IPv6 network as an IPv6 address. SIDs, or the 202 prefix(es) covering SIDs in the My Local SID Table, and their 203 reachability may be distributed by means outside the scope of this 204 document. For example, [RFC5308] or [RFC5340] may be used to 205 advertise a prefix covering the My Local SID Table. 207 A node may receive a packet with an SRv6 SID in the DA without an 208 SRH. In such case the packet should still be processed by the 209 Segment Routing engine. 211 2.3. Segment Routing (SR) Domain 213 The Segment Routing Domain (SR Domain) is defined as the set of nodes 214 participating in the source based routing model. These nodes may be 215 connected to the same physical infrastructure (e.g.: a Service 216 Provider's network). 218 The SRH is added to the packet by its source, consistent with the 219 source routing model defined in [RFC8200]. For example: 221 o At the node originating the packet (host, server). 223 o At the ingress node of an SR domain where the ingress node 224 receives a packet and encapsulates it in an outer IPv6 header 225 followed by a Segment Routing header. 227 3. Segment Routing Extension Header (SRH) 229 A new type of the Routing Header (originally defined in [RFC8200]) is 230 defined: the Segment Routing Header (SRH) which has a new Routing 231 Type, (suggested value 4) to be assigned by IANA. 233 The Segment Routing Header (SRH) is defined as follows: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Last Entry | Flags | Tag | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 | Segment List[0] (128 bits IPv6 address) | 244 | | 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 | | 249 ... 250 | | 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 | Segment List[n] (128 bits IPv6 address) | 255 | | 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 // // 259 // Optional Type Length Value objects (variable) // 260 // // 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 where: 265 o Next Header: Defined in [RFC8200] 267 o Hdr Ext Len: Defined in [RFC8200] 269 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 271 o Segments Left: Defined in [RFC8200]. See Section 3.2 for detailed 272 usage during SRH processing. 274 o Last Entry: contains the index (zero based), in the Segment List, 275 of the last element of the Segment List. 277 o Flags: 8 bits of flags. Following flags are defined: 279 0 1 2 3 4 5 6 7 280 +-+-+-+-+-+-+-+-+ 281 | U |H| U | 282 +-+-+-+-+-+-+-+-+ 284 U: Unused and for future use. SHOULD be 0 on transmission and 285 MUST be ignored on receipt. 287 H-flag: HMAC flag. If set, the HMAC TLV is present and is 288 encoded as the last TLV of the SRH. In other words, the last 289 36 octets of the SRH represent the HMAC information. See 290 Section 3.1.2 for details on the HMAC TLV. 292 o Tag: tag a packet as part of a class or group of packets, e.g., 293 packets sharing the same set of properties. When tag is not used 294 at source it SHOULD be set to zero on transmission. When tag is 295 not used during SRH Processing it MUST be ignored. The allocation 296 and use of tag is outside the scope of this document. 298 o Segment List[n]: 128 bit IPv6 addresses representing the nth 299 segment in the Segment List. The Segment List is encoded starting 300 from the last segment of the path. I.e., the first element of the 301 segment list (Segment List [0]) contains the last segment of the 302 path, the second element contains the penultimate segment of the 303 path and so on. 305 o Type Length Value (TLV) are described in Section 3.1. 307 3.1. SRH TLVs 309 This section defines TLVs of the Segment Routing Header. 311 0 1 312 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 314 | Type | Length | Variable length data 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 317 Type: An 8 bit value. Unrecognized Types MUST be ignored on receipt. 319 Length: The length of the Variable length data. It is RECOMMENDED 320 that the total length of new TLVs be multiple of 8 bytes to avoid the 321 use of Padding TLVs. 323 Variable length data: Length bytes of data that is specific to the 324 Type. 326 Type Length Value (TLV) contain optional information that may be used 327 by the node identified in the DA of the packet. The information 328 carried in the TLVs is not intended to be used by the routing layer. 329 Typically, TLVs carry information that is consumed by other 330 components (e.g.: OAM) than the routing function. 332 Each TLV has its own length, format and semantic. The code-point 333 allocated (by IANA) to each TLV Type defines both the format and the 334 semantic of the information carried in the TLV. Multiple TLVs may be 335 encoded in the same SRH. 337 TLVs may change en route at each segment. To identify when a TLV 338 type may change en route the most significant bit of the Type has the 339 following significance: 341 0: TLV data does not change en route 343 1: TLV data does change en route 345 Identifying which TLVs change en route, without having to understand 346 the Type, is required for Authentication Header Integrity Check Value 347 (ICV) computation. Any TLV that changes en route is considered 348 mutable for the purpose of ICV computation, the Type Length and 349 Variable Length Data is ignored for the purpose of ICV Computation as 350 defined in [RFC4302]. 352 The "Length" field of the TLV is used to skip the TLV while 353 inspecting the SRH in case the node doesn't support or recognize the 354 Type. The "Length" defines the TLV length in octets, not including 355 the "Type" and "Length" fields. 357 The following TLVs are defined in this document: 359 Padding TLV 361 HMAC TLV 363 Additional TLVs may be defined in the future. 365 3.1.1. Padding TLVs 367 There are two types of padding TLVs, pad0 and padN, the following 368 applies to both: 370 Padding TLVs are optional and more than one Padding TLV MUST NOT 371 appear in the SRH. 373 The Padding TLVs are used to align the SRH total length on the 8 374 octet boundary. 376 When present, a single Pad0 or PadN TLV MUST appear as the last 377 TLV before the HMAC TLV (if HMAC TLV is present). 379 When present, a PadN TLV MUST have a length from 0 to 5 in order 380 to align the SRH total length on a 8-octet boundary. 382 Padding TLVs are ignored by a node processing the SRH TLV, even if 383 more than one is present. 385 Padding TLVs are ignored during ICV calculation. 387 3.1.1.1. PAD0 389 0 1 2 3 4 5 6 7 390 +-+-+-+-+-+-+-+-+ 391 | Type | 392 +-+-+-+-+-+-+-+-+ 394 Type: to be assigned by IANA (Suggested value 128) 396 A single Pad0 TLV MUST be used when a single byte of padding is 397 required. If more than one byte of padding is required a Pad0 TLV 398 MUST NOT be used, the PadN TLV MUST be used. 400 3.1.1.2. PADN 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type | Length | Padding (variable) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 // Padding (variable) // 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Type: to be assigned by IANA (suggested value 129). 412 Length: 0 to 5 414 Padding: Length octets of padding. Padding bits have no 415 semantics. They SHOULD be set to 0 on transmission and MUST be 416 ignored on receipt. 418 The PadN TLV MUST be used when more than one byte of padding is 419 required. 421 3.1.2. HMAC TLV 423 HMAC TLV is optional and contains the HMAC information. The HMAC TLV 424 has the following format: 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type | Length | RESERVED | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | HMAC Key ID (4 octets) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | // 434 | HMAC (32 octets) // 435 | // 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 where: 440 o Type: to be assigned by IANA (suggested value 5). 442 o Length: 38. 444 o RESERVED: 2 octets. SHOULD be unset on transmission and MUST be 445 ignored on receipt. 447 o HMAC Key ID: 4 octets. 449 o HMAC: 32 octets. 451 o HMAC and HMAC Key ID usage is described in Section 6 453 The Following applies to the HMAC TLV: 455 o When present, the HMAC TLV MUST be encoded as the last TLV of the 456 SRH. 458 o If the HMAC TLV is present, the SRH H-Flag (Figure 2) MUST be set. 459 Nodes processing SRH SHOULD process the HMAC TLV only when the 460 H-Flag is set, and local policy. 462 o When the H-flag is set in the SRH, the router inspecting the SRH 463 MUST find the HMAC TLV in the last 38 octets of the SRH. 465 3.2. SRH Processing 467 Extension header processing is as defined in RFC8200 for packets 468 destined to a local IPv6 address. If SRH is present, it is processed 469 as follows (DA represents the destination address in the IPv6 470 header): 472 1. IF the DA is in My Local SID Table 473 2. The function associated with the DA is processed. 474 (Examples are as described in section 4). 475 3. ELSE 476 4. Treat the extension header as unrecognized 477 and process as defined in RFC8200 section 4.4. 479 4. SRH Functions 481 Segment Routing architecture, as defined in 482 [I-D.ietf-spring-segment-routing] defines a segment as an instruction 483 or, more generally, a set of instructions (function). 485 In this section we review two functions that may be associated to a 486 segment: 488 o End: the endpoint (End) function is the base of the source routing 489 paradigm. It consists of updating the DA with the next segment 490 and forward the packet accordingly. 492 o End.X: The endpoint layer-3 cross-connect function. 494 Other functions may be defined in other documents. 496 4.1. Endpoint Function (End) 498 The Endpoint function (End) is the most basic function. 500 When the endpoint node receives a packet destined to DA "S" and S is 501 an entry in the My Local SID Table and the function associated with S 502 in that entry is "End" then the endpoint does: 504 1. IF SegmentsLeft > 0 THEN 505 2. decrement SL 506 3. update the IPv6 DA with SRH[SL] 507 4. FIB lookup on updated DA 508 5. forward accordingly to the matched entry 509 6. ELSE IF SID is assigned to an interface 510 7. proceed to process the next header 511 8. ELSE 512 9. drop the packet 513 It has to be noted that: 515 o The End function performs the FIB lookup in the forwarding table 516 of the ingress interface. 518 o An SRv6-capable node MUST include the FlowLabel of the IPv6 header 519 in its hash computation for ECMP load-balancing as described in 520 Section 5.4. 522 4.2. End.X: Endpoint with Layer-3 cross-connect 524 When the endpoint node receives a packet destined to DA "S" and S is 525 an entry in the My Local SID Table and the function associated with S 526 in that entry is "End.X" then the endpoint does: 528 1. IF SegmentsLeft > 0 THEN 529 2. decrement SL 530 3. update the IPv6 DA with SRH[SL] 531 4. forward to layer-3 adjacency bound to the SID "S" 532 5. ELSE 533 6. drop the packet 535 It has to be noted that: 537 o If an array of layer-3 adjacencies is bound to the End.X SID, one 538 entry of the array is selected based on a hash of the packet's 539 header as described in Section 5.4 541 o An End.X function does not allow decaps. An End.X SID cannot be 542 the last SID of an SRH and cannot be the DA of a packet without 543 SRH. 545 o The End.X function is required to express an explicit path through 546 an IP network. 548 o The End.X function is the SRv6 instantiation of a Adjacency SID as 549 defined in [I-D.ietf-spring-segment-routing]. 551 o Note that with SR-MPLS ([I-D.ietf-spring-segment-routing-mpls]), 552 an AdjSID is typically preceded by a PrefixSID. This is unlikely 553 in SRv6, most likely an End.X SID is globally routed address of N. 555 o If a node N has 30 outgoing interfaces to 30 neighbors, usually 556 the operator would explicitly instantiate 30 End.X SIDs at N: one 557 per layer-3 adjacency to a neighbor. Potentially, more End.X 558 could be explicitly defined (groups of layer-3 adjacencies to the 559 same neighbor or to different neighbors). 561 o If node N has a bundle outgoing interface I to a neighbor Q made 562 of 10 member links, N may allocate up to 11 End.X local SIDs for 563 that bundle: one for the bundle itself and then up to one for each 564 member link. This is the equivalent of the L2-Link Adj SID in SR- 565 MPLS ([I-D.ietf-isis-l2bundles]). 567 5. SR Nodes 569 There are different types of nodes that may be involved in segment 570 routing networks: source nodes that originate packets with an SRH, 571 transit nodes that forward packets having an SRH and segment endpoint 572 nodes that MUST process the SRH. 574 5.1. Source SR Node 576 A Source SR Node can be any node originating an IPv6 packet with its 577 IPv6 and Segment Routing Headers. This include either: 579 A host originating an IPv6 packet. 581 An SR domain ingress router encapsulating a received packet in an 582 outer IPv6 header followed by an SRH. 584 The mechanism through which a Segment List is derived is outside the 585 scope of this document. As an example, the Segment List may be 586 obtained through: 588 Local path computation. 590 Local configuration. 592 Interaction with a centralized controller delivering the path. 594 Any other mechanism. 596 The following are the steps of the creation of the SRH: 598 Next Header and Hdr Ext Len fields are set as specified in 599 [RFC8200]. 601 Routing Type field is set as TBD (to be allocated by IANA, 602 suggested value 4). 604 The DA of the packet is set with the value of the first segment. 606 The first element of the segment list is the last segment (the 607 final DA of the packet). The second element is the penultimate 608 segment and so on. 610 In other words, the Segment List is encoded in the reverse order 611 of the path. 613 The Segments Left field is set to n-1 where n is the number of 614 elements in the Segment List. 616 The Last_Entry field is set to n-1 where n is the number of 617 elements in the Segment List. 619 HMAC TLV may be set according to Section 6. 621 If the segment list contains a single segment and there is no need 622 for information in flag or TLV, then the SRH MAY be omitted. 624 The packet is sent towards the packet's DA (the first segment). 626 5.2. Transit Node 628 As specified in [RFC8200], the only node who is allowed to inspect 629 the Routing Extension Header (and therefore the SRH), is the node 630 corresponding to the DA of the packet. Any other transit node MUST 631 NOT inspect the underneath routing header and MUST forward the packet 632 towards the DA and according to the IPv6 routing table. 634 As a generic security measure, any service provider will block any 635 packet destined to one of its internal routers, especially if these 636 packets have an extension header in it. 638 5.3. SR Segment Endpoint Node 640 The SR segment endpoint node is the node whose My Local SID 641 Table contains an entry for the DA of the packet. 643 The segment endpoint node executes the function bound to the SID as 644 per the matched My Local SID entry (Section 4). 646 5.4. Load Balancing and ECMP 648 Within an SR domain, an SR source node encapsulates a packet in an 649 outer IPv6 header for transport to an endpoint. The SR source node 650 MUST impose a Flow Label computed based on the inner packet. The 651 computation of the flow label is as recommended in [RFC6438] for the 652 sending TEP. 654 At any transit node within an SR domain, the flow label MUST be used 655 as defined in [RFC6438] to calculate the ECMP hash toward the 656 destination address. 658 At an SR segment endpoint node, the flow label MUST be used as 659 defined in [RFC6438] to calculate any ECMP hash used to forward the 660 processed packet to the next segment. 662 6. Security Considerations 664 This section analyzes the security threat model, the security issues 665 and proposed solutions related to the new Segment Routing Header. 667 The Segment Routing Header (SRH) is simply another type of the 668 routing header as described in [RFC8200] and is: 670 o Added by an SR edge router when entering the segment routing 671 domain or by the originating host itself. The source host can 672 even be outside the SR domain; 674 o inspected and acted upon when reaching the destination address of 675 the IP header per [RFC8200]. 677 Per [RFC8200], routers on the path that simply forward an IPv6 packet 678 (i.e. the IPv6 destination address is none of theirs) will never 679 inspect and process the content of the SRH. Routers whose one 680 interface IPv6 address equals the destination address field of the 681 IPv6 packet MUST parse the SRH and, if supported and if the local 682 configuration allows it, MUST act accordingly to the SRH content. 684 As specified in [RFC8200], the default behavior of a non SR-capable 685 router upon receipt of an IPv6 packet with SRH destined to an address 686 of its, is to: 688 o ignore the SRH completely if the Segment Left field is 0 and 689 proceed to process the next header in the IPv6 packet; 691 o discard the IPv6 packet if Segment Left field is greater than 0, 692 it MAY send a Parameter Problem ICMP message back to the Source 693 Address. 695 6.1. Threat model 697 6.1.1. Source routing threats 699 Using an SRH is similar to source routing, therefore it has some 700 well-known security issues as described in [RFC4942] section 2.1.1 701 and [RFC5095]: 703 o amplification attacks: where a packet could be forged in such a 704 way to cause looping among a set of SR-enabled routers causing 705 unnecessary traffic, hence a Denial of Service (DoS) against 706 bandwidth; 708 o reflection attack: where a hacker could force an intermediate node 709 to appear as the immediate attacker, hence hiding the real 710 attacker from naive forensic; 712 o bypass attack: where an intermediate node could be used as a 713 stepping stone (for example in a De-Militarized Zone) to attack 714 another host (for example in the datacenter or any back-end 715 server). 717 6.1.2. Applicability of RFC 5095 to SRH 719 First of all, the reader must remember this specific part of section 720 1 of [RFC5095], "A side effect is that this also eliminates benign 721 RH0 use-cases; however, such applications may be facilitated by 722 future Routing Header specifications.". In short, it is not 723 forbidden to create new secure type of Routing Header; for example, 724 [RFC6554] (RPL) also creates a new Routing Header type for a specific 725 application confined in a single network. 727 In the segment routing architecture described in 728 [I-D.ietf-spring-segment-routing] there are basically two kinds of 729 nodes (routers and hosts): 731 o nodes within the SR domain, which is within one single 732 administrative domain, i.e., where all nodes are trusted anyway 733 else the damage caused by those nodes could be worse than 734 amplification attacks: traffic interception, man-in-the-middle 735 attacks, more server DoS by dropping packets, and so on. 737 o nodes outside of the SR domain, which is outside of the 738 administrative segment routing domain hence they cannot be trusted 739 because there is no physical security for those nodes, i.e., they 740 can be replaced by hostile nodes or can be coerced in wrong 741 behaviors. 743 The main use case for SR consists of the single administrative domain 744 where only trusted nodes with SR enabled and configured participate 745 in SR: this is the same model as in [RFC6554]. All non-trusted nodes 746 do not participate as either SR processing is not enabled by default 747 or because they only process SRH from nodes within their domain. 749 Moreover, all SR nodes ignore SRH created by outsiders based on 750 topology information (received on a peering or internal interface) or 751 on presence and validity of the HMAC field. Therefore, if 752 intermediate nodes ONLY act on valid and authorized SRH (such as 753 within a single administrative domain), then there is no security 754 threat similar to RH-0. Hence, the [RFC5095] attacks are not 755 applicable. 757 6.1.3. Service stealing threat 759 Segment routing is used for added value services, there is also a 760 need to prevent non-participating nodes to use those services; this 761 is called 'service stealing prevention'. 763 6.1.4. Topology disclosure 765 The SRH may also contains IPv6 addresses of some intermediate SR- 766 nodes in the path towards the destination, this obviously reveals 767 those addresses to the potentially hostile attackers if those 768 attackers are able to intercept packets containing SRH. On the other 769 hand, if the attacker can do a traceroute whose probes will be 770 forwarded along the SR path, then there is little learned by 771 intercepting the SRH itself. 773 6.1.5. ICMP Generation 775 Per Section 4.4 of [RFC8200], when destination nodes (i.e. where the 776 destination address is one of theirs) receive a Routing Header with 777 unsupported Routing Type, the required behavior is: 779 o If Segments Left is zero, the node must ignore the Routing header 780 and proceed to process the next header in the packet. 782 o If Segments Left is non-zero, the node must discard the packet and 783 send an ICMP Parameter Problem, Code 0, message to the packet's 784 Source Address, pointing to the unrecognized Routing Type. 786 This required behavior could be used by an attacker to force the 787 generation of ICMP message by any node. The attacker could send 788 packets with SRH (with Segment Left not set to 0) destined to a node 789 not supporting SRH. Per [RFC8200], the destination node could 790 generate an ICMP message, causing a local CPU utilization and if the 791 source of the offending packet with SRH was spoofed could lead to a 792 reflection attack without any amplification. 794 It must be noted that this is a required behavior for any unsupported 795 Routing Type and not limited to SRH packets. So, it is not specific 796 to SRH and the usual rate limiting for ICMP generation is required 797 anyway for any IPv6 implementation and has been implemented and 798 deployed for many years. 800 6.2. Security fields in SRH 802 This section summarizes the use of specific fields in the SRH. They 803 are based on a key-hashed message authentication code (HMAC). 805 The security-related fields in the SRH are instantiated by the HMAC 806 TLV, containing: 808 o HMAC Key-id, 32 bits wide; 810 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 811 0). 813 The HMAC field is the output of the HMAC computation (per [RFC2104]) 814 using a pre-shared key identified by HMAC Key-id and of the text 815 which consists of the concatenation of: 817 o the source IPv6 address; 819 o Last Entry field; 821 o an octet of bit flags; 823 o HMAC Key-id; 825 o all addresses in the Segment List. 827 The purpose of the HMAC TLV is to verify the validity, the integrity 828 and the authorization of the SRH itself. If an outsider of the SR 829 domain does not have access to a current pre-shared secret, then it 830 cannot compute the right HMAC field and the first SR router on the 831 path processing the SRH and configured to check the validity of the 832 HMAC will simply reject the packet. 834 The HMAC TLV is located at the end of the SRH simply because only the 835 router on the ingress of the SR domain needs to process it, then all 836 other SR nodes can ignore it (based on local policy) because they 837 trust the upstream router. This is to speed up forwarding operations 838 because SR routers which do not validate the SRH do not need to parse 839 the SRH until the end. 841 The HMAC Key-id field allows for the simultaneous existence of 842 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 843 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 844 has neither syntax nor semantic except as an index to the right 845 combination of pre-shared key and hash algorithm and except that a 846 value of 0 means that there is no HMAC field. Having an HMAC Key-id 847 field allows for pre-shared key roll-over when two pre-shared keys 848 are supported for a while when all SR nodes converged to a fresher 849 pre-shared key. It could also allow for interoperation among 850 different SR domains if allowed by local policy and assuming a 851 collision-free HMAC Key Id allocation. 853 When a specific SRH is linked to a time-related service (such as 854 turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are 855 identical, then it is important to refresh the shared-secret 856 frequently as the HMAC validity period expires only when the HMAC 857 Key-id and its associated shared-secret expires. 859 6.2.1. Selecting a hash algorithm 861 The HMAC field in the HMAC TLV is 256 bit wide. Therefore, the HMAC 862 MUST be based on a hash function whose output is at least 256 bits. 863 If the output of the hash function is 256, then this output is simply 864 inserted in the HMAC field. If the output of the hash function is 865 larger than 256 bits, then the output value is truncated to 256 by 866 taking the least-significant 256 bits and inserting them in the HMAC 867 field. 869 SRH implementations can support multiple hash functions but MUST 870 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 872 NOTE: SHA-1 is currently used by some early implementations used for 873 quick interoperations testing, the 160-bit hash value must then be 874 right-hand padded with 96 bits set to 0. The authors understand that 875 this is not secure but is ok for limited tests. 877 6.2.2. Performance impact of HMAC 879 While adding an HMAC to each and every SR packet increases the 880 security, it has a performance impact. Nevertheless, it must be 881 noted that: 883 o the HMAC field is used only when SRH is added by a device (such as 884 a home set-up box) which is outside of the segment routing domain. 885 If the SRH is added by a router in the trusted segment routing 886 domain, then, there is no need for an HMAC field, hence no 887 performance impact. 889 o when present, the HMAC field MUST only be checked and validated by 890 the first router of the segment routing domain, this router is 891 named 'validating SR router'. Downstream routers may not inspect 892 the HMAC field. 894 o this validating router can also have a cache of to improve the performance. It is not the 896 same use case as in IPsec where HMAC value was unique per packet, 897 in SRH, the HMAC value is unique per flow. 899 o Last point, hash functions such as SHA-2 have been optimized for 900 security and performance and there are multiple implementations 901 with good performance. 903 With the above points in mind, the performance impact of using HMAC 904 is minimized. 906 6.2.3. Pre-shared key management 908 The field HMAC Key-id allows for: 910 o key roll-over: when there is a need to change the key (the hash 911 pre-shared secret), then multiple pre-shared keys can be used 912 simultaneously. The validating routing can have a table of for the currently active and future 914 keys. 916 o different algorithms: by extending the previous table to , the validating router 918 can also support simultaneously several hash algorithms (see 919 section Section 6.2.1) 921 The pre-shared secret distribution can be done: 923 o in the configuration of the validating routers, either by static 924 configuration or any SDN oriented approach; 926 o dynamically using a trusted key distribution such as [RFC6407] 928 The intent of this document is NOT to define yet-another-key- 929 distribution-protocol. 931 6.3. Deployment Models 933 6.3.1. Nodes within the SR domain 935 An SR domain is defined as a set of interconnected routers where all 936 routers at the perimeter are configured to add and act on SRH. Some 937 routers inside the SR domain can also act on SRH or simply forward 938 IPv6 packets. 940 The routers inside an SR domain can be trusted to generate SRH and to 941 process SRH received on interfaces that are part of the SR domain. 942 These nodes MUST drop all SRH packets received on an interface that 943 is not part of the SR domain and containing an SRH whose HMAC field 944 cannot be validated by local policies. This includes obviously 945 packet with an SRH generated by a non-cooperative SR domain. 947 If the validation fails, then these packets MUST be dropped, ICMP 948 error messages (parameter problem) SHOULD be generated (but rate 949 limited) and SHOULD be logged. 951 6.3.2. Nodes outside of the SR domain 953 Nodes outside of the SR domain cannot be trusted for physical 954 security; hence, they need to request by some trusted means (outside 955 the scope of this document) a complete SRH for each new connection 956 (i.e. new destination address). The received SRH MUST include an 957 HMAC TLV which is computed correctly (see Section 6.2). 959 When an outside node sends a packet with an SRH and towards an SR 960 domain ingress node, the packet MUST contain the HMAC TLV (with a 961 Key-id and HMAC fields) and the the destination address MUST be an 962 address of an SR domain ingress node . 964 The ingress SR router, i.e., the router with an interface address 965 equal to the destination address, MUST verify the HMAC TLV. 967 If the validation is successful, then the packet is simply forwarded 968 as usual for an SR packet. As long as the packet travels within the 969 SR domain, no further HMAC check needs to be done. Subsequent 970 routers in the SR domain MAY verify the HMAC TLV when they process 971 the SRH (i.e. when they are the destination). 973 If the validation fails, then this packet MUST be dropped, an ICMP 974 error message (parameter problem) SHOULD be generated (but rate 975 limited) and SHOULD be logged. 977 6.3.3. SR path exposure 979 As the intermediate SR nodes addresses appears in the SRH, if this 980 SRH is visible to an outsider then he/she could reuse this knowledge 981 to launch an attack on the intermediate SR nodes or get some insider 982 knowledge on the topology. This is especially applicable when the 983 path between the source node and the first SR domain ingress router 984 is on the public Internet. 986 The first remark is to state that 'security by obscurity' is never 987 enough; in other words, the security policy of the SR domain MUST 988 assume that the internal topology and addressing is known by the 989 attacker. A simple traceroute will also give the same information 990 (with even more information as all intermediate nodes between SID 991 will also be exposed). IPsec Encapsulating Security Payload 993 [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP 994 header must appear after any routing header (including SRH). 996 To prevent a user to leverage the gained knowledge by intercepting 997 SRH, it it recommended to apply an infrastructure Access Control List 998 (iACL) at the edge of the SR domain. This iACL will drop all packets 999 from outside the SR-domain whose destination is any address of any 1000 router inside the domain. This security policy should be tuned for 1001 local operations. 1003 6.3.4. Impact of BCP-38 1005 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 1006 whether the source address of packets received on an interface is 1007 valid for this interface. The use of loose source routing such as 1008 SRH forces packets to follow a path which differs from the expected 1009 routing. Therefore, if BCP-38 was implemented in all routers inside 1010 the SR domain, then SR packets could be received by an interface 1011 which is not expected one and the packets could be dropped. 1013 As an SR domain is usually a subset of one administrative domain, and 1014 as BCP-38 is only deployed at the ingress routers of this 1015 administrative domain and as packets arriving at those ingress 1016 routers have been normally forwarded using the normal routing 1017 information, then there is no reason why this ingress router should 1018 drop the SRH packet based on BCP-38. Routers inside the domain 1019 commonly do not apply BCP-38; so, this is not a problem. 1021 7. IANA Considerations 1023 This document makes the following registrations in the Internet 1024 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1025 maintained by IANA: 1027 Suggested Description Reference 1028 Value 1029 ---------------------------------------------------------- 1030 4 Segment Routing Header (SRH) This document 1032 This document request IANA to create and maintain a new Registry: 1033 "Segment Routing Header TLVs" 1035 7.1. Segment Routing Header Flags Register 1037 This document requests the creation of a new IANA managed registry to 1038 identify SRH Flags Bits. The registration procedure is "Expert 1039 Review" as defined in [RFC8126]. Suggested registry name is "Segment 1040 Routing Header Flags". Flags is 8 bits, the following bits are 1041 defined in this document: 1043 Suggested Description Reference 1044 Bit 1045 ----------------------------------------------------- 1046 4 HMAC This document 1048 7.2. Segment Routing Header TLVs Register 1050 This document requests the creation of a new IANA managed registry to 1051 identify SRH TLVs. The registration procedure is "Expert Review" as 1052 defined in [RFC8126]. Suggested registry name is "Segment Routing 1053 Header TLVs". A TLV is identified through an unsigned 8 bit 1054 codepoint value. The following codepoints are defined in this 1055 document: 1057 Suggested Description Reference 1058 Value 1059 ----------------------------------------------------- 1060 5 HMAC TLV This document 1061 128 Pad0 TLV This document 1062 129 PadN TLV This document 1064 8. Implementation Status 1066 This section is to be removed prior to publishing as an RFC. 1068 8.1. Linux 1070 Name: Linux Kernel v4.14 1072 Status: Production 1074 Implementation: adds SRH, performs END and END.X processing, supports 1075 HMAC TLV 1077 Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and 1078 [I-D.filsfils-spring-srv6-interop] 1080 8.2. Cisco Systems 1082 Name: IOS XR and IOS XE 1084 Status: Pre-production 1086 Implementation: adds SRH, performs END and END.X processing, no TLV 1087 processing 1088 Details: [I-D.filsfils-spring-srv6-interop] 1090 8.3. FD.io 1092 Name: VPP/Segment Routing for IPv6 1094 Status: Production 1096 Implementation: adds SRH, performs END and END.X processing, no TLV 1097 processing 1099 Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and 1100 [I-D.filsfils-spring-srv6-interop] 1102 8.4. Barefoot 1104 Name: Barefoot Networks Tofino NPU 1106 Status: Prototype 1108 Implementation: performs END and END.X processing, no TLV processing 1110 Details: [I-D.filsfils-spring-srv6-interop] 1112 8.5. Juniper 1114 Name: Juniper Networks Trio and vTrio NPU's 1116 Status: Prototype & Experimental 1118 Implementation: SRH insertion mode, Process SID where SID is an 1119 interface address, no TLV processing 1121 9. Contributors 1123 Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung, 1124 Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, 1125 Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre 1126 Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta 1127 Maglione, James Connolly, Aloys Augustin contributed to the content 1128 of this document. 1130 10. Acknowledgements 1132 The authors would like to thank Ole Troan, Bob Hinden, Fred Baker, 1133 Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, and David 1134 Lebrun for their comments to this document. 1136 11. References 1138 11.1. Normative References 1140 [FIPS180-4] 1141 National Institute of Standards and Technology, "FIPS 1142 180-4 Secure Hash Standard (SHS)", March 2012, 1143 . 1146 [I-D.ietf-spring-segment-routing] 1147 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1148 Litkowski, S., and R. Shakir, "Segment Routing 1149 Architecture", draft-ietf-spring-segment-routing-15 (work 1150 in progress), January 2018. 1152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1153 Requirement Levels", BCP 14, RFC 2119, 1154 DOI 10.17487/RFC2119, March 1997, 1155 . 1157 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1158 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1159 . 1161 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1162 of Type 0 Routing Headers in IPv6", RFC 5095, 1163 DOI 10.17487/RFC5095, December 2007, 1164 . 1166 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1167 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1168 October 2011, . 1170 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1171 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1172 Packet Routing in Networking (SPRING) Problem Statement 1173 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1174 2016, . 1176 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1177 (IPv6) Specification", STD 86, RFC 8200, 1178 DOI 10.17487/RFC8200, July 2017, 1179 . 1181 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 1182 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 1183 Routing in Networking (SPRING)", RFC 8354, 1184 DOI 10.17487/RFC8354, March 2018, 1185 . 1187 11.2. Informative References 1189 [I-D.filsfils-spring-srv6-interop] 1190 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 1191 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 1192 "SRv6 interoperability report", draft-filsfils-spring- 1193 srv6-interop-00 (work in progress), March 2018. 1195 [I-D.filsfils-spring-srv6-network-programming] 1196 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 1197 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1198 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 1199 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 1200 M. Sharif, "SRv6 Network Programming", draft-filsfils- 1201 spring-srv6-network-programming-04 (work in progress), 1202 March 2018. 1204 [I-D.ietf-isis-l2bundles] 1205 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 1206 E. Aries, "Advertising L2 Bundle Member Link Attributes in 1207 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 1208 May 2017. 1210 [I-D.ietf-isis-segment-routing-extensions] 1211 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1212 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 1213 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1214 segment-routing-extensions-15 (work in progress), December 1215 2017. 1217 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1218 Psenak, P., Filsfils, C., Previdi, S., Gredler, H., 1219 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1220 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1221 segment-routing-extensions-11 (work in progress), January 1222 2018. 1224 [I-D.ietf-spring-segment-routing-mpls] 1225 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1226 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1227 data plane", draft-ietf-spring-segment-routing-mpls-13 1228 (work in progress), April 2018. 1230 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1231 Zappala, "Source Demand Routing: Packet Format and 1232 Forwarding Specification (Version 1)", RFC 1940, 1233 DOI 10.17487/RFC1940, May 1996, 1234 . 1236 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1237 Hashing for Message Authentication", RFC 2104, 1238 DOI 10.17487/RFC2104, February 1997, 1239 . 1241 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1242 Defeating Denial of Service Attacks which employ IP Source 1243 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1244 May 2000, . 1246 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1247 DOI 10.17487/RFC4302, December 2005, 1248 . 1250 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1251 Co-existence Security Considerations", RFC 4942, 1252 DOI 10.17487/RFC4942, September 2007, 1253 . 1255 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1256 DOI 10.17487/RFC5308, October 2008, 1257 . 1259 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1260 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1261 . 1263 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1264 for Equal Cost Multipath Routing and Link Aggregation in 1265 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1266 . 1268 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1269 Routing Header for Source Routes with the Routing Protocol 1270 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1271 DOI 10.17487/RFC6554, March 2012, 1272 . 1274 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1275 Writing an IANA Considerations Section in RFCs", BCP 26, 1276 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1277 . 1279 Authors' Addresses 1281 Stefano Previdi 1282 Individual 1283 Italy 1285 Email: stefano@previdi.net 1287 Clarence Filsfils (editor) 1288 Cisco Systems, Inc. 1289 Brussels 1290 BE 1292 Email: cfilsfil@cisco.com 1294 John Leddy 1295 Comcast 1296 4100 East Dry Creek Road 1297 Centennial, CO 80122 1298 US 1300 Email: John_Leddy@comcast.com 1302 Satoru Matsushima 1303 Softbank 1305 Email: satoru.matsushima@g.softbank.co.jp 1307 Daniel Voyer (editor) 1308 Bell Canada 1310 Email: daniel.voyer@bell.ca