idnits 2.17.1 draft-ietf-6man-segment-routing-header-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 21, 2019) is 1792 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 217 -- Looks like a reference, but probably isn't: '8' on line 934 -- Looks like a reference, but probably isn't: '9' on line 934 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft D. Dukes, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: November 22, 2019 S. Previdi 6 Huawei 7 J. Leddy 8 Individual 9 S. Matsushima 10 Softbank 11 D. Voyer, Ed. 12 Bell Canada 13 May 21, 2019 15 IPv6 Segment Routing Header (SRH) 16 draft-ietf-6man-segment-routing-header-19 18 Abstract 20 Segment Routing can be applied to the IPv6 data plane using a new 21 type of Routing Extension Header. This document describes the 22 Segment Routing Extension Header and how it is used by Segment 23 Routing capable nodes. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 22, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Segment Routing Extension Header . . . . . . . . . . . . . . 4 62 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 7 64 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8 65 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11 67 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12 68 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12 69 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 12 70 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12 71 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 13 72 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 13 74 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID . . . . . 14 75 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 16 76 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 17 77 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 17 78 5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 17 79 5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 17 80 5.2. SR Domain as a single system with delegation among 81 components . . . . . . . . . . . . . . . . . . . . . . . 18 82 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 19 83 5.4. ICMP Error Processing . . . . . . . . . . . . . . . . . . 19 84 5.5. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 19 85 5.6. Other Deployments . . . . . . . . . . . . . . . . . . . . 20 86 6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 20 87 6.1. Abstract Representation of an SRH . . . . . . . . . . . . 20 88 6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 21 89 6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 21 90 6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 22 91 6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 22 92 6.3.3. Inter SR Domain Packet - Internal to External . . . . 22 93 6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 23 94 6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 23 95 6.6. Delegation of Function with HMAC Verification . . . . . . 23 96 6.6.1. SID List Verification . . . . . . . . . . . . . . . . 23 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 99 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 24 100 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 25 101 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 25 102 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 25 103 7.5. Applicability of AH . . . . . . . . . . . . . . . . . . . 26 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 105 8.1. Segment Routing Header Flags Register . . . . . . . . . . 27 106 8.2. Segment Routing Header TLVs Register . . . . . . . . . . 27 107 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 108 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 27 109 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 28 110 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 28 111 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 28 112 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 28 113 9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 28 114 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 115 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 116 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 117 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 118 12.2. Informative References . . . . . . . . . . . . . . . . . 30 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 121 1. Introduction 123 Segment Routing can be applied to the IPv6 data plane using a new 124 type of Routing Extension Header (SRH). This document describes the 125 Segment Routing Extension Header and how it is used by Segment 126 Routing capable nodes. 128 The Segment Routing Architecture [RFC8402] describes Segment Routing 129 and its instantiation in two data planes MPLS and IPv6. 131 The encoding of IPv6 segments in the Segment Routing Extension Header 132 is defined in this document. 134 Terminology used within this document is defined in detail in 135 [RFC8402]. Specifically, these terms: Segment Routing, SR Domain, 136 SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy. 138 1.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 2. Segment Routing Extension Header 148 Routing Headers are defined in [RFC8200]. The Segment Routing Header 149 has a new Routing Type (suggested value 4) to be assigned by IANA. 151 The Segment Routing Header (SRH) is defined as follows: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Last Entry | Flags | Tag | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 | Segment List[0] (128 bits IPv6 address) | 162 | | 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | 166 | | 167 ... 168 | | 169 | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 | Segment List[n] (128 bits IPv6 address) | 173 | | 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 // // 177 // Optional Type Length Value objects (variable) // 178 // // 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 where: 183 o Next Header: Defined in [RFC8200] Section 4.4 185 o Hdr Ext Len: Defined in [RFC8200] Section 4.4 187 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 189 o Segments Left: Defined in [RFC8200] Section 4.4 191 o Last Entry: contains the index (zero based), in the Segment List, 192 of the last element of the Segment List. 194 o Flags: 8 bits of flags. Section 8.1 creates an IANA registry for 195 new flags to be defined. The following flags are defined: 197 0 1 2 3 4 5 6 7 198 +-+-+-+-+-+-+-+-+ 199 |U U U U U U U U| 200 +-+-+-+-+-+-+-+-+ 202 U: Unused and for future use. MUST be 0 on transmission and 203 ignored on receipt. 205 o Tag: tag a packet as part of a class or group of packets, e.g., 206 packets sharing the same set of properties. When tag is not used 207 at source it MUST be set to zero on transmission. When tag is not 208 used during SRH Processing it SHOULD be ignored. Tag is not used 209 when processing the SID defined in Section 4.3.1. It may be used 210 when processing other SID types which are not defined in this 211 document. The allocation and use of tag is outside the scope of 212 this document. 214 o Segment List[n]: 128 bit IPv6 addresses representing the nth 215 segment in the Segment List. The Segment List is encoded starting 216 from the last segment of the SR Policy. I.e., the first element 217 of the segment list (Segment List [0]) contains the last segment 218 of the SR Policy, the second element contains the penultimate 219 segment of the SR Policy and so on. 221 o Type Length Value (TLV) are described in Section 2.1. 223 In the SRH, the Next Header, Hdr Ext Len, and Routing Type fields are 224 defined in Section 4.4 of [RFC8200] as not mutable. The Segments 225 Left field is defined as mutable in Section 4.4 of [RFC8200]. 227 Some of the other fields of the SRH change en route (i.e. they are 228 mutable). The SRH is processed as defined in Section 4.3 of this 229 document, and uniquely per SID type. The mutability of the remaining 230 fields in the SRH (Flags, Tag, Segment List, Optional TLVs) are 231 defined in that section, in the context of segment processing. 233 2.1. SRH TLVs 235 This section defines TLVs of the Segment Routing Header. 237 A TLV provides meta-data for segment processing. The only TLVs 238 defined in this document are the HMAC (Section 2.1.2) and PAD 239 (Section 2.1.1) TLVs. While processing the SID defined in 240 Section 4.3.1, all TLVs are ignored unless local configuration 241 indicates otherwise (Section 4.3.1.1.1). Thus, TLV and HMAC support 242 is optional for any implementation, however an implementation adding 243 or parsing TLVs MUST support PAD TLVs. Other documents may define 244 additional TLVs and processing rules for them. 246 TLVs are present when the Hdr Ext Len exceeds the Last Entry element 247 in the Segment List. 249 While processing TLVs at a segment endpoint, TLVs MUST be fully 250 contained within the SRH as determined by the Hdr Ext Len. Detection 251 of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an 252 ICMP Parameter Problem, Code 0, message to the Source Address, 253 pointing to the Hdr Ext Len field of the SRH, and the packet being 254 discarded. 256 An implementation MAY limit the number and/or length of TLVs it 257 processes based on local configuration. It MAY: 259 o Limit the number of consecutive Pad0 (Section 2.1.1.1) options to 260 1, if padding of more than one byte is required then PadN 261 (Section 2.1.1.2) should be used. 263 o Limit the length in PadN to 5. 265 o Limit the maximum number of non-Pad TLVs to be processed. 267 o Limit the maximum length of all TLVs to be processed. 269 The implementation MAY stop processing additional TLVs in the SRH 270 when these configured limits are exceeded. 272 0 1 273 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 275 | Type | Length | Variable length data 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 278 Type: An 8 bit value. Unrecognized Types MUST be ignored on receipt. 280 Length: The length of the Variable length data. 282 Variable length data: Length bytes of data that is specific to the 283 Type. 285 Type Length Value (TLV) contain OPTIONAL information that may be used 286 by the node identified in the Destination Address (DA) of the packet. 288 Each TLV has its own length, format and semantic. The code-point 289 allocated (by IANA) to each TLV Type defines both the format and the 290 semantic of the information carried in the TLV. Multiple TLVs may be 291 encoded in the same SRH. 293 TLVs may change en route at each segment. To identify when a TLV 294 type may change en route the most significant bit of the Type has the 295 following significance: 297 0: TLV data does not change en route 299 1: TLV data does change en route 301 All TLVs specify their alignment requirements using an xn+y format. 302 The xn+y format is defined as per [RFC8200]. The SR Source nodes use 303 the xn+y alignment requirements of TLVs and padding TLVs when 304 constructing an SRH. 306 The "Length" field of the TLV is used to skip the TLV while 307 inspecting the SRH in case the node doesn't support or recognize the 308 Type. The "Length" defines the TLV length in octets, not including 309 the "Type" and "Length" fields. 311 The following TLVs are defined in this document: 313 Padding TLVs 315 HMAC TLV 317 Additional TLVs may be defined in the future. 319 2.1.1. Padding TLVs 321 There are two types of padding TLVs, pad0 and padN, the following 322 applies to both: 324 Padding TLVs are used to pad the SRH to a multiple of 8 octets. 326 Padding TLVs are used for alignment. 328 Padding TLVs are ignored by a node processing the SRH TLV. 330 Multiple Padding TLVs MAY be used in one SRH 332 2.1.1.1. PAD0 334 Alignment requirement: none 336 0 1 2 3 4 5 6 7 337 +-+-+-+-+-+-+-+-+ 338 | Type | 339 +-+-+-+-+-+-+-+-+ 341 Type: to be assigned by IANA (Suggested value 0) 343 A single Pad0 TLV MUST be used when a single byte of padding is 344 required. If more than one byte of padding is required a Pad0 TLV 345 MUST NOT be used, the PadN TLV MUST be used. 347 2.1.1.2. PADN 349 Alignment requirement: none 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Length | Padding (variable) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 // Padding (variable) // 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Type: to be assigned by IANA (suggested value 1). 361 Length: 0 to 5 363 Padding: Length octets of padding. Padding bits have no 364 semantics. They MUST be set to 0 on transmission and ignored on 365 receipt. 367 The PadN TLV MUST be used when more than one byte of padding is 368 required. 370 2.1.2. HMAC TLV 372 Alignment requirement: 8n 374 The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL 375 and has the following format: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Type | Length | RESERVED | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | HMAC Key ID (4 octets) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | // 385 | HMAC (32 octets) // 386 | // 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 where: 391 o Type: to be assigned by IANA (suggested value 5). 393 o Length: 38. 395 o RESERVED: 2 octets. MUST be 0 on transmission and ignored on 396 receipt. 398 o HMAC Key ID: A 4 octet opaque number which uniquely identifies the 399 pre-shared key and algorithm used to generate the HMAC. If 0, the 400 HMAC is not included. 402 o HMAC: 32 octets of keyed HMAC, not present if Key ID is 0. 404 The HMAC TLV is used to verify the source of a packet is permitted to 405 use the current segment in the destination address of the packet, and 406 ensure the segment list is not modified in transit. 408 2.1.2.1. HMAC Generation and Verification 410 Local configuration determines when to check for an HMAC and 411 potentially provides an alternate composition of Text, and a 412 requirement on where the HMAC TLV must appear (e.g. first TLV), and 413 whether or not to verify the destination address is equal to the 414 current segment. This local configuration is outside the scope of 415 this document. It may be based on the active segment at an SR 416 Segment endpoint node, the result of an ACL that considers incoming 417 interface, HMAC Key ID, or other packet fields. 419 An implementation that supports the generation and verification of 420 the HMAC SHOULD support the following default behavior as defined in 421 the remainder of this section. 423 The HMAC verification begins by checking the current segment is equal 424 to the destination address of the IPv6 header, i.e. destination 425 address is equal to Segment List [Segments Left] and Segments Left is 426 less than or equal to Last Segment+1. 428 The HMAC field is the output of the HMAC computation as defined in 429 [RFC2104], using: 431 o key: the pre-shared key identified by HMAC Key ID 433 o HMAC algorithm: identified by the HMAC Key ID 435 o Text: a concatenation of the following fields from the IPv6 header 436 and the SRH, as it would be received at the node verifying the 437 HMAC: 439 * IPv6 header: source address (16 octets) 441 * SRH: Last Entry (1 octet) 443 * SRH: Flags (1 octet) 445 * SRH: HMAC Key-id (4 octets) 447 * SRH: all addresses in the Segment List (variable octets) 449 The HMAC digest is truncated to 32 octets and placed in the HMAC 450 field of the HMAC TLV. 452 For HMAC algorithms producing digests less than 32 octets, the digest 453 is placed in the lowest order octets of the HMAC field. Remaining 454 octets MUST be set to zero. 456 If HMAC verification is successful, the packet is forwarded to the 457 next segment. 459 If HMAC verification fails, an ICMP error message (parameter problem, 460 error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate 461 limited) and SHOULD be logged. 463 2.1.2.2. HMAC Pre-Shared Key Algorithm 465 The HMAC Key ID field allows for the simultaneous existence of 466 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 467 well as pre-shared keys. 469 The HMAC Key ID field is opaque, i.e., it has neither syntax nor 470 semantic except as an identifier of the right combination of pre- 471 shared key and hash algorithm, and except that a value of 0 means 472 that there is no HMAC field. 474 At the HMAC TLV verification node the Key ID uniquely identifies the 475 pre-shared key and HMAC algorithm. 477 At the HMAC TLV generating node the Key ID and destination address 478 uniquely identify the pre-shared key and HMAC algorithm. Utilizing 479 the destination address with the Key ID allows for overlapping key 480 IDs amongst different HMAC verification nodes. The Text for the HMAC 481 computation is set to the IPv6 header fields and SRH fields as they 482 would appear at the verification node, not necessarily the same as 483 the source node sending a packet with the HMAC TLV. 485 Pre-shared key roll-over is supported by having two key IDs in use 486 while the HMAC TLV generating node and verifying node converge to a 487 new key. 489 SRH implementations can support multiple hash functions but MUST 490 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 492 The selection of pre-shared key and algorithm, and their distribution 493 is outside the scope of this document, some options may include: 495 o in the configuration of the HMAC generating or verifying nodes, 496 either by static configuration or any SDN oriented approach 498 o dynamically using a trusted key distribution protocol such as 499 [RFC6407] 501 3. SR Nodes 503 There are different types of nodes that may be involved in segment 504 routing networks: source SR nodes originate packets with a segment in 505 the destination address of the IPv6 header, transit nodes that 506 forward packets destined to a remote segment, and SR segment endpoint 507 nodes that process a local segment in the destination address of an 508 IPv6 header. 510 3.1. Source SR Node 512 A Source SR Node is any node that originates an IPv6 packet with a 513 segment (i.e. SRv6 SID) in the destination address of the IPv6 514 header. The packet leaving the source SR Node may or may not contain 515 an SRH. This includes either: 517 A host originating an IPv6 packet. 519 An SR domain ingress router encapsulating a received packet in an 520 outer IPv6 header, followed by an optional SRH. 522 The mechanism through which a segment in the destination address of 523 the IPv6 header and the Segment List in the SRH, is derived is 524 outside the scope of this document. 526 3.2. Transit Node 528 A transit node is any node forwarding an IPv6 packet where the 529 destination address of that packet is not locally configured as a 530 segment nor a local interface. A transit node is not required to be 531 capable of processing a segment nor SRH. 533 3.3. SR Segment Endpoint Node 535 A SR segment endpoint node is any node receiving an IPv6 packet where 536 the destination address of that packet is locally configured as a 537 segment or local interface. 539 4. Packet Processing 541 This section describes SRv6 packet processing at the SR source, 542 Transit and SR segment endpoint nodes. 544 4.1. Source SR Node 546 A Source node steers a packet into an SR Policy. If the SR Policy 547 results in a segment list containing a single segment, and there is 548 no need to add information to SRH flag or TLV, the DA is set to the 549 single segment list entry and the SRH MAY be omitted. 551 When needed, the SRH is created as follows: 553 Next Header and Hdr Ext Len fields are set as specified in 554 [RFC8200]. 556 Routing Type field is set as TBD (to be allocated by IANA, 557 suggested value 4). 559 The DA of the packet is set with the value of the first segment. 561 The first element of the SRH Segment List is the ultimate segment. 562 The second element is the penultimate segment and so on. 564 The Segments Left field is set to n-1 where n is the number of 565 elements in the SR Policy. 567 The Last Entry field is set to n-1 where n is the number of 568 elements in the SR Policy. 570 HMAC TLV may be set according to Section 7. 572 The packet is forwarded toward the packet's Destination Address 573 (the first segment). 575 4.1.1. Reduced SRH 577 When a source does not require the entire SID list to be preserved in 578 the SRH, a reduced SRH may be used. 580 A reduced SRH does not contain the first segment of the related SR 581 Policy (the first segment is the one already in the DA of the IPv6 582 header), and the Last Entry field is set to n-2 where n is the number 583 of elements in the SR Policy. 585 4.2. Transit Node 587 As specified in [RFC8200], the only node allowed to inspect the 588 Routing Extension Header (and therefore the SRH), is the node 589 corresponding to the DA of the packet. Any other transit node MUST 590 NOT inspect the underneath routing header and MUST forward the packet 591 toward the DA according to its IPv6 routing table. 593 When a SID is in the destination address of an IPv6 header of a 594 packet, it's routed through an IPv6 network as an IPv6 address. 595 SIDs, or the prefix(es) covering SIDs, and their reachability may be 596 distributed by means outside the scope of this document. For 597 example, [RFC5308] or [RFC5340] may be used to advertise a prefix 598 covering the SIDs on a node. 600 4.3. SR Segment Endpoint Node 602 Without constraining the details of an implementation, the SR segment 603 endpoint node creates Forwarding Information Base (FIB) entries for 604 its local SIDs. 606 When an SRv6-capable node receives an IPv6 packet, it performs a 607 longest-prefix-match lookup on the packets destination address. This 608 lookup can return any of the following: 610 A FIB entry that represents a locally instantiated SRv6 SID 611 A FIB entry that represents a local interface, not locally 612 instantiated as an SRv6 SID 613 A FIB entry that represents a non-local route 614 No Match 616 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID 618 This document, and section, defines a single SRv6 SID. Future 619 documents may define additional SRv6 SIDs. In which case, the entire 620 content of this section will be defined in that document. 622 If the FIB entry represents a locally instantiated SRv6 SID, process 623 the next header chain of the IPv6 header as defined in section 4 of 624 [RFC8200]. Section 4.3.1.1 describes how to process an SRH, 625 Section 4.3.1.2 describes how to process an upper layer header or no 626 next header. 628 Processing this SID type modifies the Segments Left and, if 629 configured to process TLVs, it may modify the "variable length data" 630 of TLV types that change en route. Therefore Segments Left is 631 mutable and TLVs that change en route are mutable. The remainder of 632 the SRH (Flags, Tag, Segment List, and TLVs that do not change en 633 route) are immutable while processing this SID type. 635 4.3.1.1. SRH Processing 636 S01. When an SRH is processed { 637 S02. If Segments Left is equal to zero { 638 S03. Proceed to process the next header in the packet, 639 whose type is identified by the Next Header field in 640 the Routing header. 641 S04. } 642 S05. Else { 643 S06. If local configuration requires TLV processing { 644 S07. Perform TLV processing (see TLV Processing) 645 S08. } 646 S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1 647 S10. If ((Last Entry > max_last_entry) or 648 S11. (Segments Left is greater than (Last Entry+1)) { 649 S12. Send an ICMP Parameter Problem, Code 0, message to 650 the Source Address, pointing to the Segments Left 651 field, and discard the packet. 652 S13. } 653 S14. Else { 654 S15. Decrement Segments Left by 1. 655 S16. Copy Segment List[Segments Left] from the SRH to the 656 destination address of the IPv6 header. 657 S17. If the IPv6 Hop Limit is less than or equal to 1 { 658 S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in 659 Transit message to the Source Address and discard 660 the packet. 661 S19. } 662 S20. Else { 663 S21. Decrement the Hop Limit by 1 664 S22. Resubmit the packet to the IPv6 module for transmission 665 to the new destination. 666 S23. } 667 S24. } 668 S25. } 669 S26. } 671 4.3.1.1.1. TLV Processing 673 Local configuration determines how TLVs are to be processed when the 674 Active Segment is a local SID type defined in this document. The 675 definition of local configuration is outside the scope of this 676 document. 678 For illustration purpose only, two example local configurations that 679 may be associated with a SID are provided below. 681 Example 1: 682 For any packet received from interface I2 683 Skip TLV processing 685 Example 2: 686 For any packet received from interface I1 687 If first TLV is HMAC { 688 Process the HMAC TLV 689 } 690 Else { 691 Discard the packet 692 } 694 4.3.1.2. Upper-layer Header or No Next Header 696 When processing the Upper-layer header of a packet matching a FIB 697 entry locally instantiated as an SRv6 SID type defined in this 698 document. 700 IF (Upper-layer Header is IPv4 or IPv6) and 701 local configuration permits { 702 Perform IPv6 decapsulation 703 Resubmit the decapsulated packet to the IPv4 or IPv6 module 704 } 705 ELSE { 706 Send an ICMP parameter problem message to the Source Address and 707 discard the packet. Error code (TBD by IANA) "SR Upper-layer 708 Header Error", pointer set to the offset of the upper-layer 709 header. 710 } 712 A unique error code allows an SR Source node to recognize an error in 713 SID processing at an endpoint. 715 4.3.2. FIB Entry is a Local Interface 717 If the FIB entry represents a local interface, not locally 718 instantiated as an SRv6 SID, the SRH is processed as follows: 720 If Segments Left is zero, the node must ignore the Routing header 721 and proceed to process the next header in the packet, whose type 722 is identified by the Next Header field in the Routing Header. 724 If Segments Left is non-zero, the node must discard the packet and 725 send an ICMP Parameter Problem, Code 0, message to the packet's 726 Source Address, pointing to the unrecognized Routing Type. 728 4.3.3. FIB Entry Is A Non-Local Route 730 Processing is not changed by this document. 732 4.3.4. FIB Entry Is A No Match 734 Processing is not changed by this document. 736 5. Intra SR Domain Deployment Model 738 The use of the SIDs exclusively within the SR Domain and solely for 739 packets of the SR Domain is an important deployment model. 741 This enables the SR Domain to act as a single routing system. 743 This section covers: 745 o securing the SR Domain from external attempt to use its SIDs 747 o SR Domain as a single system with delegation between components 749 o handling packets of the SR Domain 751 5.1. Securing the SR Domain 753 Nodes outside the SR Domain are not trusted: they cannot directly use 754 the SID's of the domain. This is enforced by two levels of access 755 control lists: 757 1. Any packet entering the SR Domain and destined to a SID within 758 the SR Domain is dropped. This may be realized with the 759 following logic, other methods with equivalent outcome are 760 considered compliant: 762 * allocate all the SID's from a block S/s 764 * configure each external interface of each edge node of the 765 domain with an inbound infrastructure access list (IACL) which 766 drops any incoming packet with a destination address in S/s 768 * Failure to implement this method of ingress filtering exposes 769 the SR Domain to source routing attacks as described and 770 referenced in [RFC5095] 772 2. The distributed protection in #1 is complemented with per node 773 protection, dropping packets to SIDs from source addresses 774 outside the SR Domain. This may be realized with the following 775 logic, other methods with equivalent outcome are considered 776 compliant: 778 * assign all interface addresses from prefix A/a 780 * at node k, all SIDs local to k are assigned from prefix Sk/sk 782 * configure each internal interface of each SR node k in the SR 783 Domain with an inbound IACL which drops any incoming packet 784 with a destination address in Sk/sk if the source address is 785 not in A/a. 787 5.2. SR Domain as a single system with delegation among components 789 All intra SR Domain packets are of the SR Domain. The IPv6 header is 790 originated by a node of the SR Domain, and is destined to a node of 791 the SR Domain. 793 All inter domain packets are encapsulated for the part of the packet 794 journey that is within the SR Domain. The outer IPv6 header is 795 originated by a node of the SR Domain, and is destined to a node of 796 the SR Domain. 798 As a consequence, any packet within the SR Domain is of the SR 799 Domain. 801 The SR Domain is a system in which the operator may want to 802 distribute or delegate different operations of the outer most header 803 to different nodes within the system. 805 An operator of an SR domain may choose to delegate SRH addition to a 806 host node within the SR domain, and validation of the contents of any 807 SRH to a more trusted router or switch attached to the host. 808 Consider a top of rack switch (T) connected to host (H) via interface 809 (I). H receives an SRH (SRH1) with a computed HMAC via some SDN 810 method outside the scope of this document. H classifies traffic it 811 sources and adds SRH1 to traffic requiring a specific SLA. T is 812 configured with an IACL on I requiring verification of the SRH for 813 any packet destined to the SID block of the SR Domain (S/s). T 814 checks and verifies that SRH1 is valid, contains an HMAC TLV and 815 verifies the HMAC. 817 An operator of the SR Domain may choose to have all segments in the 818 SR Domain verify the HMAC. This mechanism would verify that the SRH 819 segment list is not modified while traversing the SR Domain. 821 5.3. MTU Considerations 823 Within the SR Domain, well known mitigation techniques are 824 RECOMMENDED, such as deploying a greater MTU value within the SR 825 Domain than at the ingress edges. 827 5.4. ICMP Error Processing 829 ICMP error packets generated within the SR Domain are sent to source 830 nodes within the SR Domain. The invoking packet in the ICMP error 831 message may contain an SRH. Since the destination address of a 832 packet with an SRH changes as each segment is processed, it may not 833 be the destination used by the socket or application that generated 834 the invoking packet. 836 For the source of an invoking packet to process the ICMP error 837 message, the correct destination address must be determined. The 838 following logic is used to determine the destination address for use 839 by protocol error handlers. 841 o Walk all extension headers of the invoking IPv6 packet to the 842 routing extension header preceding the upper layer header. 844 * If routing header is type 4 (SRH) 846 + Use the 0th segment in the segment list as the destination 847 address of the invoking packet. 849 ICMP errors are then processed by upper layer transports as defined 850 in [RFC4443]. 852 For IP packets encapsulated in an outer IPv6 header, ICMP error 853 handling is as defined in [RFC2473]. 855 5.5. Load Balancing and ECMP 857 For any inter domain packet, the SR Source node MUST impose a flow 858 label computed based on the inner packet. The computation of the 859 flow label is as recommended in [RFC6438] for the sending Tunnel End 860 Point. 862 For any intra domain packet, the SR Source node SHOULD impose a flow 863 label computed as described in [RFC6437] to assist ECMP load 864 balancing at transit nodes incapable of computing a 5-tuple beyond 865 the SRH. 867 At any transit node within an SR domain, the flow label MUST be used 868 as defined in [RFC6438] to calculate the ECMP hash toward the 869 destination address. If flow label is not used, the transit node 870 would likely hash all packets between a pair of SR Edge nodes to the 871 same link. 873 At an SR segment endpoint node, the flow label MUST be used as 874 defined in [RFC6438] to calculate any ECMP hash used to forward the 875 processed packet to the next segment. 877 5.6. Other Deployments 879 Other deployment models and their implications on security, MTU, 880 HMAC, ICMP error processing and interaction with other extension 881 headers are outside the scope of this document. 883 6. Illustrations 885 This section provides illustrations of SRv6 packet processing at SR 886 source, transit and SR segment endpoint nodes. 888 6.1. Abstract Representation of an SRH 890 For a node k, its IPv6 address is represented as Ak, its SRv6 SID is 891 represented as Sk. 893 IPv6 headers are represented as the tuple of (source, destination). 894 For example, a packet with source address A1 and destination address 895 A2 is represented as (A1,A2). The payload of the packet is omitted. 897 An SR Policy is a list of segments. A list of segments is 898 represented as where S1 is the first SID to visit, S2 is 899 the second SID to visit and S3 is the last SID to visit. 901 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 903 o Source Address is SA, Destination Addresses is DA, and next-header 904 is SRH. 906 o SRH with SID list with SegmentsLeft = SL. 908 o Note the difference between the <> and () symbols. 909 represents a SID list where the leftmost segment is the first 910 segment. Whereas, (S3, S2, S1; SL) represents the same SID list 911 but encoded in the SRH Segment List format where the leftmost 912 segment is the last segment. When referring to an SR policy in a 913 high-level use-case, it is simpler to use the 914 notation. When referring to an illustration of detailed behavior, 915 the (S3, S2, S1; SL) notation is more convenient. 917 At its SR Policy headend, the Segment List results in SRH 918 (S3,S2,S1; SL=2) represented fully as: 920 Segments Left=2 921 Last Entry=2 922 Flags=0 923 Tag=0 924 Segment List[0]=S3 925 Segment List[1]=S2 926 Segment List[2]=S1 928 6.2. Example Topology 930 The following topology is used in examples below: 932 + * * * * * * * * * * * * * * * * * * * * + 934 * [8] [9] * 935 | | 936 * | | * 937 [1]----[3]--------[5]----------------[6]---------[4]---[2] 938 * | | * 939 | | 940 * | | * 941 +--------[7]-------+ 942 * * 944 + * * * * * * * SR Domain * * * * * * * + 946 Figure 3 948 o 3 and 4 are SR Domain edge routers 950 o 5, 6, and 7 are all SR Domain routers 952 o 8 and 9 are hosts within the SR Domain 954 o 1 and 2 are hosts outside the SR Domain 956 o The SR domain is secured as per Section 5.1 and no external packet 957 can enter the domain with a destination address equal to a segment 958 of the domain. 960 6.3. Source SR Node 961 6.3.1. Intra SR Domain Packet 963 When host 8 sends a packet to host 9 via an SR Policy the 964 packet is 966 P1: (A8,S7)(A9,S7; SL=1) 968 6.3.1.1. Reduced Variant 970 When host 8 sends a packet to host 9 via an SR Policy and it 971 wants to use a reduced SRH, the packet is 973 P2: (A8,S7)(A9; SL=1) 975 6.3.2. Inter SR Domain Packet - Transit 977 When host 1 sends a packet to host 2, the packet is 979 P3: (A1,A2) 981 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 982 egress router 4 via an SR Policy . Router 3 encapsulates the 983 received packet P3 in an outer header with an SRH. The packet is 985 P4: (A3, S7)(S4, S7; SL=1)(A1, A2) 987 If the SR Policy contains only one segment (the egress router 4), the 988 ingress Router 3 encapsulates P3 into an outer header (A3, S4). The 989 packet is 991 P5: (A3, S4)(A1, A2) 993 6.3.2.1. Reduced Variant 995 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 996 egress router 4 via an SR Policy . If router 3 wants to use 997 a reduced SRH, Router 3 encapsulates the received packet P3 in an 998 outer header with a reduced SRH. The packet is 1000 P6: (A3, S7)(S4; SL=1)(A1, A2) 1002 6.3.3. Inter SR Domain Packet - Internal to External 1004 When host 8 sends a packet to host 1, the packet is encapsulated for 1005 the portion of its journey within the SR Domain. From 8 to 3 the 1006 packet is 1008 P7: (A8,S3)(A8,A1) 1009 In the opposite direction, the packet generated from 1 to 8 is 1011 P8: (A1,A8) 1013 At node 3 P8 is encapsulated for the portion of its journey within 1014 the SR domain, with the outer header destined to segment S8. 1015 Resulting in 1017 P9: (A3,S8)(A1,A8) 1019 At node 8 the outer IPv6 header is removed by S8 processing, then 1020 processed again when received by A8. 1022 6.4. Transit Node 1024 Nodes 5 acts as transit nodes for packet P1, and sends packet 1026 P1: (A8,S7)(A9,S7;SL=1) 1028 on the interface toward node 7. 1030 6.5. SR Segment Endpoint Node 1032 Node 7 receives packet P1 and, using the logic in Section 4.3.1, 1033 sends packet 1035 P7: (A8,A9)(A9,S7; SL=0) 1037 on the interface toward router 6. 1039 6.6. Delegation of Function with HMAC Verification 1041 This section describes how a function may be delegated within the SR 1042 Domain to non SR source nodes. In the following sections consider a 1043 host 8 connected to a top of rack 5. 1045 6.6.1. SID List Verification 1047 An operator may prefer to add the SRH at source 8, while 5 verifies 1048 the SID list is valid. 1050 For illustration purpose, an SDN controller provides 8 an SRH 1051 terminating at node 9, with segment list , and HMAC TLV 1052 computed for the SRH. The HMAC key is shared with 5, node 8 does not 1053 know the key. Node 5 is configured with an IACL applied to the 1054 interface connected to 8, requiring HMAC verification for any packet 1055 destined to S/s. 1057 Node 8 originates packets with the received SRH with HMAC TLV. 1059 P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC) 1061 Node 5 receives and verifies the HMAC for the SRH, then forwards the 1062 packet to the next segment 1064 P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC) 1066 Node 6 receives 1068 P17:(A8,S6)(A9,S6,S7,S5;SL=1;HMAC) 1070 Node 9 receives 1072 P18:(A8,A9)(A9,S6,S7,S5;SL=0;HMAC) 1074 This use of an HMAC is particularly valuable within an enterprise 1075 based SR Domain [SRN]. 1077 7. Security Considerations 1079 This section reviews security considerations related to the SRH, 1080 given the SRH processing and deployment models discussed in this 1081 document. 1083 As described in Section 5, it is necessary to filter packets ingress 1084 to the SR Domain, destined to SIDs within the SR Domain (i.e., 1085 bearing a SID in the destination address). This ingress filtering is 1086 via an IACL at SR Domain ingress border nodes. Additional protection 1087 is applied via an IACL at each SR Segment Endpoint node, filtering 1088 packets not from within the SR Domain, destined to SIDs in the SR 1089 Domain. ACLs are easily supported for small numbers of prefixes, 1090 making summarization important, and when the prefixes requiring 1091 filtering is kept to a seldom changing set. 1093 Additionally, ingress filtering of IPv6 source addresses as 1094 recommended in BCP38 SHOULD be used. 1096 7.1. Source Routing Attacks 1098 [RFC5095] deprecates the Type 0 Routing header due to a number of 1099 significant attacks that are referenced in that document. Such 1100 attacks include bypassing filtering devices, reaching otherwise 1101 unreachable Internet systems, network topology discovery, bandwidth 1102 exhaustion, and defeating anycast. 1104 Because this document specifies that the SRH is for use within an SR 1105 domain protected by ingress filtering via IACLs; such attacks cannot 1106 be mounted from outside an SR Domain. As specified in this document, 1107 SR Domain ingress edge nodes drop packets entering the SR Domain 1108 destined to segments within the SR Domain. 1110 Additionally, this document specifies the use of IACL on SR Segment 1111 Endpoint nodes within the SR Domain to limit the source addresses 1112 permitted to send packets to a SID in the SR Domain. 1114 Such attacks may, however, be mounted from within the SR Domain, from 1115 nodes permitted to source traffic to SIDs in the domain. As such, 1116 these attacks and other known attacks on an IP network (e.g. DOS/ 1117 DDOS, topology discovery, man-in-the-middle, traffic interception/ 1118 siphoning), can occur from compromised nodes within an SR Domain. 1120 7.2. Service Theft 1122 Service theft is defined as the use of a service offered by the SR 1123 Domain by a node not authorized to use the service. 1125 Service theft is not a concern within the SR Domain as all SR Source 1126 nodes and SR segment endpoint nodes within the domain are able to 1127 utilize the services of the Domain. If a node outside the SR Domain 1128 learns of segments or a topological service within the SR domain, 1129 IACL filtering denies access to those segments. 1131 7.3. Topology Disclosure 1133 The SRH is unencrypted and may contain SIDs of some intermediate SR- 1134 nodes in the path towards the destination within the SR Domain. If 1135 packets can be snooped within the SR Domain, the SRH may reveal 1136 topology, traffic flows, and service usage. 1138 This is applicable within an SR Domain but the disclosure is less 1139 relevant as an attacker has other means of learning topology, flows, 1140 and service usage. 1142 7.4. ICMP Generation 1144 The generation of ICMPv6 error messages may be used to attempt 1145 denial-of-service attacks by sending an error-causing destination 1146 address or SRH in back-to-back packets. An implementation that 1147 correctly follows Section 2.4 of [RFC4443] would be protected by the 1148 ICMPv6 rate-limiting mechanism. 1150 7.5. Applicability of AH 1152 The SR Domain is a trusted domain, as defined in [RFC8402] Section 2 1153 and Section 8.2. The SR Source is trusted to add an SRH (optionally 1154 verified via the HMAC TLV in this document), and segments advertised 1155 within the domain are trusted to be accurate and advertised by 1156 trusted sources via a secure control plane. As such the SR Domain 1157 does not rely on the Authentication Header (AH) as defined in 1158 [RFC4302] to secure the SRH. 1160 The use of SRH with AH by an SR source node, and processing at a SR 1161 segment endpoint node, is not defined in this document. Future 1162 documents may define use of SRH with AH and its processing. 1164 8. IANA Considerations 1166 This document makes the following registrations in the Internet 1167 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1168 maintained by IANA: 1170 Suggested Description Reference 1171 Value 1172 ---------------------------------------------------------- 1173 4 Segment Routing Header (SRH) This document 1175 This section provides guidance to the Internet Assigned Numbers 1176 Authority (IANA) regarding registration of values related to the SRH, 1177 in accordance with BCP 26, [RFC8126]. 1179 The following terms are used here with the meanings defined in BCP 1180 26: "namespace", "assigned value", "registration". 1182 The following policies are used here with the meanings defined in BCP 1183 26: "Private Use", "First Come First Served", "Expert Review", 1184 "Specification Required", "IETF Consensus", "Standards Action". 1186 For registration requests where a Designated Expert should be 1187 consulted, the responsible IESG area director should appoint the 1188 Designated Expert. The intention is that any allocation will be 1189 accompanied by a published RFC. In order to allow for the allocation 1190 of values prior to the RFC being approved for publication, the 1191 Designated Expert can approve allocations once it seems clear that an 1192 RFC will be published. The Designated expert will post a request to 1193 the 6man WG mailing list (or a successor designated by the Area 1194 Director) for comment and review, including an Internet-Draft. 1195 Before a period of 30 days has passed, the Designated Expert will 1196 either approve or deny the registration request and publish a notice 1197 of the decision to the 6man WG mailing list or its successor, as well 1198 as informing IANA. A denial notice must be justified by an 1199 explanation, and in the cases where it is possible, concrete 1200 suggestions on how the request can be modified so as to become 1201 acceptable should be provided. 1203 8.1. Segment Routing Header Flags Register 1205 This document requests the creation of a new IANA managed registry to 1206 identify SRH Flags Bits. The registration procedure is "Expert 1207 Review" as defined in [RFC8126]. Suggested registry name is "Segment 1208 Routing Header Flags". Flags is 8 bits. 1210 8.2. Segment Routing Header TLVs Register 1212 This document requests the creation of a new IANA managed registry to 1213 identify SRH TLVs. The registration procedure is "Expert Review" as 1214 defined in [RFC8126]. Suggested registry name is "Segment Routing 1215 Header TLVs". A TLV is identified through an unsigned 8 bit 1216 codepoint value, with assigned values 0-127 for TLVs that do not 1217 change en route, and 128-255 for TLVs that may change en route. The 1218 following codepoints are defined in this document: 1220 Assigned Description Reference 1221 Value 1222 ----------------------------------------------------- 1223 0 Pad0 TLV This document 1224 1 PadN TLV This document 1225 5 HMAC TLV This document 1227 9. Implementation Status 1229 This section is to be removed prior to publishing as an RFC. 1231 See [I-D.matsushima-spring-srv6-deployment-status] for updated 1232 deployment and interoperability reports. 1234 9.1. Linux 1236 Name: Linux Kernel v4.14 1238 Status: Production 1240 Implementation: adds SRH, performs END processing, supports HMAC TLV 1242 Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and 1243 [I-D.filsfils-spring-srv6-interop] 1245 9.2. Cisco Systems 1247 Name: IOS XR and IOS XE 1249 Status: Production (IOS XR), Pre-production (IOS XE) 1251 Implementation: adds SRH, performs END processing, no TLV processing 1253 Details: [I-D.filsfils-spring-srv6-interop] 1255 9.3. FD.io 1257 Name: VPP/Segment Routing for IPv6 1259 Status: Production 1261 Implementation: adds SRH, performs END processing, no TLV processing 1263 Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and 1264 [I-D.filsfils-spring-srv6-interop] 1266 9.4. Barefoot 1268 Name: Barefoot Networks Tofino NPU 1270 Status: Prototype 1272 Implementation: performs END processing, no TLV processing 1274 Details: [I-D.filsfils-spring-srv6-interop] 1276 9.5. Juniper 1278 Name: Juniper Networks Trio and vTrio NPU's 1280 Status: Prototype & Experimental 1282 Implementation: SRH insertion mode, Process SID where SID is an 1283 interface address, no TLV processing 1285 9.6. Huawei 1287 Name: Huawei Systems VRP Platform 1289 Status: Production 1291 Implementation: adds SRH, performs END processing, no TLV processing 1293 10. Contributors 1295 Kamran Raza, Zafar Ali, Brian Field, Daniel Bernier, Ida Leung, Jen 1296 Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk 1297 Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre 1298 Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta 1299 Maglione, James Connolly, Aloys Augustin contributed to the content 1300 of this document. 1302 11. Acknowledgements 1304 The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, 1305 Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, 1306 and David Lebrun for their comments to this document. 1308 12. References 1310 12.1. Normative References 1312 [FIPS180-4] 1313 National Institute of Standards and Technology, "FIPS 1314 180-4 Secure Hash Standard (SHS)", March 2012, 1315 . 1318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1319 Requirement Levels", BCP 14, RFC 2119, 1320 DOI 10.17487/RFC2119, March 1997, 1321 . 1323 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1324 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1325 December 1998, . 1327 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1328 DOI 10.17487/RFC4302, December 2005, 1329 . 1331 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1332 of Type 0 Routing Headers in IPv6", RFC 5095, 1333 DOI 10.17487/RFC5095, December 2007, 1334 . 1336 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1337 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1338 October 2011, . 1340 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1341 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1342 May 2017, . 1344 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1345 (IPv6) Specification", STD 86, RFC 8200, 1346 DOI 10.17487/RFC8200, July 2017, 1347 . 1349 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1350 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1351 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1352 July 2018, . 1354 12.2. Informative References 1356 [I-D.filsfils-spring-srv6-interop] 1357 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 1358 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 1359 "SRv6 interoperability report", draft-filsfils-spring- 1360 srv6-interop-02 (work in progress), March 2019. 1362 [I-D.matsushima-spring-srv6-deployment-status] 1363 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 1364 Implementation and Deployment Status", draft-matsushima- 1365 spring-srv6-deployment-status-01 (work in progress), May 1366 2019. 1368 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1369 Hashing for Message Authentication", RFC 2104, 1370 DOI 10.17487/RFC2104, February 1997, 1371 . 1373 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1374 Control Message Protocol (ICMPv6) for the Internet 1375 Protocol Version 6 (IPv6) Specification", STD 89, 1376 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1377 . 1379 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1380 DOI 10.17487/RFC5308, October 2008, 1381 . 1383 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1384 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1385 . 1387 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1388 "IPv6 Flow Label Specification", RFC 6437, 1389 DOI 10.17487/RFC6437, November 2011, 1390 . 1392 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1393 for Equal Cost Multipath Routing and Link Aggregation in 1394 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1395 . 1397 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1398 Writing an IANA Considerations Section in RFCs", BCP 26, 1399 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1400 . 1402 [SRN] Lebrun, D., Jadin, M., Clad, F., Filsfils, C., and O. 1403 Bonaventure, "Software Resolved Networks: Rethinking 1404 Enterprise Networks with IPv6 Segment Routing", 2018, 1405 . 1408 Authors' Addresses 1410 Clarence Filsfils (editor) 1411 Cisco Systems, Inc. 1412 Brussels 1413 BE 1415 Email: cfilsfil@cisco.com 1417 Darren Dukes (editor) 1418 Cisco Systems, Inc. 1419 Ottawa 1420 CA 1422 Email: ddukes@cisco.com 1424 Stefano Previdi 1425 Huawei 1426 Italy 1428 Email: stefano@previdi.net 1429 John Leddy 1430 Individual 1431 US 1433 Email: john@leddy.net 1435 Satoru Matsushima 1436 Softbank 1438 Email: satoru.matsushima@g.softbank.co.jp 1440 Daniel Voyer (editor) 1441 Bell Canada 1443 Email: daniel.voyer@bell.ca