idnits 2.17.00 (12 Aug 2021) /tmp/idnits3474/draft-ietf-6man-segment-routing-header-26.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 (October 22, 2019) is 935 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 887 -- Looks like a reference, but probably isn't: '8' on line 975 -- Looks like a reference, but probably isn't: '9' on line 975 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-02 Summary: 1 error (**), 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: April 24, 2020 S. Previdi 6 Huawei 7 J. Leddy 8 Individual 9 S. Matsushima 10 Softbank 11 D. Voyer 12 Bell Canada 13 October 22, 2019 15 IPv6 Segment Routing Header (SRH) 16 draft-ietf-6man-segment-routing-header-26 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 April 24, 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 . . . . . . . . . . . . . . . . . . . . . . 13 70 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 13 71 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 13 72 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . 23 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 . . . . . . . . . . . . . . . . 24 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 99 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 25 100 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 25 101 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 25 102 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 26 103 7.5. Applicability of AH . . . . . . . . . . . . . . . . . . . 26 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 105 8.1. Segment Routing Header Flags Registry . . . . . . . . . . 27 106 8.2. Segment Routing Header TLVs Registry . . . . . . . . . . 27 107 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . 31 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 that 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 codepoint from Segment Routing Header TLVs Registry 293 TBD IANA Reference. Unrecognized Types MUST be ignored on receipt. 295 Length: The length of the Variable length data in bytes. 297 Variable length data: Length bytes of data that is specific to the 298 Type. 300 Type Length Value (TLV) entries contain OPTIONAL information that may 301 be used by the node identified in the Destination Address (DA) of the 302 packet. 304 Each TLV has its own length, format and semantic. The codepoint 305 allocated (by IANA) to each TLV Type defines both the format and the 306 semantic of the information carried in the TLV. Multiple TLVs may be 307 encoded in the same SRH. 309 The highest-order bit of the TLV type (bit 0) specifies whether or 310 not the TLV data of that type can change en route to the packet's 311 final destination: 313 0: TLV data does not change en route 315 1: TLV data does change en route 317 All TLVs specify their alignment requirements using an xn+y format. 318 The xn+y format is defined as per [RFC8200]. The SR Source nodes use 319 the xn+y alignment requirements of TLVs and Padding TLVs when 320 constructing an SRH. 322 The "Length" field of the TLV is used to skip the TLV while 323 inspecting the SRH in case the node doesn't support or recognize the 324 Type. The "Length" defines the TLV length in octets, not including 325 the "Type" and "Length" fields. 327 The following TLVs are defined in this document: 329 Padding TLVs 331 HMAC TLV 333 Additional TLVs may be defined in the future. 335 2.1.1. Padding TLVs 337 There are two types of Padding TLVs, pad1 and padN, the following 338 applies to both: 340 Padding TLVs are used for meeting the alignment requirement of the 341 subsequent TLVs. 343 Padding TLVs are used to pad the SRH to a multiple of 8 octets. 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. A Pad1 TLV MUST NOT be used if more than one consecutive 362 byte of padding is required. 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 380 Padding: Length octets of padding. Padding bits have no semantic. 381 They MUST be set to 0 on transmission and ignored on 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 |D| RESERVED | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | HMAC Key ID (4 octets) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | // 401 | HMAC (Variable) // 402 | // 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 where: 407 o Type: to be assigned by IANA (suggested value 5). 409 o Length: The length of the variable length data in bytes. 411 o D: 1 bit. 1 indicates the Destination Address verification is 412 disabled due to use of reduced segment list, Section 4.1.1. 414 o RESERVED: 15 bits. MUST be 0 on transmission. 416 o HMAC Key ID: A 4 octet opaque number which uniquely identifies the 417 pre-shared key and algorithm used to generate the HMAC. 419 o HMAC: Keyed HMAC, in multiples of 8 octets, at most 32 octets. 421 The HMAC TLV is used to verify that the SRH applied to a packet was 422 selected by an authorized party, and to ensure that the segment list 423 is not modified after generation. This also allows for verification 424 that the current segment (by virtue of being in the authorized 425 segment list) is authorized for use. The SR Domain ensures the 426 source node is permitted to use the source address in the packet via 427 ingress filtering mechanisms as defined in BCP 84 [RFC3704], or other 428 strategies as appropriate. 430 2.1.2.1. HMAC Generation and Verification 432 Local configuration determines when to check for an HMAC. This local 433 configuration is outside the scope of this document. It may be based 434 on the active segment at an SR Segment endpoint node, the result of 435 an ACL that considers incoming interface, HMAC Key ID, or other 436 packet fields. 438 An implementation that supports the generation and verification of 439 the HMAC supports the following default behavior, as defined in the 440 remainder of this section. 442 The HMAC verification begins by checking the current segment is equal 443 to the destination address of the IPv6 header. The check is 444 successful when either 446 o HMAC D bit is 1 and Segments Left is greater than Last Entry. 448 o HMAC Segments Left is less than or equal to Last Entry and 449 destination address is equal to Segment List [Segments Left]. 451 The HMAC field is the output of the HMAC computation as defined in 452 [RFC2104], using: 454 o key: the pre-shared key identified by HMAC Key ID 456 o HMAC algorithm: identified by the HMAC Key ID 458 o Text: a concatenation of the following fields from the IPv6 header 459 and the SRH, as it would be received at the node verifying the 460 HMAC: 462 * IPv6 header: source address (16 octets) 464 * SRH: Last Entry (1 octet) 466 * SRH: Flags (1 octet) 468 * SRH: HMAC 16 bits following Length 470 * SRH: HMAC Key ID (4 octets) 472 * SRH: all addresses in the Segment List (variable octets) 474 The HMAC digest is truncated to 32 octets and placed in the HMAC 475 field of the HMAC TLV. 477 For HMAC algorithms producing digests less than 32 octets, the digest 478 is placed in the lowest order octets of the HMAC field. Subsequent 479 octets MUST be set to zero such that the HMAC length is a multiple of 480 8 octets. 482 If HMAC verification is successful, processing proceeds as normal. 484 If HMAC verification fails, an ICMP error message (parameter problem, 485 error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate 486 limited) and SHOULD be logged and the packet discarded. 488 2.1.2.2. HMAC Pre-Shared Key Algorithm 490 The HMAC Key ID field allows for the simultaneous existence of 491 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 492 well as pre-shared keys. 494 The HMAC Key ID field is opaque, i.e., it has neither syntax nor 495 semantic except as an identifier of the right combination of pre- 496 shared key and hash algorithm. 498 At the HMAC TLV generating and verification nodes, the Key ID 499 uniquely identifies the pre-shared key and HMAC algorithm. 501 At the HMAC TLV generating node, the Text for the HMAC computation is 502 set to the IPv6 header fields and SRH fields as they would appear at 503 the verification node(s), not necessarily the same as the source node 504 sending a packet with the HMAC TLV. 506 Pre-shared key roll-over is supported by having two key IDs in use 507 while the HMAC TLV generating node and verifying node converge to a 508 new key. 510 The HMAC TLV generating node may need to revoke an SRH for which it 511 previously generated an HMAC. Revocation is achieved by allocating a 512 new key and key ID, then rolling over the key ID associated with the 513 SRH to be revoked. The HMAC TLV verifying node drops packets with 514 the revoked SRH. 516 An implementation supporting HMAC can support multiple hash 517 functions. An implementation supporting HMAC MUST implement SHA-2 518 [FIPS180-4] in its SHA-256 variant. 520 The selection of pre-shared key and algorithm, and their distribution 521 is outside the scope of this document. Some options may include: 523 o in the configuration of the HMAC generating or verifying nodes, 524 either by static configuration or any SDN oriented approach 526 o dynamically using a trusted key distribution protocol such as 527 [RFC6407] 529 While key management is outside the scope of this document, the 530 recommendations of BCP 107 [RFC4107] should be considered when 531 choosing the key management system. 533 3. SR Nodes 535 There are different types of nodes that may be involved in segment 536 routing networks: source SR nodes originate packets with a segment in 537 the destination address of the IPv6 header, transit nodes that 538 forward packets destined to a remote segment, and SR segment endpoint 539 nodes that process a local segment in the destination address of an 540 IPv6 header. 542 3.1. Source SR Node 544 A Source SR Node is any node that originates an IPv6 packet with a 545 segment (i.e. SRv6 SID) in the destination address of the IPv6 546 header. The packet leaving the source SR Node may or may not contain 547 an SRH. This includes either: 549 A host originating an IPv6 packet. 551 An SR domain ingress router encapsulating a received packet in an 552 outer IPv6 header, followed by an optional SRH. 554 The mechanism through which a segment in the destination address of 555 the IPv6 header and the Segment List in the SRH, is derived is 556 outside the scope of this document. 558 3.2. Transit Node 560 A transit node is any node forwarding an IPv6 packet where the 561 destination address of that packet is not locally configured as a 562 segment nor a local interface. A transit node is not required to be 563 capable of processing a segment nor SRH. 565 3.3. SR Segment Endpoint Node 567 A SR segment endpoint node is any node receiving an IPv6 packet where 568 the destination address of that packet is locally configured as a 569 segment or local interface. 571 4. Packet Processing 573 This section describes SRv6 packet processing at the SR source, 574 Transit and SR segment endpoint nodes. 576 4.1. Source SR Node 578 A Source node steers a packet into an SR Policy. If the SR Policy 579 results in a segment list containing a single segment, and there is 580 no need to add information to the SRH flag or to add TLV, the DA is 581 set to the single segment list entry and the SRH MAY be omitted. 583 When needed, the SRH is created as follows: 585 Next Header and Hdr Ext Len fields are set as specified in 586 [RFC8200]. 588 Routing Type field is set as TBD (to be allocated by IANA, 589 suggested value 4). 591 The DA of the packet is set with the value of the first segment. 593 The first element of the SRH Segment List is the ultimate segment. 594 The second element is the penultimate segment, and so on. 596 The Segments Left field is set to n-1 where n is the number of 597 elements in the SR Policy. 599 The Last Entry field is set to n-1 where n is the number of 600 elements in the SR Policy. 602 TLVs (including HMAC) may be set according to their specification. 604 The packet is forwarded toward the packet's Destination Address 605 (the first segment). 607 4.1.1. Reduced SRH 609 When a source does not require the entire SID list to be preserved in 610 the SRH, a reduced SRH may be used. 612 A reduced SRH does not contain the first segment of the related SR 613 Policy (the first segment is the one already in the DA of the IPv6 614 header), and the Last Entry field is set to n-2 where n is the number 615 of elements in the SR Policy. 617 4.2. Transit Node 619 As specified in [RFC8200], the only node allowed to inspect the 620 Routing Extension Header (and therefore the SRH), is the node 621 corresponding to the DA of the packet. Any other transit node MUST 622 NOT inspect the underneath routing header and MUST forward the packet 623 toward the DA according to its IPv6 routing table. 625 When a SID is in the destination address of an IPv6 header of a 626 packet, it's routed through an IPv6 network as an IPv6 address. 627 SIDs, or the prefix(es) covering SIDs, and their reachability may be 628 distributed by means outside the scope of this document. For 629 example, [RFC5308] or [RFC5340] may be used to advertise a prefix 630 covering the SIDs on a node. 632 4.3. SR Segment Endpoint Node 634 Without constraining the details of an implementation, the SR segment 635 endpoint node creates Forwarding Information Base (FIB) entries for 636 its local SIDs. 638 When an SRv6-capable node receives an IPv6 packet, it performs a 639 longest-prefix-match lookup on the packets destination address. This 640 lookup can return any of the following: 642 * A FIB entry that represents a locally instantiated SRv6 SID 643 * A FIB entry that represents a local interface, not locally 644 instantiated as an SRv6 SID 645 * A FIB entry that represents a non-local route 646 * No Match 648 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID 650 This document, and section, defines a single SRv6 SID. Future 651 documents may define additional SRv6 SIDs. In which case, the entire 652 content of this section will be defined in that document. 654 If the FIB entry represents a locally instantiated SRv6 SID, process 655 the next header chain of the IPv6 header as defined in section 4 of 656 [RFC8200]. Section 4.3.1.1 describes how to process an SRH, 657 Section 4.3.1.2 describes how to process an upper layer header or no 658 next header. 660 Processing this SID modifies the Segments Left and, if configured to 661 process TLVs, it may modify the "variable length data" of TLV types 662 that change en route. Therefore Segments Left is mutable and TLVs 663 that change en route are mutable. The remainder of the SRH (Flags, 664 Tag, Segment List, and TLVs that do not change en route) are 665 immutable while processing this SID. 667 4.3.1.1. SRH Processing 669 S01. When an SRH is processed { 670 S02. If Segments Left is equal to zero { 671 S03. Proceed to process the next header in the packet, 672 whose type is identified by the Next Header field in 673 the Routing header. 674 S04. } 675 S05. Else { 676 S06. If local configuration requires TLV processing { 677 S07. Perform TLV processing (see TLV Processing) 678 S08. } 679 S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1 680 S10. If ((Last Entry > max_last_entry) or 681 S11. (Segments Left is greater than (Last Entry+1)) { 682 S12. Send an ICMP Parameter Problem, Code 0, message to 683 the Source Address, pointing to the Segments Left 684 field, and discard the packet. 685 S13. } 686 S14. Else { 687 S15. Decrement Segments Left by 1. 688 S16. Copy Segment List[Segments Left] from the SRH to the 689 destination address of the IPv6 header. 690 S17. If the IPv6 Hop Limit is less than or equal to 1 { 691 S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in 692 Transit message to the Source Address and discard 693 the packet. 694 S19. } 695 S20. Else { 696 S21. Decrement the Hop Limit by 1 697 S22. Resubmit the packet to the IPv6 module for transmission 698 to the new destination. 699 S23. } 700 S24. } 701 S25. } 702 S26. } 704 4.3.1.1.1. TLV Processing 706 Local configuration determines how TLVs are to be processed when the 707 Active Segment is a local SID defined in this document. The 708 definition of local configuration is outside the scope of this 709 document. 711 For illustration purpose only, two example local configurations that 712 may be associated with a SID are provided below. 714 Example 1: 715 For any packet received from interface I2 716 Skip TLV processing 718 Example 2: 719 For any packet received from interface I1 720 If first TLV is HMAC { 721 Process the HMAC TLV 722 } 723 Else { 724 Discard the packet 725 } 727 4.3.1.2. Upper-layer Header or No Next Header 729 When processing the Upper-layer header of a packet matching a FIB 730 entry locally instantiated as an SRv6 SID defined in this document. 732 IF (Upper-layer Header is IPv4 or IPv6) and 733 local configuration permits { 734 Perform IPv6 decapsulation 735 Resubmit the decapsulated packet to the IPv4 or IPv6 module 736 } 737 ELSE { 738 Send an ICMP parameter problem message to the Source Address and 739 discard the packet. Error code (TBD by IANA) "SR Upper-layer 740 Header Error", pointer set to the offset of the upper-layer 741 header. 742 } 744 A unique error code allows an SR Source node to recognize an error in 745 SID processing at an endpoint. 747 4.3.2. FIB Entry Is A Local Interface 749 If the FIB entry represents a local interface, not locally 750 instantiated as an SRv6 SID, the SRH is processed as follows: 752 If Segments Left is zero, the node must ignore the Routing header 753 and proceed to process the next header in the packet, whose type 754 is identified by the Next Header field in the Routing Header. 756 If Segments Left is non-zero, the node must discard the packet and 757 send an ICMP Parameter Problem, Code 0, message to the packet's 758 Source Address, pointing to the unrecognized Routing Type. 760 4.3.3. FIB Entry Is A Non-Local Route 762 Processing is not changed by this document. 764 4.3.4. FIB Entry Is A No Match 766 Processing is not changed by this document. 768 5. Intra SR Domain Deployment Model 770 The use of the SIDs exclusively within the SR Domain and solely for 771 packets of the SR Domain is an important deployment model. 773 This enables the SR Domain to act as a single routing system. 775 This section covers: 777 o securing the SR Domain from external attempt to use its SIDs 779 o SR Domain as a single system with delegation between components 781 o handling packets of the SR Domain 783 5.1. Securing the SR Domain 785 Nodes outside the SR Domain are not trusted: they cannot directly use 786 the SIDs of the domain. This is enforced by two levels of access 787 control lists: 789 1. Any packet entering the SR Domain and destined to a SID within 790 the SR Domain is dropped. This may be realized with the 791 following logic. Other methods with equivalent outcome are 792 considered compliant: 794 * allocate all the SID's from a block S/s 796 * configure each external interface of each edge node of the 797 domain with an inbound infrastructure access list (IACL) which 798 drops any incoming packet with a destination address in S/s 800 * Failure to implement this method of ingress filtering exposes 801 the SR Domain to source routing attacks as described and 802 referenced in [RFC5095] 804 2. The distributed protection in #1 is complemented with per node 805 protection, dropping packets to SIDs from source addresses 806 outside the SR Domain. This may be realized with the following 807 logic. Other methods with equivalent outcome are considered 808 compliant: 810 * assign all interface addresses from prefix A/a 812 * at node k, all SIDs local to k are assigned from prefix Sk/sk 814 * configure each internal interface of each SR node k in the SR 815 Domain with an inbound IACL which drops any incoming packet 816 with a destination address in Sk/sk if the source address is 817 not in A/a. 819 5.2. SR Domain as A Single System with Delegation Among Components 821 All intra SR Domain packets are of the SR Domain. The IPv6 header is 822 originated by a node of the SR Domain, and is destined to a node of 823 the SR Domain. 825 All inter domain packets are encapsulated for the part of the packet 826 journey that is within the SR Domain. The outer IPv6 header is 827 originated by a node of the SR Domain, and is destined to a node of 828 the SR Domain. 830 As a consequence, any packet within the SR Domain is of the SR 831 Domain. 833 The SR Domain is a system in which the operator may want to 834 distribute or delegate different operations of the outer most header 835 to different nodes within the system. 837 An operator of an SR domain may choose to delegate SRH addition to a 838 host node within the SR domain, and validation of the contents of any 839 SRH to a more trusted router or switch attached to the host. 840 Consider a top of rack switch (T) connected to host (H) via interface 841 (I). H receives an SRH (SRH1) with a computed HMAC via some SDN 842 method outside the scope of this document. H classifies traffic it 843 sources and adds SRH1 to traffic requiring a specific SLA. T is 844 configured with an IACL on I requiring verification of the SRH for 845 any packet destined to the SID block of the SR Domain (S/s). T 846 checks and verifies that SRH1 is valid, contains an HMAC TLV and 847 verifies the HMAC. 849 An operator of the SR Domain may choose to have all segments in the 850 SR Domain verify the HMAC. This mechanism would verify that the SRH 851 segment list is not modified while traversing the SR Domain. 853 5.3. MTU Considerations 855 An SR Domain ingress edge node encapsulates packets traversing the SR 856 Domain, and needs to consider the MTU of the SR Domain. Within the 857 SR Domain, well known mitigation techniques are RECOMMENDED, such as 858 deploying a greater MTU value within the SR Domain than at the 859 ingress edges. 861 Encapsulation with an outer IPv6 header and SRH share the same MTU 862 and fragmentation considerations as IPv6 tunnels described in 863 [RFC2473]. Further investigation on the limitation of various 864 tunneling methods (including IPv6 tunnels) are discussed in 865 [I-D.ietf-intarea-tunnels] and SHOULD be considered by operators when 866 considering MTU within the SR Domain. 868 5.4. ICMP Error Processing 870 ICMP error packets generated within the SR Domain are sent to source 871 nodes within the SR Domain. The invoking packet in the ICMP error 872 message may contain an SRH. Since the destination address of a 873 packet with an SRH changes as each segment is processed, it may not 874 be the destination used by the socket or application that generated 875 the invoking packet. 877 For the source of an invoking packet to process the ICMP error 878 message, the ultimate destination address of the IPv6 header may be 879 required. The following logic is used to determine the destination 880 address for use by protocol error handlers. 882 o Walk all extension headers of the invoking IPv6 packet to the 883 routing extension header preceding the upper layer header. 885 * If routing header is type TBD IANA (SRH) 887 + The SID at Segment List[0] may be used as the destination 888 address of the invoking packet. 890 ICMP errors are then processed by upper layer transports as defined 891 in [RFC4443]. 893 For IP packets encapsulated in an outer IPv6 header, ICMP error 894 handling is as defined in [RFC2473]. 896 5.5. Load Balancing and ECMP 898 For any inter domain packet, the SR Source node MUST impose a flow 899 label computed based on the inner packet. The computation of the 900 flow label is as recommended in [RFC6438] for the sending Tunnel End 901 Point. 903 For any intra domain packet, the SR Source node SHOULD impose a flow 904 label computed as described in [RFC6437] to assist ECMP load 905 balancing at transit nodes incapable of computing a 5-tuple beyond 906 the SRH. 908 At any transit node within an SR domain, the flow label MUST be used 909 as defined in [RFC6438] to calculate the ECMP hash toward the 910 destination address. If flow label is not used, the transit node 911 would likely hash all packets between a pair of SR Edge nodes to the 912 same link. 914 At an SR segment endpoint node, the flow label MUST be used as 915 defined in [RFC6438] to calculate any ECMP hash used to forward the 916 processed packet to the next segment. 918 5.6. Other Deployments 920 Other deployment models and their implications on security, MTU, 921 HMAC, ICMP error processing and interaction with other extension 922 headers are outside the scope of this document. 924 6. Illustrations 926 This section provides illustrations of SRv6 packet processing at SR 927 source, transit and SR segment endpoint nodes. 929 6.1. Abstract Representation of an SRH 931 For a node k, its IPv6 address is represented as Ak, its SRv6 SID is 932 represented as Sk. 934 IPv6 headers are represented as the tuple of (source, destination). 935 For example, a packet with source address A1 and destination address 936 A2 is represented as (A1,A2). The payload of the packet is omitted. 938 An SR Policy is a list of segments. A list of segments is 939 represented as where S1 is the first SID to visit, S2 is 940 the second SID to visit and S3 is the last SID to visit. 942 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 944 o Source Address is SA, Destination Addresses is DA, and next-header 945 is SRH. 947 o SRH with SID list with SegmentsLeft = SL. 949 o Note the difference between the <> and () symbols. 950 represents a SID list where the leftmost segment is the first 951 segment. Whereas, (S3, S2, S1; SL) represents the same SID list 952 but encoded in the SRH Segment List format where the leftmost 953 segment is the last segment. When referring to an SR policy in a 954 high-level use-case, it is simpler to use the 955 notation. When referring to an illustration of detailed behavior, 956 the (S3, S2, S1; SL) notation is more convenient. 958 At its SR Policy headend, the Segment List results in SRH 959 (S3,S2,S1; SL=2) represented fully as: 961 Segments Left=2 962 Last Entry=2 963 Flags=0 964 Tag=0 965 Segment List[0]=S3 966 Segment List[1]=S2 967 Segment List[2]=S1 969 6.2. Example Topology 971 The following topology is used in examples below: 973 + * * * * * * * * * * * * * * * * * * * * + 975 * [8] [9] * 976 | | 977 * | | * 978 [1]----[3]--------[5]----------------[6]---------[4]---[2] 979 * | | * 980 | | 981 * | | * 982 +--------[7]-------+ 983 * * 985 + * * * * * * * SR Domain * * * * * * * + 987 Figure 3 989 o 3 and 4 are SR Domain edge routers 991 o 5, 6, and 7 are all SR Domain routers 993 o 8 and 9 are hosts within the SR Domain 995 o 1 and 2 are hosts outside the SR Domain 996 o The SR domain implements ingress filtering as per Section 5.1 and 997 no external packet can enter the domain with a destination address 998 equal to a segment of the domain. 1000 6.3. Source SR Node 1002 6.3.1. Intra SR Domain Packet 1004 When host 8 sends a packet to host 9 via an SR Policy the 1005 packet is 1007 P1: (A8,S7)(A9,S7; SL=1) 1009 6.3.1.1. Reduced Variant 1011 When host 8 sends a packet to host 9 via an SR Policy and it 1012 wants to use a reduced SRH, the packet is 1014 P2: (A8,S7)(A9; SL=1) 1016 6.3.2. Inter SR Domain Packet - Transit 1018 When host 1 sends a packet to host 2, the packet is 1020 P3: (A1,A2) 1022 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 1023 egress router 4 via an SR Policy . Router 3 encapsulates the 1024 received packet P3 in an outer header with an SRH. The packet is 1026 P4: (A3, S7)(S4, S7; SL=1)(A1, A2) 1028 If the SR Policy contains only one segment (the egress router 4), the 1029 ingress Router 3 encapsulates P3 into an outer header (A3, S4) 1030 without SRH. The packet is 1032 P5: (A3, S4)(A1, A2) 1034 6.3.2.1. Reduced Variant 1036 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 1037 egress router 4 via an SR Policy . If router 3 wants to use 1038 a reduced SRH, Router 3 encapsulates the received packet P3 in an 1039 outer header with a reduced SRH. The packet is 1041 P6: (A3, S7)(S4; SL=1)(A1, A2) 1043 6.3.3. Inter SR Domain Packet - Internal to External 1045 When host 8 sends a packet to host 1, the packet is encapsulated for 1046 the portion of its journey within the SR Domain. From 8 to 3 the 1047 packet is 1049 P7: (A8,S3)(A8,A1) 1051 In the opposite direction, the packet generated from 1 to 8 is 1053 P8: (A1,A8) 1055 At node 3 P8 is encapsulated for the portion of its journey within 1056 the SR domain, with the outer header destined to segment S8. 1057 Resulting in 1059 P9: (A3,S8)(A1,A8) 1061 At node 8 the outer IPv6 header is removed by S8 processing, then 1062 processed again when received by A8. 1064 6.4. Transit Node 1066 Nodes 5 acts as transit nodes for packet P1, and sends packet 1068 P1: (A8,S7)(A9,S7;SL=1) 1070 on the interface toward node 7. 1072 6.5. SR Segment Endpoint Node 1074 Node 7 receives packet P1 and, using the logic in Section 4.3.1, 1075 sends packet 1077 P7: (A8,A9)(A9,S7; SL=0) 1079 on the interface toward router 6. 1081 6.6. Delegation of Function with HMAC Verification 1083 This section describes how a function may be delegated within the SR 1084 Domain. In the following sections consider a host 8 connected to a 1085 top of rack 5. 1087 6.6.1. SID List Verification 1089 An operator may prefer to apply the SRH at source 8, while 5 verifies 1090 the SID list is valid. 1092 For illustration purpose, an SDN controller provides 8 an SRH 1093 terminating at node 9, with segment list , and HMAC TLV 1094 computed for the SRH. The HMAC key ID and key associated with the 1095 HMAC TLV is shared with 5. Node 8 does not know the key. Node 5 is 1096 configured with an IACL applied to the interface connected to 8, 1097 requiring HMAC verification for any packet destined to S/s. 1099 Node 8 originates packets with the received SRH including HMAC TLV. 1101 P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC) 1103 Node 5 receives and verifies the HMAC for the SRH, then forwards the 1104 packet to the next segment 1106 P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC) 1108 Node 6 receives 1110 P17:(A8,S6)(A9,S6,S7,S5;SL=1;HMAC) 1112 Node 9 receives 1114 P18:(A8,A9)(A9,S6,S7,S5;SL=0;HMAC) 1116 This use of an HMAC is particularly valuable within an enterprise 1117 based SR Domain [SRN]. 1119 7. Security Considerations 1121 This section reviews security considerations related to the SRH, 1122 given the SRH processing and deployment models discussed in this 1123 document. 1125 As described in Section 5, it is necessary to filter packets ingress 1126 to the SR Domain, destined to SIDs within the SR Domain (i.e., 1127 bearing a SID in the destination address). This ingress filtering is 1128 via an IACL at SR Domain ingress border nodes. Additional protection 1129 is applied via an IACL at each SR Segment Endpoint node, filtering 1130 packets not from within the SR Domain, destined to SIDs in the SR 1131 Domain. ACLs are easily supported for small numbers of prefixes, 1132 making summarization important, and when the prefixes requiring 1133 filtering is kept to a seldom changing set. 1135 Additionally, ingress filtering of IPv6 source addresses as 1136 recommended in BCP38 [RFC2827] SHOULD be used. 1138 7.1. Source Routing Attacks 1140 An SR domain implements distributed and per node protection as 1141 described in section 5.1. Additionally, domains deny traffic with 1142 spoofed addresses by implementing the recommendations in BCP 84 1143 [RFC3704]. 1145 Full implementation of the recommended protection blocks the attacks 1146 documented in [RFC5095] from outside the SR domain, including 1147 bypassing filtering devices, reaching otherwise unreachable Internet 1148 systems, network topology discovery, bandwidth exhaustion, and 1149 defeating anycast. 1151 Failure to implement distributed and per node protection allows 1152 attackers to bypass filtering devices and exposes the SR Domain to 1153 these attacks. 1155 Compromised nodes within the SR Domain may mount the attacks listed 1156 above along with other known attacks on IP networks (e.g. DOS/DDOS, 1157 topology discovery, man-in-the-middle, traffic interception/ 1158 siphoning). 1160 7.2. Service Theft 1162 Service theft is defined as the use of a service offered by the SR 1163 Domain by a node not authorized to use the service. 1165 Service theft is not a concern within the SR Domain as all SR Source 1166 nodes and SR segment endpoint nodes within the domain are able to 1167 utilize the services of the Domain. If a node outside the SR Domain 1168 learns of segments or a topological service within the SR domain, 1169 IACL filtering denies access to those segments. 1171 7.3. Topology Disclosure 1173 The SRH is unencrypted and may contain SIDs of some intermediate SR- 1174 nodes in the path towards the destination within the SR Domain. If 1175 packets can be snooped within the SR Domain, the SRH may reveal 1176 topology, traffic flows, and service usage. 1178 This is applicable within an SR Domain, but the disclosure is less 1179 relevant as an attacker has other means of learning topology, flows, 1180 and service usage. 1182 7.4. ICMP Generation 1184 The generation of ICMPv6 error messages may be used to attempt 1185 denial-of-service attacks by sending an error-causing destination 1186 address or SRH in back-to-back packets. An implementation that 1187 correctly follows Section 2.4 of [RFC4443] would be protected by the 1188 ICMPv6 rate-limiting mechanism. 1190 7.5. Applicability of AH 1192 The SR Domain is a trusted domain, as defined in [RFC8402] Section 2 1193 and Section 8.2. The SR Source is trusted to add an SRH (optionally 1194 verified as having been generated by a trusted source via the HMAC 1195 TLV in this document), and segments advertised within the domain are 1196 trusted to be accurate and advertised by trusted sources via a secure 1197 control plane. As such the SR Domain does not rely on the 1198 Authentication Header (AH) as defined in [RFC4302] to secure the SRH. 1200 The use of SRH with AH by an SR source node, and processing at a SR 1201 segment endpoint node is not defined in this document. Future 1202 documents may define use of SRH with AH and its processing. 1204 8. IANA Considerations 1206 This document makes the following registrations in the Internet 1207 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1208 maintained by IANA: 1210 Suggested Description Reference 1211 Value 1212 ---------------------------------------------------------- 1213 4 Segment Routing Header (SRH) This document 1215 This document makes the following registrations in "Type 4 - 1216 Parameter Problem" message of the "Internet Control Message Protocol 1217 version 6 (ICMPv6) Parameters" registry maintained by IANA: 1219 CODE NAME/DESCRIPTION 1220 ---------------------------------------------------------- 1221 TBD IANA SR Upper-layer Header Error 1223 This section provides guidance to the Internet Assigned Numbers 1224 Authority (IANA) regarding registration of values related to the SRH, 1225 in accordance with BCP 26, [RFC8126]. 1227 The following terms are used here with the meanings defined in BCP 1228 26: "namespace", "assigned value", "registration". 1230 The following policies are used here with the meanings defined in BCP 1231 26 [RFC8126]: "IETF Review". 1233 8.1. Segment Routing Header Flags Registry 1235 This document requests the creation of a new IANA managed registry to 1236 identify SRH Flags Bits. The registration procedure is "IETF 1237 Review". Suggested registry name is "Segment Routing Header Flags". 1238 Flags is 8 bits. 1240 8.2. Segment Routing Header TLVs Registry 1242 This document requests the creation of a new IANA managed registry to 1243 identify SRH TLVs. The registration procedure is "IETF Review". 1244 Suggested registry name is "Segment Routing Header TLVs". A TLV is 1245 identified through an unsigned 8 bit codepoint value, with assigned 1246 values 0-127 for TLVs that do not change en route, and 128-255 for 1247 TLVs that may change en route. The following codepoints are defined 1248 in this document: 1250 Assigned Description Reference 1251 Value 1252 ----------------------------------------------------- 1253 0 Pad1 TLV This document 1254 1 Reserved This document 1255 2 Reserved This document 1256 3 Reserved This document 1257 4 PadN TLV This document 1258 5 HMAC TLV This document 1259 6 Reserved This document 1260 124-126 Experimentation and Test This document 1261 127 Reserved This document 1262 252-254 Experimentation and Test This document 1263 255 Reserved This document 1265 Values 1,2,3,6 were defined in draft versions of this specification 1266 and are Reserved for backwards compatibility with early 1267 implementations and should not be reassigned. Values 127 and 255 are 1268 Reserved to allow for expansion of the Type field in future 1269 specifications if needed. 1271 9. Implementation Status 1273 This section is to be removed prior to publishing as an RFC. 1275 See [I-D.matsushima-spring-srv6-deployment-status] for updated 1276 deployment and interoperability reports. 1278 9.1. Linux 1280 Name: Linux Kernel v4.14 1282 Status: Production 1284 Implementation: adds SRH, performs END processing, supports HMAC TLV 1286 Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and 1287 [I-D.filsfils-spring-srv6-interop] 1289 9.2. Cisco Systems 1291 Name: IOS XR and IOS XE 1293 Status: Production (IOS XR), Pre-production (IOS XE) 1295 Implementation: adds SRH, performs END processing, no TLV processing 1297 Details: [I-D.filsfils-spring-srv6-interop] 1299 9.3. FD.io 1301 Name: VPP/Segment Routing for IPv6 1303 Status: Production 1305 Implementation: adds SRH, performs END processing, no TLV processing 1307 Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and 1308 [I-D.filsfils-spring-srv6-interop] 1310 9.4. Barefoot 1312 Name: Barefoot Networks Tofino NPU 1314 Status: Prototype 1316 Implementation: performs END processing, no TLV processing 1318 Details: [I-D.filsfils-spring-srv6-interop] 1320 9.5. Juniper 1322 Name: Juniper Networks Trio and vTrio NPU's 1324 Status: Prototype & Experimental 1325 Implementation: SRH insertion mode, Process SID where SID is an 1326 interface address, no TLV processing 1328 9.6. Huawei 1330 Name: Huawei Systems VRP Platform 1332 Status: Production 1334 Implementation: adds SRH, performs END processing, no TLV processing 1336 10. Contributors 1338 Kamran Raza, Zafar Ali, Brian Field, Daniel Bernier, Ida Leung, Jen 1339 Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk 1340 Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre 1341 Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta 1342 Maglione, James Connolly, Aloys Augustin contributed to the content 1343 of this document. 1345 11. Acknowledgements 1347 The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, 1348 Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, 1349 David Lebrun, Benjamin Kaduk, Frank Xialiang, Mirja Kuhlewind, Roman 1350 Danyliw, Joe Touch, and Magnus Westerlund for their comments to this 1351 document. 1353 12. References 1355 12.1. Normative References 1357 [FIPS180-4] 1358 National Institute of Standards and Technology, "FIPS 1359 180-4 Secure Hash Standard (SHS)", March 2012, 1360 . 1363 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1364 Hashing for Message Authentication", RFC 2104, 1365 DOI 10.17487/RFC2104, February 1997, 1366 . 1368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1369 Requirement Levels", BCP 14, RFC 2119, 1370 DOI 10.17487/RFC2119, March 1997, 1371 . 1373 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1374 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1375 December 1998, . 1377 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1378 Defeating Denial of Service Attacks which employ IP Source 1379 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1380 May 2000, . 1382 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1383 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 1384 2004, . 1386 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1387 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1388 June 2005, . 1390 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1391 DOI 10.17487/RFC4302, December 2005, 1392 . 1394 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1395 of Type 0 Routing Headers in IPv6", RFC 5095, 1396 DOI 10.17487/RFC5095, December 2007, 1397 . 1399 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1400 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1401 October 2011, . 1403 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1404 "IPv6 Flow Label Specification", RFC 6437, 1405 DOI 10.17487/RFC6437, November 2011, 1406 . 1408 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1409 for Equal Cost Multipath Routing and Link Aggregation in 1410 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1411 . 1413 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1414 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1415 May 2017, . 1417 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1418 (IPv6) Specification", STD 86, RFC 8200, 1419 DOI 10.17487/RFC8200, July 2017, 1420 . 1422 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1423 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1424 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1425 July 2018, . 1427 12.2. Informative References 1429 [I-D.filsfils-spring-srv6-interop] 1430 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 1431 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 1432 "SRv6 interoperability report", draft-filsfils-spring- 1433 srv6-interop-02 (work in progress), March 2019. 1435 [I-D.ietf-intarea-tunnels] 1436 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1437 Architecture", draft-ietf-intarea-tunnels-10 (work in 1438 progress), September 2019. 1440 [I-D.matsushima-spring-srv6-deployment-status] 1441 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 1442 Implementation and Deployment Status", draft-matsushima- 1443 spring-srv6-deployment-status-02 (work in progress), 1444 October 2019. 1446 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1447 Control Message Protocol (ICMPv6) for the Internet 1448 Protocol Version 6 (IPv6) Specification", STD 89, 1449 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1450 . 1452 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1453 DOI 10.17487/RFC5308, October 2008, 1454 . 1456 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1457 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1458 . 1460 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1461 Writing an IANA Considerations Section in RFCs", BCP 26, 1462 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1463 . 1465 [SRN] Lebrun, D., Jadin, M., Clad, F., Filsfils, C., and O. 1466 Bonaventure, "Software Resolved Networks: Rethinking 1467 Enterprise Networks with IPv6 Segment Routing", 2018, 1468 . 1471 Authors' Addresses 1473 Clarence Filsfils (editor) 1474 Cisco Systems, Inc. 1475 Brussels 1476 BE 1478 Email: cfilsfil@cisco.com 1480 Darren Dukes (editor) 1481 Cisco Systems, Inc. 1482 Ottawa 1483 CA 1485 Email: ddukes@cisco.com 1487 Stefano Previdi 1488 Huawei 1489 Italy 1491 Email: stefano@previdi.net 1493 John Leddy 1494 Individual 1495 US 1497 Email: john@leddy.net 1499 Satoru Matsushima 1500 Softbank 1502 Email: satoru.matsushima@g.softbank.co.jp 1504 Daniel Voyer 1505 Bell Canada 1507 Email: daniel.voyer@bell.ca