idnits 2.17.1 draft-ietf-6man-segment-routing-header-23.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 (September 15, 2019) is 1678 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 863 -- Looks like a reference, but probably isn't: '8' on line 951 -- Looks like a reference, but probably isn't: '9' on line 951 -- 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: March 18, 2020 S. Previdi 6 Huawei 7 J. Leddy 8 Individual 9 S. Matsushima 10 Softbank 11 D. Voyer 12 Bell Canada 13 September 15, 2019 15 IPv6 Segment Routing Header (SRH) 16 draft-ietf-6man-segment-routing-header-23 18 Abstract 20 Segment Routing can be applied to the IPv6 data plane using a new 21 type of Routing Extension Header called the Segment Routing Header. 22 This document describes the Segment Routing Header and how it is used 23 by Segment 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 March 18, 2020. 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 Header . . . . . . . . . . . . . . . . . . . 4 62 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 8 64 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 9 65 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . 28 108 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28 109 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 28 110 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 28 111 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 28 112 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 29 113 9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . . . 32 121 1. Introduction 123 Segment Routing can be applied to the IPv6 data plane using a new 124 type of Routing Header called the Segment Routing Header. This 125 document describes the Segment Routing Header and how it is used by 126 Segment 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 Header is 132 defined in this document. 134 This document uses the terms Segment Routing, SR Domain, SRv6, 135 Segment ID (SID), SRv6 SID, Active Segment, and SR Policy as defined 136 in [RFC8402]. 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 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 SIDs which are not defined in this document. 211 The allocation and use of tag is outside the scope of this 212 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, Routing Type, and Segments 224 Left fields are defined in Section 4.4 of [RFC8200]. Based on the 225 constraints in that section Next Header, Header Ext Len, and Routing 226 Type are not mutable while Segments Left is mutable. 228 The mutability of the TLV value is defined by the most significant 229 bit in the type, as specified in Section 2.1. 231 Section 4.3 defines the mutability of the remaining fields in the SRH 232 (Flags, Tag, Segment List) in the context of the SID defined in this 233 document. 235 New SIDs defined in the future MUST specify the mutability properties 236 of the Flags, Tag, and Segment List and indicate how the HMAC TLV 237 (Section 2.1.2) verification works. Note, that in effect these 238 fields are mutable. 240 Consistent with the source routing model, the source of the SRH 241 always knows how to set the segment list, Flags, Tag and TLVs of the 242 SRH for use within the SR Domain. How it achieves this is outside 243 the scope of this document, but may be based on topology, available 244 SIDs and their mutability properties, the SRH mutability requirements 245 of the destination, or any other information. 247 2.1. SRH TLVs 249 This section defines TLVs of the Segment Routing Header. 251 A TLV provides meta-data for segment processing. The only TLVs 252 defined in this document are the HMAC (Section 2.1.2) and PAD 253 (Section 2.1.1) TLVs. While processing the SID defined in 254 Section 4.3.1, all TLVs are ignored unless local configuration 255 indicates otherwise (Section 4.3.1.1.1). Thus, TLV and HMAC support 256 is optional for any implementation, however an implementation adding 257 or parsing TLVs MUST support PAD TLVs. Other documents may define 258 additional TLVs and processing rules for them. 260 TLVs are present when the Hdr Ext Len is greater than (Last 261 Entry+1)*2. 263 While processing TLVs at a segment endpoint, TLVs MUST be fully 264 contained within the SRH as determined by the Hdr Ext Len. Detection 265 of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an 266 ICMP Parameter Problem, Code 0, message to the Source Address, 267 pointing to the Hdr Ext Len field of the SRH, and the packet being 268 discarded. 270 An implementation MAY limit the number and/or length of TLVs it 271 processes based on local configuration. It MAY: 273 o Limit the number of consecutive Pad1 (Section 2.1.1.1) options to 274 1, if padding of more than one byte is required then PadN 275 (Section 2.1.1.2) should be used. 277 o Limit the length in PadN to 5. 279 o Limit the maximum number of non-Pad TLVs to be processed. 281 o Limit the maximum length of all TLVs to be processed. 283 The implementation MAY stop processing additional TLVs in the SRH 284 when these configured limits are exceeded. 286 0 1 287 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 289 | Type | Length | Variable length data 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 292 Type: An 8 bit value. Unrecognized Types MUST be ignored on receipt. 294 Length: The length of the Variable length data. 296 Variable length data: Length bytes of data that is specific to the 297 Type. 299 Type Length Value (TLV) contain OPTIONAL information that may be used 300 by the node identified in the Destination Address (DA) of the packet. 302 Each TLV has its own length, format and semantic. The code-point 303 allocated (by IANA) to each TLV Type defines both the format and the 304 semantic of the information carried in the TLV. Multiple TLVs may be 305 encoded in the same SRH. 307 The highest-order bit of the TLV type specifies whether or not the 308 TLV data of that type can change en route to the packet's final 309 destination: 311 0: TLV data does not change en route 313 1: TLV data does change en route 315 All TLVs specify their alignment requirements using an xn+y format. 316 The xn+y format is defined as per [RFC8200]. The SR Source nodes use 317 the xn+y alignment requirements of TLVs and Padding TLVs when 318 constructing an SRH. 320 The "Length" field of the TLV is used to skip the TLV while 321 inspecting the SRH in case the node doesn't support or recognize the 322 Type. The "Length" defines the TLV length in octets, not including 323 the "Type" and "Length" fields. 325 The following TLVs are defined in this document: 327 Padding TLVs 329 HMAC TLV 331 Additional TLVs may be defined in the future. 333 2.1.1. Padding TLVs 335 There are two types of Padding TLVs, pad1 and padN, the following 336 applies to both: 338 Padding TLVs are used for meeting the alignment requirement of the 339 subsequent TLVs. 341 Padding TLVs are used to pad the SRH to a multiple of 8 octets. 343 Padding TLVs are used for alignment. 345 Padding TLVs are ignored by a node processing the SRH TLV. 347 Multiple Padding TLVs MAY be used in one SRH 349 2.1.1.1. PAD1 351 Alignment requirement: none 353 0 1 2 3 4 5 6 7 354 +-+-+-+-+-+-+-+-+ 355 | Type | 356 +-+-+-+-+-+-+-+-+ 358 Type: to be assigned by IANA (Suggested value 0) 360 A single Pad1 TLV MUST be used when a single byte of padding is 361 required. If more than one byte of padding is required a Pad1 TLV 362 MUST NOT be used, the PadN TLV MUST be used. 364 2.1.1.2. PADN 366 Alignment requirement: none 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Type | Length | Padding (variable) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 // Padding (variable) // 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Type: to be assigned by IANA (suggested value 4). 378 Length: 0 to 5 379 Padding: Length octets of padding. Padding bits have no 380 semantics. They MUST be set to 0 on transmission and ignored on 381 receipt. 383 The PadN TLV MUST be used when more than one byte of padding is 384 required. 386 2.1.2. HMAC TLV 388 Alignment requirement: 8n 390 The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL 391 and has the following format: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type | Length | RESERVED | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | HMAC Key ID (4 octets) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | // 401 | HMAC (32 octets) // 402 | // 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 where: 407 o Type: to be assigned by IANA (suggested value 5). 409 o Length: 38. 411 o RESERVED: 2 octets. MUST be 0 on transmission and ignored on 412 receipt. 414 o HMAC Key ID: A 4 octet opaque number which uniquely identifies the 415 pre-shared key and algorithm used to generate the HMAC. 417 o HMAC: 32 octets of keyed HMAC. 419 The HMAC TLV is used to verify the source of a packet is permitted to 420 use the current segment in the destination address of the packet, and 421 ensure the segment list is not modified in transit. 423 2.1.2.1. HMAC Generation and Verification 425 Local configuration determines when to check for an HMAC and 426 potentially indicates what the HMAC protects, and a requirement on 427 where the HMAC TLV must appear (e.g. first TLV), and whether or not 428 to verify the destination address is equal to the current segment. 429 This local configuration is outside the scope of this document. It 430 may be based on the active segment at an SR Segment endpoint node, 431 the result of an ACL that considers incoming interface, HMAC Key ID, 432 or other packet fields. 434 An implementation that supports the generation and verification of 435 the HMAC SHOULD support the following default behavior as defined in 436 the remainder of this section. 438 The HMAC verification begins by checking the current segment is equal 439 to the destination address of the IPv6 header, i.e. destination 440 address is equal to Segment List [Segments Left] and Segments Left is 441 less than or equal to Last Segment+1. 443 The HMAC field is the output of the HMAC computation as defined in 444 [RFC2104], using: 446 o key: the pre-shared key identified by HMAC Key ID 448 o HMAC algorithm: identified by the HMAC Key ID 450 o Text: a concatenation of the following fields from the IPv6 header 451 and the SRH, as it would be received at the node verifying the 452 HMAC: 454 * IPv6 header: source address (16 octets) 456 * SRH: Last Entry (1 octet) 458 * SRH: Flags (1 octet) 460 * SRH: HMAC Key-id (4 octets) 462 * SRH: all addresses in the Segment List (variable octets) 464 The HMAC digest is truncated to 32 octets and placed in the HMAC 465 field of the HMAC TLV. 467 For HMAC algorithms producing digests less than 32 octets, the digest 468 is placed in the lowest order octets of the HMAC field. Remaining 469 octets MUST be set to zero. 471 If HMAC verification is successful, the packet is forwarded to the 472 next segment. 474 If HMAC verification fails, an ICMP error message (parameter problem, 475 error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate 476 limited) and SHOULD be logged and the packet discarded. 478 2.1.2.2. HMAC Pre-Shared Key Algorithm 480 The HMAC Key ID field allows for the simultaneous existence of 481 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 482 well as pre-shared keys. 484 The HMAC Key ID field is opaque, i.e., it has neither syntax nor 485 semantic except as an identifier of the right combination of pre- 486 shared key and hash algorithm, and except that a value of 0 means 487 that there is no HMAC field. 489 At the HMAC TLV verification node the Key ID uniquely identifies the 490 pre-shared key and HMAC algorithm. 492 At the HMAC TLV generating node the Key ID and destination address 493 uniquely identify the pre-shared key and HMAC algorithm. Utilizing 494 the destination address with the Key ID allows for overlapping key 495 IDs amongst different HMAC verification nodes. The Text for the HMAC 496 computation is set to the IPv6 header fields and SRH fields as they 497 would appear at the verification node, not necessarily the same as 498 the source node sending a packet with the HMAC TLV. 500 Pre-shared key roll-over is supported by having two key IDs in use 501 while the HMAC TLV generating node and verifying node converge to a 502 new key. 504 An implementation supporting HMAC can support multiple hash 505 functions. An implementation supporting HMAC MUST implement SHA-2 506 [FIPS180-4] in its SHA-256 variant. 508 The selection of pre-shared key and algorithm, and their distribution 509 is outside the scope of this document, some options may include: 511 o in the configuration of the HMAC generating or verifying nodes, 512 either by static configuration or any SDN oriented approach 514 o dynamically using a trusted key distribution protocol such as 515 [RFC6407] 517 3. SR Nodes 519 There are different types of nodes that may be involved in segment 520 routing networks: source SR nodes originate packets with a segment in 521 the destination address of the IPv6 header, transit nodes that 522 forward packets destined to a remote segment, and SR segment endpoint 523 nodes that process a local segment in the destination address of an 524 IPv6 header. 526 3.1. Source SR Node 528 A Source SR Node is any node that originates an IPv6 packet with a 529 segment (i.e. SRv6 SID) in the destination address of the IPv6 530 header. The packet leaving the source SR Node may or may not contain 531 an SRH. This includes either: 533 A host originating an IPv6 packet. 535 An SR domain ingress router encapsulating a received packet in an 536 outer IPv6 header, followed by an optional SRH. 538 The mechanism through which a segment in the destination address of 539 the IPv6 header and the Segment List in the SRH, is derived is 540 outside the scope of this document. 542 3.2. Transit Node 544 A transit node is any node forwarding an IPv6 packet where the 545 destination address of that packet is not locally configured as a 546 segment nor a local interface. A transit node is not required to be 547 capable of processing a segment nor SRH. 549 3.3. SR Segment Endpoint Node 551 A SR segment endpoint node is any node receiving an IPv6 packet where 552 the destination address of that packet is locally configured as a 553 segment or local interface. 555 4. Packet Processing 557 This section describes SRv6 packet processing at the SR source, 558 Transit and SR segment endpoint nodes. 560 4.1. Source SR Node 562 A Source node steers a packet into an SR Policy. If the SR Policy 563 results in a segment list containing a single segment, and there is 564 no need to add information to SRH flag or TLV, the DA is set to the 565 single segment list entry and the SRH MAY be omitted. 567 When needed, the SRH is created as follows: 569 Next Header and Hdr Ext Len fields are set as specified in 570 [RFC8200]. 572 Routing Type field is set as TBD (to be allocated by IANA, 573 suggested value 4). 575 The DA of the packet is set with the value of the first segment. 577 The first element of the SRH Segment List is the ultimate segment. 578 The second element is the penultimate segment and so on. 580 The Segments Left field is set to n-1 where n is the number of 581 elements in the SR Policy. 583 The Last Entry field is set to n-1 where n is the number of 584 elements in the SR Policy. 586 HMAC TLV may be set according to Section 2.1.2. 588 The packet is forwarded toward the packet's Destination Address 589 (the first segment). 591 4.1.1. Reduced SRH 593 When a source does not require the entire SID list to be preserved in 594 the SRH, a reduced SRH may be used. 596 A reduced SRH does not contain the first segment of the related SR 597 Policy (the first segment is the one already in the DA of the IPv6 598 header), and the Last Entry field is set to n-2 where n is the number 599 of elements in the SR Policy. 601 4.2. Transit Node 603 As specified in [RFC8200], the only node allowed to inspect the 604 Routing Extension Header (and therefore the SRH), is the node 605 corresponding to the DA of the packet. Any other transit node MUST 606 NOT inspect the underneath routing header and MUST forward the packet 607 toward the DA according to its IPv6 routing table. 609 When a SID is in the destination address of an IPv6 header of a 610 packet, it's routed through an IPv6 network as an IPv6 address. 611 SIDs, or the prefix(es) covering SIDs, and their reachability may be 612 distributed by means outside the scope of this document. For 613 example, [RFC5308] or [RFC5340] may be used to advertise a prefix 614 covering the SIDs on a node. 616 4.3. SR Segment Endpoint Node 618 Without constraining the details of an implementation, the SR segment 619 endpoint node creates Forwarding Information Base (FIB) entries for 620 its local SIDs. 622 When an SRv6-capable node receives an IPv6 packet, it performs a 623 longest-prefix-match lookup on the packets destination address. This 624 lookup can return any of the following: 626 * A FIB entry that represents a locally instantiated SRv6 SID 627 * A FIB entry that represents a local interface, not locally 628 instantiated as an SRv6 SID 629 * A FIB entry that represents a non-local route 630 * No Match 632 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID 634 This document, and section, defines a single SRv6 SID. Future 635 documents may define additional SRv6 SIDs. In which case, the entire 636 content of this section will be defined in that document. 638 If the FIB entry represents a locally instantiated SRv6 SID, process 639 the next header chain of the IPv6 header as defined in section 4 of 640 [RFC8200]. Section 4.3.1.1 describes how to process an SRH, 641 Section 4.3.1.2 describes how to process an upper layer header or no 642 next header. 644 Processing this SID modifies the Segments Left and, if configured to 645 process TLVs, it may modify the "variable length data" of TLV types 646 that change en route. Therefore Segments Left is mutable and TLVs 647 that change en route are mutable. The remainder of the SRH (Flags, 648 Tag, Segment List, and TLVs that do not change en route) are 649 immutable while processing this SID. 651 4.3.1.1. SRH Processing 652 S01. When an SRH is processed { 653 S02. If Segments Left is equal to zero { 654 S03. Proceed to process the next header in the packet, 655 whose type is identified by the Next Header field in 656 the Routing header. 657 S04. } 658 S05. Else { 659 S06. If local configuration requires TLV processing { 660 S07. Perform TLV processing (see TLV Processing) 661 S08. } 662 S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1 663 S10. If ((Last Entry > max_last_entry) or 664 S11. (Segments Left is greater than (Last Entry+1)) { 665 S12. Send an ICMP Parameter Problem, Code 0, message to 666 the Source Address, pointing to the Segments Left 667 field, and discard the packet. 668 S13. } 669 S14. Else { 670 S15. Decrement Segments Left by 1. 671 S16. Copy Segment List[Segments Left] from the SRH to the 672 destination address of the IPv6 header. 673 S17. If the IPv6 Hop Limit is less than or equal to 1 { 674 S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in 675 Transit message to the Source Address and discard 676 the packet. 677 S19. } 678 S20. Else { 679 S21. Decrement the Hop Limit by 1 680 S22. Resubmit the packet to the IPv6 module for transmission 681 to the new destination. 682 S23. } 683 S24. } 684 S25. } 685 S26. } 687 4.3.1.1.1. TLV Processing 689 Local configuration determines how TLVs are to be processed when the 690 Active Segment is a local SID defined in this document. The 691 definition of local configuration is outside the scope of this 692 document. 694 For illustration purpose only, two example local configurations that 695 may be associated with a SID are provided below. 697 Example 1: 698 For any packet received from interface I2 699 Skip TLV processing 701 Example 2: 702 For any packet received from interface I1 703 If first TLV is HMAC { 704 Process the HMAC TLV 705 } 706 Else { 707 Discard the packet 708 } 710 4.3.1.2. Upper-layer Header or No Next Header 712 When processing the Upper-layer header of a packet matching a FIB 713 entry locally instantiated as an SRv6 SID defined in this document. 715 IF (Upper-layer Header is IPv4 or IPv6) and 716 local configuration permits { 717 Perform IPv6 decapsulation 718 Resubmit the decapsulated packet to the IPv4 or IPv6 module 719 } 720 ELSE { 721 Send an ICMP parameter problem message to the Source Address and 722 discard the packet. Error code (TBD by IANA) "SR Upper-layer 723 Header Error", pointer set to the offset of the upper-layer 724 header. 725 } 727 A unique error code allows an SR Source node to recognize an error in 728 SID processing at an endpoint. 730 4.3.2. FIB Entry Is A Local Interface 732 If the FIB entry represents a local interface, not locally 733 instantiated as an SRv6 SID, the SRH is processed as follows: 735 If Segments Left is zero, the node must ignore the Routing header 736 and proceed to process the next header in the packet, whose type 737 is identified by the Next Header field in the Routing Header. 739 If Segments Left is non-zero, the node must discard the packet and 740 send an ICMP Parameter Problem, Code 0, message to the packet's 741 Source Address, pointing to the unrecognized Routing Type. 743 4.3.3. FIB Entry Is A Non-Local Route 745 Processing is not changed by this document. 747 4.3.4. FIB Entry Is A No Match 749 Processing is not changed by this document. 751 5. Intra SR Domain Deployment Model 753 The use of the SIDs exclusively within the SR Domain and solely for 754 packets of the SR Domain is an important deployment model. 756 This enables the SR Domain to act as a single routing system. 758 This section covers: 760 o securing the SR Domain from external attempt to use its SIDs 762 o SR Domain as a single system with delegation between components 764 o handling packets of the SR Domain 766 5.1. Securing the SR Domain 768 Nodes outside the SR Domain are not trusted: they cannot directly use 769 the SID's of the domain. This is enforced by two levels of access 770 control lists: 772 1. Any packet entering the SR Domain and destined to a SID within 773 the SR Domain is dropped. This may be realized with the 774 following logic, other methods with equivalent outcome are 775 considered compliant: 777 * allocate all the SID's from a block S/s 779 * configure each external interface of each edge node of the 780 domain with an inbound infrastructure access list (IACL) which 781 drops any incoming packet with a destination address in S/s 783 * Failure to implement this method of ingress filtering exposes 784 the SR Domain to source routing attacks as described and 785 referenced in [RFC5095] 787 2. The distributed protection in #1 is complemented with per node 788 protection, dropping packets to SIDs from source addresses 789 outside the SR Domain. This may be realized with the following 790 logic, other methods with equivalent outcome are considered 791 compliant: 793 * assign all interface addresses from prefix A/a 795 * at node k, all SIDs local to k are assigned from prefix Sk/sk 797 * configure each internal interface of each SR node k in the SR 798 Domain with an inbound IACL which drops any incoming packet 799 with a destination address in Sk/sk if the source address is 800 not in A/a. 802 5.2. SR Domain as A Single System with Delegation Among Components 804 All intra SR Domain packets are of the SR Domain. The IPv6 header is 805 originated by a node of the SR Domain, and is destined to a node of 806 the SR Domain. 808 All inter domain packets are encapsulated for the part of the packet 809 journey that is within the SR Domain. The outer IPv6 header is 810 originated by a node of the SR Domain, and is destined to a node of 811 the SR Domain. 813 As a consequence, any packet within the SR Domain is of the SR 814 Domain. 816 The SR Domain is a system in which the operator may want to 817 distribute or delegate different operations of the outer most header 818 to different nodes within the system. 820 An operator of an SR domain may choose to delegate SRH addition to a 821 host node within the SR domain, and validation of the contents of any 822 SRH to a more trusted router or switch attached to the host. 823 Consider a top of rack switch (T) connected to host (H) via interface 824 (I). H receives an SRH (SRH1) with a computed HMAC via some SDN 825 method outside the scope of this document. H classifies traffic it 826 sources and adds SRH1 to traffic requiring a specific SLA. T is 827 configured with an IACL on I requiring verification of the SRH for 828 any packet destined to the SID block of the SR Domain (S/s). T 829 checks and verifies that SRH1 is valid, contains an HMAC TLV and 830 verifies the HMAC. 832 An operator of the SR Domain may choose to have all segments in the 833 SR Domain verify the HMAC. This mechanism would verify that the SRH 834 segment list is not modified while traversing the SR Domain. 836 5.3. MTU Considerations 838 An SR Domain ingress edge node encapsulates packets traversing the SR 839 Domain, and needs to consider the MTU of the SR Domain. Within the 840 SR Domain, well known mitigation techniques are RECOMMENDED, such as 841 deploying a greater MTU value within the SR Domain than at the 842 ingress edges. 844 5.4. ICMP Error Processing 846 ICMP error packets generated within the SR Domain are sent to source 847 nodes within the SR Domain. The invoking packet in the ICMP error 848 message may contain an SRH. Since the destination address of a 849 packet with an SRH changes as each segment is processed, it may not 850 be the destination used by the socket or application that generated 851 the invoking packet. 853 For the source of an invoking packet to process the ICMP error 854 message, the correct destination address must be determined. The 855 following logic is used to determine the destination address for use 856 by protocol error handlers. 858 o Walk all extension headers of the invoking IPv6 packet to the 859 routing extension header preceding the upper layer header. 861 * If routing header is type 4 (SRH) 863 + Use the SID at Segment List[0] as the destination address of 864 the invoking packet. 866 ICMP errors are then processed by upper layer transports as defined 867 in [RFC4443]. 869 For IP packets encapsulated in an outer IPv6 header, ICMP error 870 handling is as defined in [RFC2473]. 872 5.5. Load Balancing and ECMP 874 For any inter domain packet, the SR Source node MUST impose a flow 875 label computed based on the inner packet. The computation of the 876 flow label is as recommended in [RFC6438] for the sending Tunnel End 877 Point. 879 For any intra domain packet, the SR Source node SHOULD impose a flow 880 label computed as described in [RFC6437] to assist ECMP load 881 balancing at transit nodes incapable of computing a 5-tuple beyond 882 the SRH. 884 At any transit node within an SR domain, the flow label MUST be used 885 as defined in [RFC6438] to calculate the ECMP hash toward the 886 destination address. If flow label is not used, the transit node 887 would likely hash all packets between a pair of SR Edge nodes to the 888 same link. 890 At an SR segment endpoint node, the flow label MUST be used as 891 defined in [RFC6438] to calculate any ECMP hash used to forward the 892 processed packet to the next segment. 894 5.6. Other Deployments 896 Other deployment models and their implications on security, MTU, 897 HMAC, ICMP error processing and interaction with other extension 898 headers are outside the scope of this document. 900 6. Illustrations 902 This section provides illustrations of SRv6 packet processing at SR 903 source, transit and SR segment endpoint nodes. 905 6.1. Abstract Representation of an SRH 907 For a node k, its IPv6 address is represented as Ak, its SRv6 SID is 908 represented as Sk. 910 IPv6 headers are represented as the tuple of (source, destination). 911 For example, a packet with source address A1 and destination address 912 A2 is represented as (A1,A2). The payload of the packet is omitted. 914 An SR Policy is a list of segments. A list of segments is 915 represented as where S1 is the first SID to visit, S2 is 916 the second SID to visit and S3 is the last SID to visit. 918 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 920 o Source Address is SA, Destination Addresses is DA, and next-header 921 is SRH. 923 o SRH with SID list with SegmentsLeft = SL. 925 o Note the difference between the <> and () symbols. 926 represents a SID list where the leftmost segment is the first 927 segment. Whereas, (S3, S2, S1; SL) represents the same SID list 928 but encoded in the SRH Segment List format where the leftmost 929 segment is the last segment. When referring to an SR policy in a 930 high-level use-case, it is simpler to use the 931 notation. When referring to an illustration of detailed behavior, 932 the (S3, S2, S1; SL) notation is more convenient. 934 At its SR Policy headend, the Segment List results in SRH 935 (S3,S2,S1; SL=2) represented fully as: 937 Segments Left=2 938 Last Entry=2 939 Flags=0 940 Tag=0 941 Segment List[0]=S3 942 Segment List[1]=S2 943 Segment List[2]=S1 945 6.2. Example Topology 947 The following topology is used in examples below: 949 + * * * * * * * * * * * * * * * * * * * * + 951 * [8] [9] * 952 | | 953 * | | * 954 [1]----[3]--------[5]----------------[6]---------[4]---[2] 955 * | | * 956 | | 957 * | | * 958 +--------[7]-------+ 959 * * 961 + * * * * * * * SR Domain * * * * * * * + 963 Figure 3 965 o 3 and 4 are SR Domain edge routers 967 o 5, 6, and 7 are all SR Domain routers 969 o 8 and 9 are hosts within the SR Domain 971 o 1 and 2 are hosts outside the SR Domain 973 o The SR domain is secured as per Section 5.1 and no external packet 974 can enter the domain with a destination address equal to a segment 975 of the domain. 977 6.3. Source SR Node 979 6.3.1. Intra SR Domain Packet 981 When host 8 sends a packet to host 9 via an SR Policy the 982 packet is 984 P1: (A8,S7)(A9,S7; SL=1) 986 6.3.1.1. Reduced Variant 988 When host 8 sends a packet to host 9 via an SR Policy and it 989 wants to use a reduced SRH, the packet is 991 P2: (A8,S7)(A9; SL=1) 993 6.3.2. Inter SR Domain Packet - Transit 995 When host 1 sends a packet to host 2, the packet is 997 P3: (A1,A2) 999 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 1000 egress router 4 via an SR Policy . Router 3 encapsulates the 1001 received packet P3 in an outer header with an SRH. The packet is 1003 P4: (A3, S7)(S4, S7; SL=1)(A1, A2) 1005 If the SR Policy contains only one segment (the egress router 4), the 1006 ingress Router 3 encapsulates P3 into an outer header (A3, S4). The 1007 packet is 1009 P5: (A3, S4)(A1, A2) 1011 6.3.2.1. Reduced Variant 1013 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 1014 egress router 4 via an SR Policy . If router 3 wants to use 1015 a reduced SRH, Router 3 encapsulates the received packet P3 in an 1016 outer header with a reduced SRH. The packet is 1018 P6: (A3, S7)(S4; SL=1)(A1, A2) 1020 6.3.3. Inter SR Domain Packet - Internal to External 1022 When host 8 sends a packet to host 1, the packet is encapsulated for 1023 the portion of its journey within the SR Domain. From 8 to 3 the 1024 packet is 1025 P7: (A8,S3)(A8,A1) 1027 In the opposite direction, the packet generated from 1 to 8 is 1029 P8: (A1,A8) 1031 At node 3 P8 is encapsulated for the portion of its journey within 1032 the SR domain, with the outer header destined to segment S8. 1033 Resulting in 1035 P9: (A3,S8)(A1,A8) 1037 At node 8 the outer IPv6 header is removed by S8 processing, then 1038 processed again when received by A8. 1040 6.4. Transit Node 1042 Nodes 5 acts as transit nodes for packet P1, and sends packet 1044 P1: (A8,S7)(A9,S7;SL=1) 1046 on the interface toward node 7. 1048 6.5. SR Segment Endpoint Node 1050 Node 7 receives packet P1 and, using the logic in Section 4.3.1, 1051 sends packet 1053 P7: (A8,A9)(A9,S7; SL=0) 1055 on the interface toward router 6. 1057 6.6. Delegation of Function with HMAC Verification 1059 This section describes how a function may be delegated within the SR 1060 Domain to non SR source nodes. In the following sections consider a 1061 host 8 connected to a top of rack 5. 1063 6.6.1. SID List Verification 1065 An operator may prefer to add the SRH at source 8, while 5 verifies 1066 the SID list is valid. 1068 For illustration purpose, an SDN controller provides 8 an SRH 1069 terminating at node 9, with segment list , and HMAC TLV 1070 computed for the SRH. The HMAC key is shared with 5, node 8 does not 1071 know the key. Node 5 is configured with an IACL applied to the 1072 interface connected to 8, requiring HMAC verification for any packet 1073 destined to S/s. 1075 Node 8 originates packets with the received SRH with HMAC TLV. 1077 P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC) 1079 Node 5 receives and verifies the HMAC for the SRH, then forwards the 1080 packet to the next segment 1082 P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC) 1084 Node 6 receives 1086 P17:(A8,S6)(A9,S6,S7,S5;SL=1;HMAC) 1088 Node 9 receives 1090 P18:(A8,A9)(A9,S6,S7,S5;SL=0;HMAC) 1092 This use of an HMAC is particularly valuable within an enterprise 1093 based SR Domain [SRN]. 1095 7. Security Considerations 1097 This section reviews security considerations related to the SRH, 1098 given the SRH processing and deployment models discussed in this 1099 document. 1101 As described in Section 5, it is necessary to filter packets ingress 1102 to the SR Domain, destined to SIDs within the SR Domain (i.e., 1103 bearing a SID in the destination address). This ingress filtering is 1104 via an IACL at SR Domain ingress border nodes. Additional protection 1105 is applied via an IACL at each SR Segment Endpoint node, filtering 1106 packets not from within the SR Domain, destined to SIDs in the SR 1107 Domain. ACLs are easily supported for small numbers of prefixes, 1108 making summarization important, and when the prefixes requiring 1109 filtering is kept to a seldom changing set. 1111 Additionally, ingress filtering of IPv6 source addresses as 1112 recommended in BCP38 [RFC2827] SHOULD be used. 1114 7.1. Source Routing Attacks 1116 [RFC5095] deprecates the Type 0 Routing header due to a number of 1117 significant attacks that are referenced in that document. Such 1118 attacks include bypassing filtering devices, reaching otherwise 1119 unreachable Internet systems, network topology discovery, bandwidth 1120 exhaustion, and defeating anycast. 1122 Because this document specifies that the SRH is for use within an SR 1123 domain protected by ingress filtering via IACLs; such attacks cannot 1124 be mounted from outside an SR Domain. As specified in this document, 1125 SR Domain ingress edge nodes drop packets entering the SR Domain 1126 destined to segments within the SR Domain. 1128 Additionally, this document specifies the use of IACL on SR Segment 1129 Endpoint nodes within the SR Domain to limit the source addresses 1130 permitted to send packets to a SID in the SR Domain. 1132 Such attacks may, however, be mounted from within the SR Domain, from 1133 nodes permitted to source traffic to SIDs in the domain. As such, 1134 these attacks and other known attacks on an IP network (e.g. DOS/ 1135 DDOS, topology discovery, man-in-the-middle, traffic interception/ 1136 siphoning), can occur from compromised nodes within an SR Domain. 1138 7.2. Service Theft 1140 Service theft is defined as the use of a service offered by the SR 1141 Domain by a node not authorized to use the service. 1143 Service theft is not a concern within the SR Domain as all SR Source 1144 nodes and SR segment endpoint nodes within the domain are able to 1145 utilize the services of the Domain. If a node outside the SR Domain 1146 learns of segments or a topological service within the SR domain, 1147 IACL filtering denies access to those segments. 1149 7.3. Topology Disclosure 1151 The SRH is unencrypted and may contain SIDs of some intermediate SR- 1152 nodes in the path towards the destination within the SR Domain. If 1153 packets can be snooped within the SR Domain, the SRH may reveal 1154 topology, traffic flows, and service usage. 1156 This is applicable within an SR Domain but the disclosure is less 1157 relevant as an attacker has other means of learning topology, flows, 1158 and service usage. 1160 7.4. ICMP Generation 1162 The generation of ICMPv6 error messages may be used to attempt 1163 denial-of-service attacks by sending an error-causing destination 1164 address or SRH in back-to-back packets. An implementation that 1165 correctly follows Section 2.4 of [RFC4443] would be protected by the 1166 ICMPv6 rate-limiting mechanism. 1168 7.5. Applicability of AH 1170 The SR Domain is a trusted domain, as defined in [RFC8402] Section 2 1171 and Section 8.2. The SR Source is trusted to add an SRH (optionally 1172 verified via the HMAC TLV in this document), and segments advertised 1173 within the domain are trusted to be accurate and advertised by 1174 trusted sources via a secure control plane. As such the SR Domain 1175 does not rely on the Authentication Header (AH) as defined in 1176 [RFC4302] to secure the SRH. 1178 The use of SRH with AH by an SR source node, and processing at a SR 1179 segment endpoint node, is not defined in this document. Future 1180 documents may define use of SRH with AH and its processing. 1182 8. IANA Considerations 1184 This document makes the following registrations in the Internet 1185 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1186 maintained by IANA: 1188 Suggested Description Reference 1189 Value 1190 ---------------------------------------------------------- 1191 4 Segment Routing Header (SRH) This document 1193 This document makes the following registrations in "Type 4 - 1194 Parameter Problem" message of the "Internet Control Message Protocol 1195 version 6 (ICMPv6) Parameters" registry maintained by IANA: 1197 CODE NAME/DESCRIPTION 1198 ---------------------------------------------------------- 1199 TBD IANA SR Upper-layer Header Error 1201 This section provides guidance to the Internet Assigned Numbers 1202 Authority (IANA) regarding registration of values related to the SRH, 1203 in accordance with BCP 26, [RFC8126]. 1205 The following terms are used here with the meanings defined in BCP 1206 26: "namespace", "assigned value", "registration". 1208 The following policies are used here with the meanings defined in BCP 1209 26: "Private Use", "First Come First Served", "Expert Review", 1210 "Specification Required", "IETF Consensus", "Standards Action". 1212 For registration requests where a Designated Expert should be 1213 consulted, the responsible IESG area director should appoint the 1214 Designated Expert. The intention is that any allocation will be 1215 accompanied by a published RFC. In order to allow for the allocation 1216 of values prior to the RFC being approved for publication, the 1217 Designated Expert can approve allocations once it seems clear that an 1218 RFC will be published. The Designated expert will post a request to 1219 the 6man WG mailing list (or a successor designated by the Area 1220 Director) for comment and review, including an Internet-Draft. 1221 Before a period of 30 days has passed, the Designated Expert will 1222 either approve or deny the registration request and publish a notice 1223 of the decision to the 6man WG mailing list or its successor, as well 1224 as informing IANA. A denial notice must be justified by an 1225 explanation, and in the cases where it is possible, concrete 1226 suggestions on how the request can be modified so as to become 1227 acceptable should be provided. 1229 8.1. Segment Routing Header Flags Register 1231 This document requests the creation of a new IANA managed registry to 1232 identify SRH Flags Bits. The registration procedure is "Expert 1233 Review" as defined in [RFC8126]. Suggested registry name is "Segment 1234 Routing Header Flags". Flags is 8 bits. 1236 8.2. Segment Routing Header TLVs Register 1238 This document requests the creation of a new IANA managed registry to 1239 identify SRH TLVs. The registration procedure is "Expert Review" as 1240 defined in [RFC8126]. Suggested registry name is "Segment Routing 1241 Header TLVs". A TLV is identified through an unsigned 8 bit 1242 codepoint value, with assigned values 0-127 for TLVs that do not 1243 change en route, and 128-255 for TLVs that may change en route. The 1244 following codepoints are defined in this document: 1246 Assigned Description Reference 1247 Value 1248 ----------------------------------------------------- 1249 0 Pad1 TLV This document 1250 1 Reserved This document 1251 2 Reserved This document 1252 3 Reserved This document 1253 4 PadN TLV This document 1254 5 HMAC TLV This document 1255 6 Reserved This document 1256 124-126 Experimentation and Test This document 1257 127 Reserved This document 1258 252-254 Experimentation and Test This document 1259 255 Reserved This document 1261 Values 1,2,3,6 were defined in draft versions of this specification 1262 and are Reserved for backwards compatibility with early 1263 implementations and should not be reassigned. Values 127 and 255 are 1264 Reserved to allow for expansion of the Type field in future 1265 specifications if needed. 1267 9. Implementation Status 1269 This section is to be removed prior to publishing as an RFC. 1271 See [I-D.matsushima-spring-srv6-deployment-status] for updated 1272 deployment and interoperability reports. 1274 9.1. Linux 1276 Name: Linux Kernel v4.14 1278 Status: Production 1280 Implementation: adds SRH, performs END processing, supports HMAC TLV 1282 Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and 1283 [I-D.filsfils-spring-srv6-interop] 1285 9.2. Cisco Systems 1287 Name: IOS XR and IOS XE 1289 Status: Production (IOS XR), Pre-production (IOS XE) 1291 Implementation: adds SRH, performs END processing, no TLV processing 1293 Details: [I-D.filsfils-spring-srv6-interop] 1295 9.3. FD.io 1297 Name: VPP/Segment Routing for IPv6 1299 Status: Production 1301 Implementation: adds SRH, performs END processing, no TLV processing 1303 Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and 1304 [I-D.filsfils-spring-srv6-interop] 1306 9.4. Barefoot 1308 Name: Barefoot Networks Tofino NPU 1310 Status: Prototype 1311 Implementation: performs END processing, no TLV processing 1313 Details: [I-D.filsfils-spring-srv6-interop] 1315 9.5. Juniper 1317 Name: Juniper Networks Trio and vTrio NPU's 1319 Status: Prototype & Experimental 1321 Implementation: SRH insertion mode, Process SID where SID is an 1322 interface address, no TLV processing 1324 9.6. Huawei 1326 Name: Huawei Systems VRP Platform 1328 Status: Production 1330 Implementation: adds SRH, performs END processing, no TLV processing 1332 10. Contributors 1334 Kamran Raza, Zafar Ali, Brian Field, Daniel Bernier, Ida Leung, Jen 1335 Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk 1336 Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre 1337 Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta 1338 Maglione, James Connolly, Aloys Augustin contributed to the content 1339 of this document. 1341 11. Acknowledgements 1343 The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, 1344 Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, 1345 and David Lebrun for their comments to this document. 1347 12. References 1349 12.1. Normative References 1351 [FIPS180-4] 1352 National Institute of Standards and Technology, "FIPS 1353 180-4 Secure Hash Standard (SHS)", March 2012, 1354 . 1357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1358 Requirement Levels", BCP 14, RFC 2119, 1359 DOI 10.17487/RFC2119, March 1997, 1360 . 1362 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1363 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1364 December 1998, . 1366 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1367 Defeating Denial of Service Attacks which employ IP Source 1368 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1369 May 2000, . 1371 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1372 DOI 10.17487/RFC4302, December 2005, 1373 . 1375 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1376 of Type 0 Routing Headers in IPv6", RFC 5095, 1377 DOI 10.17487/RFC5095, December 2007, 1378 . 1380 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1381 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1382 October 2011, . 1384 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1385 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1386 May 2017, . 1388 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1389 (IPv6) Specification", STD 86, RFC 8200, 1390 DOI 10.17487/RFC8200, July 2017, 1391 . 1393 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1394 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1395 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1396 July 2018, . 1398 12.2. Informative References 1400 [I-D.filsfils-spring-srv6-interop] 1401 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 1402 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 1403 "SRv6 interoperability report", draft-filsfils-spring- 1404 srv6-interop-02 (work in progress), March 2019. 1406 [I-D.matsushima-spring-srv6-deployment-status] 1407 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 1408 Implementation and Deployment Status", draft-matsushima- 1409 spring-srv6-deployment-status-01 (work in progress), May 1410 2019. 1412 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1413 Hashing for Message Authentication", RFC 2104, 1414 DOI 10.17487/RFC2104, February 1997, 1415 . 1417 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1418 Control Message Protocol (ICMPv6) for the Internet 1419 Protocol Version 6 (IPv6) Specification", STD 89, 1420 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1421 . 1423 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1424 DOI 10.17487/RFC5308, October 2008, 1425 . 1427 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1428 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1429 . 1431 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1432 "IPv6 Flow Label Specification", RFC 6437, 1433 DOI 10.17487/RFC6437, November 2011, 1434 . 1436 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1437 for Equal Cost Multipath Routing and Link Aggregation in 1438 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1439 . 1441 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1442 Writing an IANA Considerations Section in RFCs", BCP 26, 1443 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1444 . 1446 [SRN] Lebrun, D., Jadin, M., Clad, F., Filsfils, C., and O. 1447 Bonaventure, "Software Resolved Networks: Rethinking 1448 Enterprise Networks with IPv6 Segment Routing", 2018, 1449 . 1452 Authors' Addresses 1454 Clarence Filsfils (editor) 1455 Cisco Systems, Inc. 1456 Brussels 1457 BE 1459 Email: cfilsfil@cisco.com 1461 Darren Dukes (editor) 1462 Cisco Systems, Inc. 1463 Ottawa 1464 CA 1466 Email: ddukes@cisco.com 1468 Stefano Previdi 1469 Huawei 1470 Italy 1472 Email: stefano@previdi.net 1474 John Leddy 1475 Individual 1476 US 1478 Email: john@leddy.net 1480 Satoru Matsushima 1481 Softbank 1483 Email: satoru.matsushima@g.softbank.co.jp 1485 Daniel Voyer 1486 Bell Canada 1488 Email: daniel.voyer@bell.ca