idnits 2.17.1 draft-ietf-6man-segment-routing-header-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 1, 2017) is 2640 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 409 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-09 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-07 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-08 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-08 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-10 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-06 Summary: 1 error (**), 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, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 5, 2017 B. Field 6 Comcast 7 I. Leung 8 Rogers Communications 9 J. Linkova 10 Google 11 E. Aries 12 Facebook 13 T. Kosugi 14 NTT 15 E. Vyncke 16 Cisco Systems, Inc. 17 D. Lebrun 18 Universite Catholique de Louvain 19 February 1, 2017 21 IPv6 Segment Routing Header (SRH) 22 draft-ietf-6man-segment-routing-header-05 24 Abstract 26 Segment Routing (SR) allows a node to steer a packet through a 27 controlled set of instructions, called segments, by prepending an SR 28 header to the packet. A segment can represent any instruction, 29 topological or service-based. SR allows to enforce a flow through 30 any path (topological, or application/service based) while 31 maintaining per-flow state only at the ingress node to the SR domain. 33 Segment Routing can be applied to the IPv6 data plane with the 34 addition of a new type of Routing Extension Header. This draft 35 describes the Segment Routing Extension Header Type and how it is 36 used by SR capable nodes. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on August 5, 2017. 61 Copyright Notice 63 Copyright (c) 2017 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 79 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2.1. Data Planes supporting Segment Routing . . . . . . . . . 4 81 2.2. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 4 82 2.2.1. SR Domain in a Service Provider Network . . . . . . . 5 83 2.2.2. SR Domain in a Overlay Network . . . . . . . . . . . 6 84 3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 7 85 3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 9 86 3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 10 87 3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 11 88 3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 11 89 3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 12 90 3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 13 91 3.2. SRH and RFC2460 behavior . . . . . . . . . . . . . . . . 14 92 4. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 14 93 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 14 94 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 15 95 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 16 96 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 5.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17 98 5.1.1. Source routing threats . . . . . . . . . . . . . . . 17 99 5.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 17 100 5.1.3. Service stealing threat . . . . . . . . . . . . . . . 18 101 5.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 18 102 5.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 18 103 5.2. Security fields in SRH . . . . . . . . . . . . . . . . . 19 104 5.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 20 105 5.2.2. Performance impact of HMAC . . . . . . . . . . . . . 21 106 5.2.3. Pre-shared key management . . . . . . . . . . . . . . 21 107 5.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 22 108 5.3.1. Nodes within the SR domain . . . . . . . . . . . . . 22 109 5.3.2. Nodes outside of the SR domain . . . . . . . . . . . 22 110 5.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 23 111 5.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 23 112 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 113 7. Manageability Considerations . . . . . . . . . . . . . . . . 24 114 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 115 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 117 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 118 10.2. Informative References . . . . . . . . . . . . . . . . . 25 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 121 1. Segment Routing Documents 123 Segment Routing terminology is defined in 124 [I-D.ietf-spring-segment-routing]. 126 Segment Routing use cases are described in [RFC7855] and 127 [I-D.ietf-spring-ipv6-use-cases]. 129 Segment Routing protocol extensions are defined in 130 [I-D.ietf-isis-segment-routing-extensions], and 131 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 133 2. Introduction 135 Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing], 136 allows a node to steer a packet through a controlled set of 137 instructions, called segments, by prepending an SR header to the 138 packet. A segment can represent any instruction, topological or 139 service-based. SR allows to enforce a flow through any path 140 (topological or service/application based) while maintaining per-flow 141 state only at the ingress node to the SR domain. Segments can be 142 derived from different components: IGP, BGP, Services, Contexts, 143 Locators, etc. The list of segment forming the path is called the 144 Segment List and is encoded in the packet header. 146 SR allows the use of strict and loose source based routing paradigms 147 without requiring any additional signaling protocols in the 148 infrastructure hence delivering an excellent scalability property. 150 The source based routing model described in 151 [I-D.ietf-spring-segment-routing] is inherited from the ones proposed 152 by [RFC1940] and [RFC2460]. The source based routing model offers 153 the support for explicit routing capability. 155 2.1. Data Planes supporting Segment Routing 157 Segment Routing (SR), can be instantiated over MPLS 158 ([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document 159 defines its instantiation over the IPv6 data-plane based on the use- 160 cases defined in [I-D.ietf-spring-ipv6-use-cases]. 162 This document defines a new type of Routing Header (originally 163 defined in [RFC2460]) called the Segment Routing Header (SRH) in 164 order to convey the Segment List in the packet header as defined in 165 [I-D.ietf-spring-segment-routing]. Mechanisms through which segment 166 are known and advertised are outside the scope of this document. 168 A segment is materialized by an IPv6 address. A segment identifies a 169 topological instruction or a service instruction. A segment can be 170 either: 172 o global: a global segment represents an instruction supported by 173 all nodes in the SR domain and it is instantiated through an IPv6 174 address globally known in the SR domain. 176 o local: a local segment represents an instruction supported only by 177 the node who originates it and it is instantiated through an IPv6 178 address that is known only by the local node. 180 2.2. Segment Routing (SR) Domain 182 We define the concept of the Segment Routing Domain (SR Domain) as 183 the set of nodes participating into the source based routing model. 184 These nodes may be connected to the same physical infrastructure 185 (e.g.: a Service Provider's network) as well as nodes remotely 186 connected to each other (e.g.: an enterprise VPN or an overlay). 188 A non-exhaustive list of examples of SR Domains is: 190 o The network of an operator, service provider, content provider, 191 enterprise including nodes, links and Autonomous Systems. 193 o A set of nodes connected as an overlay over one or more transit 194 providers. The overlay nodes exchange SR-enabled traffic with 195 segments belonging solely to the overlay routers (the SR domain). 196 None of the segments in the SR-enabled packets exchanged by the 197 overlay belong to the transit networks 199 The source based routing model through its instantiation of the 200 Segment Routing Header (SRH) defined in this document equally applies 201 to all the above examples. 203 It is assumed in this document that the SRH is added to the packet by 204 its source, consistently with the source routing model defined in 205 [RFC2460]. For example: 207 o At the node originating the packet (host, server). 209 o At the ingress node of an SR domain where the ingress node 210 receives an IPv6 packet and encapsulates it into an outer IPv6 211 header followed by a Segment Routing header. 213 2.2.1. SR Domain in a Service Provider Network 215 The following figure illustrates an SR domain consisting of an 216 operator's network infrastructure. 218 (-------------------------- Operator 1 -----------------------) 219 ( ) 220 ( (-----AS 1-----) (-------AS 2-------) (----AS 3-------) ) 221 ( ( ) ( ) ( ) ) 222 A1--(--(--11---13--14-)--(-21---22---23--24-)--(-31---32---34--)--)--Z1 223 ( ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) ) 224 A2--(--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--)--Z2 225 ( ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) ) 226 ( ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) ) 227 A3--(--(--15---17--18-)--(-25---26---27--28-)--(-35---36---38--)--)--Z3 228 ( ( ) ( ) ( ) ) 229 ( (--------------) (------------------) (---------------) ) 230 ( ) 231 (-------------------------------------------------------------) 233 Figure 1: Service Provider SR Domain 235 Figure 1 describes an operator network including several ASes and 236 delivering connectivity between endpoints. In this scenario, Segment 237 Routing is used within the operator networks and across the ASes 238 boundaries (all being under the control of the same operator). In 239 this case segment routing can be used in order to address use cases 240 such as end-to-end traffic engineering, fast re-route, egress peer 241 engineering, data-center traffic engineering as described in 242 [RFC7855], [I-D.ietf-spring-ipv6-use-cases] and 243 [I-D.ietf-spring-resiliency-use-cases]. 245 Typically, an IPv6 packet received at ingress (i.e.: from outside the 246 SR domain), is classified according to network operator policies and 247 such classification results into an outer header with an SRH applied 248 to the incoming packet. The SRH contains the list of segment 249 representing the path the packet must take inside the SR domain. 250 Thus, the SA of the packet is the ingress node, the DA (due to SRH 251 procedures described in Section 4) is set as the first segment of the 252 path and the last segment of the path is the egress node of the SR 253 domain. 255 The path may include intra-AS as well as inter-AS segments. It has 256 to be noted that all nodes within the SR domain are under control of 257 the same administration. When the packet reaches the egress point of 258 the SR domain, the outer header and its SRH are removed so that the 259 destination of the packet is unaware of the SR domain the packet has 260 traversed. 262 The outer header with the SRH is no different from any other 263 tunneling encapsulation mechanism and allows a network operator to 264 implement traffic engineering mechanisms so to efficiently steer 265 traffic across his infrastructure. 267 2.2.2. SR Domain in a Overlay Network 269 The following figure illustrates an SR domain consisting of an 270 overlay network over multiple operator's networks. 272 (--Operator 1---) (-----Operator 2-----) (--Operator 3---) 273 ( ) ( ) ( ) 274 A1--(--11---13--14--)--(--21---22---23--24--)--(-31---32---34--)--C1 275 ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) 276 A2--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--C2 277 ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) 278 ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) 279 A3--(--15---17--18--)--(--25---26---27--28--)--(-35---36---38--)--C3 280 ( ) ( | | | ) ( ) 281 (---------------) (--|----|---------|--) (---------------) 282 | | | 283 B1 B2 B3 285 Figure 2: Overlay SR Domain 287 Figure 2 describes an overlay consisting of nodes connected to three 288 different network operators and forming a single overlay network 289 where Segment routing packets are exchanged. 291 The overlay consists of nodes A1, A2, A3, B1, B2, B3, C1, C2 and C3. 292 These nodes are connected to their respective network operator and 293 form an overlay network. 295 Each node may originate packets with an SRH which contains, in the 296 segment list of the SRH or in the DA, segments identifying other 297 overlay nodes. This implies that packets with an SRH may traverse 298 operator's networks but, obviously, these SRHs cannot contain an 299 address/segment of the transit operators 1, 2 and 3. The SRH 300 originated by the overlay can only contain address/segment under the 301 administration of the overlay (e.g. address/segments supported by A1, 302 A2, A3, B1, B2, B3, C1,C2 or C3). 304 In this model, the operator network nodes are transit nodes and, 305 according to [RFC2460], MUST NOT inspect the routing extension header 306 since they are not the DA of the packet. 308 It is a common practice in operators networks to filter out, at 309 ingress, any packet whose DA is the address of an internal node and 310 it is also possible that an operator would filter out any packet 311 destined to an internal address and having an extension header in it. 313 This common practice does not impact the SR-enabled traffic between 314 the overlay nodes as the intermediate transit networks never see a 315 destination address belonging to their infrastructure. These SR- 316 enabled overlay packets will thus never be filtered by the transit 317 operators. 319 In all cases, transit packets (i.e.: packets whose DA is outside the 320 domain of the operator's network) will be forwarded accordingly 321 without introducing any security concern in the operator's network. 322 This is similar to tunneled packets. 324 3. Segment Routing Extension Header (SRH) 326 A new type of the Routing Header (originally defined in [RFC2460]) is 327 defined: the Segment Routing Header (SRH) which has a new Routing 328 Type, (suggested value 4) to be assigned by IANA. 330 The Segment Routing Header (SRH) is defined as follows: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | First Segment | Flags | RESERVED | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 | Segment List[0] (128 bits IPv6 address) | 341 | | 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 | | 346 ... 347 | | 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 | Segment List[n] (128 bits IPv6 address) | 352 | | 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 // // 356 // Optional Type Length Value objects (variable) // 357 // // 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 where: 362 o Next Header: 8-bit selector. Identifies the type of header 363 immediately following the SRH. 365 o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH 366 header in 8-octet units, not including the first 8 octets. 368 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 370 o Segments Left. Defined in [RFC2460], it contains the index, in 371 the Segment List, of the next segment to inspect. Segments Left 372 is decremented at each segment. 374 o First Segment: contains the index, in the Segment List, of the 375 first segment of the path which is in fact the last element of the 376 Segment List. 378 o Flags: 8 bits of flags. Following flags are defined: 380 0 1 2 3 4 5 6 7 381 +-+-+-+-+-+-+-+-+ 382 |U|P|O|A|H| U | 383 +-+-+-+-+-+-+-+-+ 385 U: Unused and for future use. SHOULD be unset on transmission 386 and MUST be ignored on receipt. 388 P-flag: Protected flag. Set when the packet has been rerouted 389 through FRR mechanism by an SR endpoint node. 391 O-flag: OAM flag. When set, it indicates that this packet is 392 an operations and management (OAM) packet. 394 A-flag: Alert flag. If present, it means important Type Length 395 Value (TLV) objects are present. See Section 3.1 for details 396 on TLVs objects. 398 H-flag: HMAC flag. If set, the HMAC TLV is present and is 399 encoded as the last TLV of the SRH. In other words, the last 400 36 octets of the SRH represent the HMAC information. See 401 Section 3.1.5 for details on the HMAC TLV. 403 o RESERVED: SHOULD be unset on transmission and MUST be ignored on 404 receipt. 406 o Segment List[n]: 128 bit IPv6 addresses representing the nth 407 segment in the Segment List. The Segment List is encoded starting 408 from the last segment of the path. I.e., the first element of the 409 segment list (Segment List [0]) contains the last segment of the 410 path while the last segment of the Segment List (Segment List[n]) 411 contains the first segment of the path. The index contained in 412 "Segments Left" identifies the current active segment. 414 o Type Length Value (TLV) are described in Section 3.1. 416 3.1. SRH TLVs 418 This section defines TLVs of the Segment Routing Header. 420 Type Length Value (TLV) contain optional information that may be used 421 by the node identified in the DA of the packet. It has to be noted 422 that the information carried in the TLVs is not intended to be used 423 by the routing layer. Typically, TLVs carry information that is 424 consumed by other components (e.g.: OAM) than the routing function. 426 Each TLV has its own length, format and semantic. The code-point 427 allocated (by IANA) to each TLV defines both the format and the 428 semantic of the information carried in the TLV. Multiple TLVs may be 429 encoded in the same SRH. 431 The "Length" field of the TLV is primarily used to skip the TLV while 432 inspecting the SRH in case the node doesn't support or recognize the 433 TLV codepoint. The "Length" defines the TLV length in octets and not 434 including the "Type" and "Length" fields. 436 The primary scope of TLVs is to give the receiver of the packet 437 information related to the source routed path (e.g.: where the packet 438 entered in the SR domain and where it is expected to exit). 440 Additional TLVs may be defined in the future. 442 3.1.1. Ingress Node TLV 444 The Ingress Node TLV is optional and identifies the node this packet 445 traversed when entered the SR domain. The Ingress Node TLV has 446 following format: 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type | Length | RESERVED | Flags | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 | Ingress Node (16 octets) | 455 | | 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 where: 461 o Type: to be assigned by IANA (suggested value 1). 463 o Length: 18. 465 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 466 ignored on receipt. 468 o Flags: 8 bits. No flags are defined in this document. 470 o Ingress Node: 128 bits. Defines the node where the packet is 471 expected to enter the SR domain. In the encapsulation case 472 described in Section 2.2.1, this information corresponds to the SA 473 of the encapsulating header. 475 3.1.2. Egress Node TLV 477 The Egress Node TLV is optional and identifies the node this packet 478 is expected to traverse when exiting the SR domain. The Egress Node 479 TLV has following format: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type | Length | RESERVED | Flags | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 | Egress Node (16 octets) | 488 | | 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 where: 494 o Type: to be assigned by IANA (suggested value 2). 496 o Length: 18. 498 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 499 ignored on receipt. 501 o Flags: 8 bits. No flags are defined in this document. 503 o Egress Node: 128 bits. Defines the node where the packet is 504 expected to exit the SR domain. In the encapsulation case 505 described in Section 2.2.1, this information corresponds to the 506 last segment of the SRH in the encapsulating header. 508 3.1.3. Opaque Container TLV 510 The Opaque Container TLV is optional and has the following format: 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Type | Length | RESERVED | Flags | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | | 518 | Opaque Container (16 octets) | 519 | | 520 | | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 where: 525 o Type: to be assigned by IANA (suggested value 3). 527 o Length: 18. 529 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 530 ignored on receipt. 532 o Flags: 8 bits. No flags are defined in this document. 534 o Opaque Container: 128 bits of opaque data not relevant for the 535 routing layer. Typically, this information is consumed by a non- 536 routing component of the node receiving the packet (i.e.: the node 537 in the DA). 539 3.1.4. Padding TLV 541 The Padding TLV is optional and with the purpose of aligning the SRH 542 on a 8 octet boundary. The Padding TLV has the following format: 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Type | Length | Padding (variable) | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 // Padding (variable) // 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 where: 554 o Type: to be assigned by IANA (suggested value 4). 556 o Length: 1 to 7 557 o Padding: from 1 to 7 octets of padding. Padding bits have no 558 semantic. They SHOULD be set to 0 on transmission and MUST be 559 ignored on receipt. 561 The following applies to the Padding TLV: 563 o Padding TLV is optional and MAY only appear once in the SRH. If 564 present, it MUST have a length between 1 and 7 octets. 566 o The Padding TLV is used in order to align the SRH total length on 567 the 8 octet boundary. 569 o When present, the Padding TLV MUST appear as the last TLV before 570 the HMAC TLV (if HMAC TLV is present). 572 o When present, the Padding TLV MUST have a length from 1 to 7 in 573 order to align the SRH total lenght on a 8-octet boundary. 575 o When a router inspecting the SRH encounters the Padding TLV, it 576 MUST assume that no other TLV (other than the HMAC) follow the 577 Padding TLV. 579 3.1.5. HMAC TLV 581 HMAC TLV is optional and contains the HMAC information. The HMAC TLV 582 has the following format: 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type | Length | RESERVED | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | HMAC Key ID (4 octets) | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | // 592 | HMAC (32 octets) // 593 | // 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 where: 598 o Type: to be assigned by IANA (suggested value 5). 600 o Length: 38. 602 o RESERVED: 2 octets. SHOULD be unset on transmission and MUST be 603 ignored on receipt. 605 o HMAC Key ID: 4 octets. 607 o HMAC: 32 octets. 609 o HMAC and HMAC Key ID usage is described in Section 5 611 The Following applies to the HMAC TLV: 613 o When present, the HMAC TLV MUST be encoded as the last TLV of the 614 SRH. 616 o If the HMAC TLV is present, the SRH H-Flag (Figure 4) MUST be set. 618 o When the H-flag is set in the SRH, the router inspecting the SRH 619 MUST find the HMAC TLV in the last 38 octets of the SRH. 621 3.2. SRH and RFC2460 behavior 623 The SRH being a new type of the Routing Header, it also has the same 624 properties: 626 SHOULD only appear once in the packet. 628 Only the router whose address is in the DA field of the packet 629 header MUST inspect the SRH. 631 Therefore, Segment Routing in IPv6 networks implies that the segment 632 identifier (i.e.: the IPv6 address of the segment) is moved into the 633 DA of the packet. 635 The DA of the packet changes at each segment termination/completion 636 and therefore the final DA of the packet MUST be encoded as the last 637 segment of the path. 639 4. SRH Procedures 641 In this section we describe the different procedures on the SRH. 643 4.1. Source SR Node 645 A Source SR Node can be any node originating an IPv6 packet with its 646 IPv6 and Segment Routing Headers. This include either: 648 A host originating an IPv6 packet. 650 An SR domain ingress router encapsulating a received IPv6 packet 651 into an outer IPv6 header followed by an SRH. 653 The mechanism through which a Segment List is derived is outside of 654 the scope of this document. As an example, the Segment List may be 655 obtained through: 657 Local path computation. 659 Local configuration. 661 Interaction with a centralized controller delivering the path. 663 Any other mechanism. 665 The following are the steps of the creation of the SRH: 667 Next Header and Hdr Ext Len fields are set according to [RFC2460]. 669 Routing Type field is set as TBD (to be allocated by IANA, 670 suggested value 4). 672 The Segment List is built with the FIRST segment of the path 673 encoded in the LAST element of the Segment List. Subsequent 674 segments are encoded on top of the first segment. Finally, the 675 LAST segment of the path is encoded in the FIRST element of the 676 Segment List. In other words, the Segment List is encoded in the 677 reverse order of the path. 679 The final DA of the packet is encoded as the last segment of the 680 path (encoded in the first element of the Segment List). 682 The DA of the packet is set with the value of the first segment 683 (found in the last element of the segment list). 685 The Segments Left field is set to n-1 where n is the number of 686 elements in the Segment List. 688 The First Segment field is set to n-1 where n is the number of 689 elements in the Segment List. 691 The packet is sent out towards the first segment (i.e.: 692 represented in the packet DA). 694 HMAC TLV may be set according to Section 5. 696 4.2. Transit Node 698 According to [RFC2460], the only node who is allowed to inspect the 699 Routing Extension Header (and therefore the SRH), is the node 700 corresponding to the DA of the packet. Any other transit node MUST 701 NOT inspect the underneath routing header and MUST forward the packet 702 towards the DA and according to the IPv6 routing table. 704 In the example case described in Section 2.2.2, when SR capable nodes 705 are connected through an overlay spanning multiple third-party 706 infrastructure, it is safe to send SRH packets (i.e.: packet having a 707 Segment Routing Header) between each other overlay/SR-capable nodes 708 as long as the segment list does not include any of the transit 709 provider nodes. In addition, as a generic security measure, any 710 service provider will block any packet destined to one of its 711 internal routers, especially if these packets have an extended header 712 in it. 714 4.3. SR Segment Endpoint Node 716 The SR segment endpoint node is the node whose address is in the DA. 717 The segment endpoint node inspects the SRH and does: 719 1. IF DA = myself (segment endpoint) 720 2. IF Segments Left > 0 THEN 721 decrement Segments Left 722 update DA with Segment List[Segments Left] 723 3. ELSE continue IPv6 processing of the packet 724 End of processing. 725 4. Forward the packet out 727 5. Security Considerations 729 This section analyzes the security threat model, the security issues 730 and proposed solutions related to the new Segment Routing Header. 732 The Segment Routing Header (SRH) is simply another type of the 733 routing header as described in RFC 2460 [RFC2460] and is: 735 o Added by an SR edge router when entering the segment routing 736 domain or by the originating host itself. The source host can 737 even be outside the SR domain; 739 o inspected and acted upon when reaching the destination address of 740 the IP header per RFC 2460 [RFC2460]. 742 Per RFC2460 [RFC2460], routers on the path that simply forward an 743 IPv6 packet (i.e. the IPv6 destination address is none of theirs) 744 will never inspect and process the content of the SRH. Routers whose 745 one interface IPv6 address equals the destination address field of 746 the IPv6 packet MUST parse the SRH and, if supported and if the local 747 configuration allows it, MUST act accordingly to the SRH content. 749 According to RFC2460 [RFC2460], the default behavior of a non SR- 750 capable router upon receipt of an IPv6 packet with SRH destined to an 751 address of its, is to: 753 o ignore the SRH completely if the Segment Left field is 0 and 754 proceed to process the next header in the IPv6 packet; 756 o discard the IPv6 packet if Segment Left field is greater than 0, 757 it MAY send a Parameter Problem ICMP message back to the Source 758 Address. 760 5.1. Threat model 762 5.1.1. Source routing threats 764 Using an SRH is similar to source routing, therefore it has some 765 well-known security issues as described in RFC4942 [RFC4942] section 766 2.1.1 and RFC5095 [RFC5095]: 768 o amplification attacks: where a packet could be forged in such a 769 way to cause looping among a set of SR-enabled routers causing 770 unnecessary traffic, hence a Denial of Service (DoS) against 771 bandwidth; 773 o reflection attack: where a hacker could force an intermediate node 774 to appear as the immediate attacker, hence hiding the real 775 attacker from naive forensic; 777 o bypass attack: where an intermediate node could be used as a 778 stepping stone (for example in a De-Militarized Zone) to attack 779 another host (for example in the datacenter or any back-end 780 server). 782 5.1.2. Applicability of RFC 5095 to SRH 784 First of all, the reader must remember this specific part of section 785 1 of RFC5095 [RFC5095], "A side effect is that this also eliminates 786 benign RH0 use-cases; however, such applications may be facilitated 787 by future Routing Header specifications.". In short, it is not 788 forbidden to create new secure type of Routing Header; for example, 789 RFC 6554 (RPL) [RFC6554] also creates a new Routing Header type for a 790 specific application confined in a single network. 792 In the segment routing architecture described in 793 [I-D.ietf-spring-segment-routing] there are basically two kinds of 794 nodes (routers and hosts): 796 o nodes within the SR domain, which is within one single 797 administrative domain, i.e., where all nodes are trusted anyway 798 else the damage caused by those nodes could be worse than 799 amplification attacks: traffic interception, man-in-the-middle 800 attacks, more server DoS by dropping packets, and so on. 802 o nodes outside of the SR domain, which is outside of the 803 administrative segment routing domain hence they cannot be trusted 804 because there is no physical security for those nodes, i.e., they 805 can be replaced by hostile nodes or can be coerced in wrong 806 behaviors. 808 The main use case for SR consists of the single administrative domain 809 where only trusted nodes with SR enabled and configured participate 810 in SR: this is the same model as in RFC6554 [RFC6554]. All non- 811 trusted nodes do not participate as either SR processing is not 812 enabled by default or because they only process SRH from nodes within 813 their domain. 815 Moreover, all SR nodes ignore SRH created by outsiders based on 816 topology information (received on a peering or internal interface) or 817 on presence and validity of the HMAC field. Therefore, if 818 intermediate nodes ONLY act on valid and authorized SRH (such as 819 within a single administrative domain), then there is no security 820 threat similar to RH-0. Hence, the RFC 5095 [RFC5095] attacks are 821 not applicable. 823 5.1.3. Service stealing threat 825 Segment routing is used for added value services, there is also a 826 need to prevent non-participating nodes to use those services; this 827 is called 'service stealing prevention'. 829 5.1.4. Topology disclosure 831 The SRH may also contains IPv6 addresses of some intermediate SR- 832 nodes in the path towards the destination, this obviously reveals 833 those addresses to the potentially hostile attackers if those 834 attackers are able to intercept packets containing SRH. On the other 835 hand, if the attacker can do a traceroute whose probes will be 836 forwarded along the SR path, then there is little learned by 837 intercepting the SRH itself. 839 5.1.5. ICMP Generation 841 Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e. 842 where the destination address is one of theirs) receive a Routing 843 Header with unsupported Routing Type, the required behavior is: 845 o If Segments Left is zero, the node must ignore the Routing header 846 and proceed to process the next header in the packet. 848 o If Segments Left is non-zero, the node must discard the packet and 849 send an ICMP Parameter Problem, Code 0, message to the packet's 850 Source Address, pointing to the unrecognized Routing Type. 852 This required behavior could be used by an attacker to force the 853 generation of ICMP message by any node. The attacker could send 854 packets with SRH (with Segment Left set to 0) destined to a node not 855 supporting SRH. Per RFC2460 [RFC2460], the destination node could 856 generate an ICMP message, causing a local CPU utilization and if the 857 source of the offending packet with SRH was spoofed could lead to a 858 reflection attack without any amplification. 860 It must be noted that this is a required behavior for any unsupported 861 Routing Type and not limited to SRH packets. So, it is not specific 862 to SRH and the usual rate limiting for ICMP generation is required 863 anyway for any IPv6 implementation and has been implemented and 864 deployed for many years. 866 5.2. Security fields in SRH 868 This section summarizes the use of specific fields in the SRH. They 869 are based on a key-hashed message authentication code (HMAC). 871 The security-related fields in the SRH are instantiated by the HMAC 872 TLV, containing: 874 o HMAC Key-id, 32 bits wide; 876 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 877 0). 879 The HMAC field is the output of the HMAC computation (per RFC 2104 880 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 881 the text which consists of the concatenation of: 883 o the source IPv6 address; 885 o First Segment field; 887 o an octet of bit flags; 889 o HMAC Key-id; 891 o all addresses in the Segment List. 893 The purpose of the HMAC TLV is to verify the validity, the integrity 894 and the authorization of the SRH itself. If an outsider of the SR 895 domain does not have access to a current pre-shared secret, then it 896 cannot compute the right HMAC field and the first SR router on the 897 path processing the SRH and configured to check the validity of the 898 HMAC will simply reject the packet. 900 The HMAC TLV is located at the end of the SRH simply because only the 901 router on the ingress of the SR domain needs to process it, then all 902 other SR nodes can ignore it (based on local policy) because they 903 trust the upstream router. This is to speed up forwarding operations 904 because SR routers which do not validate the SRH do not need to parse 905 the SRH until the end. 907 The HMAC Key-id field allows for the simultaneous existence of 908 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 909 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 910 has neither syntax nor semantic except as an index to the right 911 combination of pre-shared key and hash algorithm and except that a 912 value of 0 means that there is no HMAC field. Having an HMAC Key-id 913 field allows for pre-shared key roll-over when two pre-shared keys 914 are supported for a while when all SR nodes converged to a fresher 915 pre-shared key. It could also allow for interoperation among 916 different SR domains if allowed by local policy and assuming a 917 collision-free HMAC Key Id allocation. 919 When a specific SRH is linked to a time-related service (such as 920 turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are 921 identical, then it is important to refresh the shared-secret 922 frequently as the HMAC validity period expires only when the HMAC 923 Key-id and its associated shared-secret expires. 925 5.2.1. Selecting a hash algorithm 927 The HMAC field in the HMAC TLV is 256 bit wide. Therefore, the HMAC 928 MUST be based on a hash function whose output is at least 256 bits. 929 If the output of the hash function is 256, then this output is simply 930 inserted in the HMAC field. If the output of the hash function is 931 larger than 256 bits, then the output value is truncated to 256 by 932 taking the least-significant 256 bits and inserting them in the HMAC 933 field. 935 SRH implementations can support multiple hash functions but MUST 936 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 938 NOTE: SHA-1 is currently used by some early implementations used for 939 quick interoperations testing, the 160-bit hash value must then be 940 right-hand padded with 96 bits set to 0. The authors understand that 941 this is not secure but is ok for limited tests. 943 5.2.2. Performance impact of HMAC 945 While adding an HMAC to each and every SR packet increases the 946 security, it has a performance impact. Nevertheless, it must be 947 noted that: 949 o the HMAC field is used only when SRH is added by a device (such as 950 a home set-up box) which is outside of the segment routing domain. 951 If the SRH is added by a router in the trusted segment routing 952 domain, then, there is no need for an HMAC field, hence no 953 performance impact. 955 o when present, the HMAC field MUST only be checked and validated by 956 the first router of the segment routing domain, this router is 957 named 'validating SR router'. Downstream routers may not inspect 958 the HMAC field. 960 o this validating router can also have a cache of to improve the performance. It is not the 962 same use case as in IPsec where HMAC value was unique per packet, 963 in SRH, the HMAC value is unique per flow. 965 o Last point, hash functions such as SHA-2 have been optimized for 966 security and performance and there are multiple implementations 967 with good performance. 969 With the above points in mind, the performance impact of using HMAC 970 is minimized. 972 5.2.3. Pre-shared key management 974 The field HMAC Key-id allows for: 976 o key roll-over: when there is a need to change the key (the hash 977 pre-shared secret), then multiple pre-shared keys can be used 978 simultaneously. The validating routing can have a table of for the currently active and future 980 keys. 982 o different algorithms: by extending the previous table to , the validating router 984 can also support simultaneously several hash algorithms (see 985 section Section 5.2.1) 987 The pre-shared secret distribution can be done: 989 o in the configuration of the validating routers, either by static 990 configuration or any SDN oriented approach; 992 o dynamically using a trusted key distribution such as [RFC6407] 994 The intent of this document is NOT to define yet-another-key- 995 distribution-protocol. 997 5.3. Deployment Models 999 5.3.1. Nodes within the SR domain 1001 An SR domain is defined as a set of interconnected routers where all 1002 routers at the perimeter are configured to add and act on SRH. Some 1003 routers inside the SR domain can also act on SRH or simply forward 1004 IPv6 packets. 1006 The routers inside an SR domain can be trusted to generate SRH and to 1007 process SRH received on interfaces that are part of the SR domain. 1008 These nodes MUST drop all SRH packets received on an interface that 1009 is not part of the SR domain and containing an SRH whose HMAC field 1010 cannot be validated by local policies. This includes obviously 1011 packet with an SRH generated by a non-cooperative SR domain. 1013 If the validation fails, then these packets MUST be dropped, ICMP 1014 error messages (parameter problem) SHOULD be generated (but rate 1015 limited) and SHOULD be logged. 1017 5.3.2. Nodes outside of the SR domain 1019 Nodes outside of the SR domain cannot be trusted for physical 1020 security; hence, they need to request by some trusted means (outside 1021 of the scope of this document) a complete SRH for each new connection 1022 (i.e. new destination address). The received SRH MUST include an 1023 HMAC TLV which is computed correctly (see Section 5.2). 1025 When an outside node sends a packet with an SRH and towards an SR 1026 domain ingress node, the packet MUST contain the HMAC TLV (with a 1027 Key-id and HMAC fields) and the the destination address MUST be an 1028 address of an SR domain ingress node . 1030 The ingress SR router, i.e., the router with an interface address 1031 equals to the destination address, MUST verify the HMAC TLV. 1033 If the validation is successful, then the packet is simply forwarded 1034 as usual for an SR packet. As long as the packet travels within the 1035 SR domain, no further HMAC check needs to be done. Subsequent 1036 routers in the SR domain MAY verify the HMAC TLV when they process 1037 the SRH (i.e. when they are the destination). 1039 If the validation fails, then this packet MUST be dropped, an ICMP 1040 error message (parameter problem) SHOULD be generated (but rate 1041 limited) and SHOULD be logged. 1043 5.3.3. SR path exposure 1045 As the intermediate SR nodes addresses appears in the SRH, if this 1046 SRH is visible to an outsider then he/she could reuse this knowledge 1047 to launch an attack on the intermediate SR nodes or get some insider 1048 knowledge on the topology. This is especially applicable when the 1049 path between the source node and the first SR domain ingress router 1050 is on the public Internet. 1052 The first remark is to state that 'security by obscurity' is never 1053 enough; in other words, the security policy of the SR domain MUST 1054 assume that the internal topology and addressing is known by the 1055 attacker. A simple traceroute will also give the same information 1056 (with even more information as all intermediate nodes between SID 1057 will also be exposed). IPsec Encapsulating Security Payload 1058 [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP 1059 header must appear after any routing header (including SRH). 1061 To prevent a user to leverage the gained knowledge by intercepting 1062 SRH, it it recommended to apply an infrastructure Access Control List 1063 (iACL) at the edge of the SR domain. This iACL will drop all packets 1064 from outside the SR-domain whose destination is any address of any 1065 router inside the domain. This security policy should be tuned for 1066 local operations. 1068 5.3.4. Impact of BCP-38 1070 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 1071 whether the source address of packets received on an interface is 1072 valid for this interface. The use of loose source routing such as 1073 SRH forces packets to follow a path which differs from the expected 1074 routing. Therefore, if BCP-38 was implemented in all routers inside 1075 the SR domain, then SR packets could be received by an interface 1076 which is not expected one and the packets could be dropped. 1078 As an SR domain is usually a subset of one administrative domain, and 1079 as BCP-38 is only deployed at the ingress routers of this 1080 administrative domain and as packets arriving at those ingress 1081 routers have been normally forwarded using the normal routing 1082 information, then there is no reason why this ingress router should 1083 drop the SRH packet based on BCP-38. Routers inside the domain 1084 commonly do not apply BCP-38; so, this is not a problem. 1086 6. IANA Considerations 1088 This document makes the following registrations in the Internet 1089 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1090 maintained by IANA: 1092 Suggested Description Reference 1093 Value 1094 ---------------------------------------------------------- 1095 4 Segment Routing Header (SRH) This document 1097 In addition, this document request IANA to create and maintain a new 1098 Registry: "Segment Routing Header Type-Value Objects". The following 1099 code-points are requested from the registry: 1101 Registry: Segment Routing Header Type-Value Objects 1103 Suggested Description Reference 1104 Value 1105 ----------------------------------------------------- 1106 1 Ingress Node TLV This document 1107 2 Egress Node TLV This document 1108 3 Opaque Container TLV This document 1109 4 Padding TLV This document 1110 5 HMAC TLV This document 1112 7. Manageability Considerations 1114 TBD 1116 8. Contributors 1118 Dave Barach, John Leddy, John Brzozowski, Pierre Francois, Nagendra 1119 Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James 1120 Connolly, Aloys Augustin contributed to the content of this document. 1122 9. Acknowledgements 1124 The authors would like to thank Ole Troan, Bob Hinden, Fred Baker, 1125 Brian Carpenter, Alexandru Petrescu and Punit Kumar Jaiswal for their 1126 comments to this document. 1128 10. References 1130 10.1. Normative References 1132 [FIPS180-4] 1133 National Institute of Standards and Technology, "FIPS 1134 180-4 Secure Hash Standard (SHS)", March 2012, 1135 . 1138 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1139 Requirement Levels", BCP 14, RFC 2119, 1140 DOI 10.17487/RFC2119, March 1997, 1141 . 1143 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1144 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1145 December 1998, . 1147 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1148 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1149 . 1151 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1152 of Type 0 Routing Headers in IPv6", RFC 5095, 1153 DOI 10.17487/RFC5095, December 2007, 1154 . 1156 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1157 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1158 October 2011, . 1160 10.2. Informative References 1162 [I-D.ietf-isis-segment-routing-extensions] 1163 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1164 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 1165 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1166 segment-routing-extensions-09 (work in progress), October 1167 2016. 1169 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1170 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1171 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1172 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1173 segment-routing-extensions-07 (work in progress), October 1174 2016. 1176 [I-D.ietf-spring-ipv6-use-cases] 1177 Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and 1178 R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring- 1179 ipv6-use-cases-08 (work in progress), January 2017. 1181 [I-D.ietf-spring-resiliency-use-cases] 1182 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 1183 "Resiliency use cases in SPRING networks", draft-ietf- 1184 spring-resiliency-use-cases-08 (work in progress), October 1185 2016. 1187 [I-D.ietf-spring-segment-routing] 1188 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1189 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1190 spring-segment-routing-10 (work in progress), November 1191 2016. 1193 [I-D.ietf-spring-segment-routing-mpls] 1194 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1195 Litkowski, S., Horneffer, M., Shakir, R., 1196 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 1197 with MPLS data plane", draft-ietf-spring-segment-routing- 1198 mpls-06 (work in progress), January 2017. 1200 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1201 Zappala, "Source Demand Routing: Packet Format and 1202 Forwarding Specification (Version 1)", RFC 1940, 1203 DOI 10.17487/RFC1940, May 1996, 1204 . 1206 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1207 Hashing for Message Authentication", RFC 2104, 1208 DOI 10.17487/RFC2104, February 1997, 1209 . 1211 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1212 Defeating Denial of Service Attacks which employ IP Source 1213 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1214 May 2000, . 1216 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1217 Co-existence Security Considerations", RFC 4942, 1218 DOI 10.17487/RFC4942, September 2007, 1219 . 1221 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1222 Routing Header for Source Routes with the Routing Protocol 1223 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1224 DOI 10.17487/RFC6554, March 2012, 1225 . 1227 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1228 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1229 Packet Routing in Networking (SPRING) Problem Statement 1230 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1231 2016, . 1233 Authors' Addresses 1235 Stefano Previdi (editor) 1236 Cisco Systems, Inc. 1237 Via Del Serafico, 200 1238 Rome 00142 1239 Italy 1241 Email: sprevidi@cisco.com 1243 Clarence Filsfils 1244 Cisco Systems, Inc. 1245 Brussels 1246 BE 1248 Email: cfilsfil@cisco.com 1250 Brian Field 1251 Comcast 1252 4100 East Dry Creek Road 1253 Centennial, CO 80122 1254 US 1256 Email: Brian_Field@cable.comcast.com 1258 Ida Leung 1259 Rogers Communications 1260 8200 Dixie Road 1261 Brampton, ON L6T 0C1 1262 CA 1264 Email: Ida.Leung@rci.rogers.com 1265 Jen Linkova 1266 Google 1267 1600 Amphitheatre Parkway 1268 Mountain View, CA 94043 1269 US 1271 Email: furry@google.com 1273 Ebben Aries 1274 Facebook 1275 US 1277 Email: exa@fb.com 1279 Tomoya Kosugi 1280 NTT 1281 3-9-11, Midori-Cho Musashino-Shi, 1282 Tokyo 180-8585 1283 JP 1285 Email: kosugi.tomoya@lab.ntt.co.jp 1287 Eric Vyncke 1288 Cisco Systems, Inc. 1289 De Kleetlaann 6A 1290 Diegem 1831 1291 Belgium 1293 Email: evyncke@cisco.com 1295 David Lebrun 1296 Universite Catholique de Louvain 1297 Place Ste Barbe, 2 1298 Louvain-la-Neuve, 1348 1299 Belgium 1301 Email: david.lebrun@uclouvain.be