idnits 2.17.1 draft-ietf-6man-segment-routing-header-24.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 3, 2019) is 1666 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 879 -- Looks like a reference, but probably isn't: '8' on line 967 -- Looks like a reference, but probably isn't: '9' on line 967 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-10 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-01 Summary: 1 error (**), 0 flaws (~~), 3 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 5, 2020 S. Previdi 6 Huawei 7 J. Leddy 8 Individual 9 S. Matsushima 10 Softbank 11 D. Voyer 12 Bell Canada 13 October 3, 2019 15 IPv6 Segment Routing Header (SRH) 16 draft-ietf-6man-segment-routing-header-24 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 5, 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 . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . 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 Register . . . . . . . . . . 27 106 8.2. Segment Routing Header TLVs Register . . . . . . . . . . 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 Register 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 | 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 that the SRH applied to a packet was 420 selected by an authorized party, and to ensure that the segment list 421 is not modified after generation. This also allows for verification 422 that the current segment (by virtue of being in the authorized 423 segment list) is authorized for use. The SR Domain ensures the 424 source node is permitted to use the source address in the packet via 425 ingress filtering mechanisms as defined in BCP 84 [RFC3704], or other 426 strategies as appropriate. 428 2.1.2.1. HMAC Generation and Verification 430 Local configuration determines when to check for an HMAC and 431 potentially indicates what the HMAC protects, and a requirement on 432 where the HMAC TLV must appear (e.g. first TLV), and whether or not 433 to verify the destination address is equal to the current segment. 434 This local configuration is outside the scope of this document. It 435 may be based on the active segment at an SR Segment endpoint node, 436 the result of an ACL that considers incoming interface, HMAC Key ID, 437 or other packet fields. 439 An implementation that supports the generation and verification of 440 the HMAC SHOULD support the following default behavior as defined in 441 the remainder of this section. 443 The HMAC verification begins by checking the current segment is equal 444 to the destination address of the IPv6 header, i.e. destination 445 address is equal to Segment List [Segments Left] and Segments Left is 446 less than or equal to Last Segment+1. 448 The HMAC field is the output of the HMAC computation as defined in 449 [RFC2104], using: 451 o key: the pre-shared key identified by HMAC Key ID 453 o HMAC algorithm: identified by the HMAC Key ID 455 o Text: a concatenation of the following fields from the IPv6 header 456 and the SRH, as it would be received at the node verifying the 457 HMAC: 459 * IPv6 header: source address (16 octets) 461 * SRH: Last Entry (1 octet) 463 * SRH: Flags (1 octet) 465 * SRH: HMAC Key-id (4 octets) 467 * SRH: all addresses in the Segment List (variable octets) 469 The HMAC digest is truncated to 32 octets and placed in the HMAC 470 field of the HMAC TLV. 472 For HMAC algorithms producing digests less than 32 octets, the digest 473 is placed in the lowest order octets of the HMAC field. Remaining 474 octets MUST be set to zero. 476 If HMAC verification is successful, processing proceeds as normal. 478 If HMAC verification fails, an ICMP error message (parameter problem, 479 error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate 480 limited) and SHOULD be logged and the packet discarded. 482 2.1.2.2. HMAC Pre-Shared Key Algorithm 484 The HMAC Key ID field allows for the simultaneous existence of 485 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 486 well as pre-shared keys. 488 The HMAC Key ID field is opaque, i.e., it has neither syntax nor 489 semantic except as an identifier of the right combination of pre- 490 shared key and hash algorithm. 492 At the HMAC TLV gernerating and verification nodes, the Key ID 493 uniquely identifies the pre-shared key and HMAC algorithm. 495 At the HMAC TLV generating node, the Text for the HMAC computation is 496 set to the IPv6 header fields and SRH fields as they would appear at 497 the verification node, not necessarily the same as the source node 498 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 The HMAC TLV generating node may need to revoke an SRH for which it 505 previously generated an HMAC. Revocation is achieved by allocating a 506 new key and key ID, then rolling over the key ID associated with the 507 SRH to be revoked. The HMAC TLV verifying node drops packets with 508 the revoked SRH. 510 An implementation supporting HMAC can support multiple hash 511 functions. An implementation supporting HMAC MUST implement SHA-2 512 [FIPS180-4] in its SHA-256 variant. 514 The selection of pre-shared key and algorithm, and their distribution 515 is outside the scope of this document. Some options may include: 517 o in the configuration of the HMAC generating or verifying nodes, 518 either by static configuration or any SDN oriented approach 520 o dynamically using a trusted key distribution protocol such as 521 [RFC6407] 523 While key management is outside the scope of this document, the 524 recommendations of BCP 107 [RFC4107] should be considered when 525 choosing the key management system. 527 3. SR Nodes 529 There are different types of nodes that may be involved in segment 530 routing networks: source SR nodes originate packets with a segment in 531 the destination address of the IPv6 header, transit nodes that 532 forward packets destined to a remote segment, and SR segment endpoint 533 nodes that process a local segment in the destination address of an 534 IPv6 header. 536 3.1. Source SR Node 538 A Source SR Node is any node that originates an IPv6 packet with a 539 segment (i.e. SRv6 SID) in the destination address of the IPv6 540 header. The packet leaving the source SR Node may or may not contain 541 an SRH. This includes either: 543 A host originating an IPv6 packet. 545 An SR domain ingress router encapsulating a received packet in an 546 outer IPv6 header, followed by an optional SRH. 548 The mechanism through which a segment in the destination address of 549 the IPv6 header and the Segment List in the SRH, is derived is 550 outside the scope of this document. 552 3.2. Transit Node 554 A transit node is any node forwarding an IPv6 packet where the 555 destination address of that packet is not locally configured as a 556 segment nor a local interface. A transit node is not required to be 557 capable of processing a segment nor SRH. 559 3.3. SR Segment Endpoint Node 561 A SR segment endpoint node is any node receiving an IPv6 packet where 562 the destination address of that packet is locally configured as a 563 segment or local interface. 565 4. Packet Processing 567 This section describes SRv6 packet processing at the SR source, 568 Transit and SR segment endpoint nodes. 570 4.1. Source SR Node 572 A Source node steers a packet into an SR Policy. If the SR Policy 573 results in a segment list containing a single segment, and there is 574 no need to add information to the SRH flag or to add TLV, the DA is 575 set to the single segment list entry and the SRH MAY be omitted. 577 When needed, the SRH is created as follows: 579 Next Header and Hdr Ext Len fields are set as specified in 580 [RFC8200]. 582 Routing Type field is set as TBD (to be allocated by IANA, 583 suggested value 4). 585 The DA of the packet is set with the value of the first segment. 587 The first element of the SRH Segment List is the ultimate segment. 588 The second element is the penultimate segment, and so on. 590 The Segments Left field is set to n-1 where n is the number of 591 elements in the SR Policy. 593 The Last Entry field is set to n-1 where n is the number of 594 elements in the SR Policy. 596 TLVs (including HMAC) may be set according to their specification. 598 The packet is forwarded toward the packet's Destination Address 599 (the first segment). 601 4.1.1. Reduced SRH 603 When a source does not require the entire SID list to be preserved in 604 the SRH, a reduced SRH may be used. 606 A reduced SRH does not contain the first segment of the related SR 607 Policy (the first segment is the one already in the DA of the IPv6 608 header), and the Last Entry field is set to n-2 where n is the number 609 of elements in the SR Policy. 611 4.2. Transit Node 613 As specified in [RFC8200], the only node allowed to inspect the 614 Routing Extension Header (and therefore the SRH), is the node 615 corresponding to the DA of the packet. Any other transit node MUST 616 NOT inspect the underneath routing header and MUST forward the packet 617 toward the DA according to its IPv6 routing table. 619 When a SID is in the destination address of an IPv6 header of a 620 packet, it's routed through an IPv6 network as an IPv6 address. 621 SIDs, or the prefix(es) covering SIDs, and their reachability may be 622 distributed by means outside the scope of this document. For 623 example, [RFC5308] or [RFC5340] may be used to advertise a prefix 624 covering the SIDs on a node. 626 4.3. SR Segment Endpoint Node 628 Without constraining the details of an implementation, the SR segment 629 endpoint node creates Forwarding Information Base (FIB) entries for 630 its local SIDs. 632 When an SRv6-capable node receives an IPv6 packet, it performs a 633 longest-prefix-match lookup on the packets destination address. This 634 lookup can return any of the following: 636 * A FIB entry that represents a locally instantiated SRv6 SID 637 * A FIB entry that represents a local interface, not locally 638 instantiated as an SRv6 SID 639 * A FIB entry that represents a non-local route 640 * No Match 642 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID 644 This document, and section, defines a single SRv6 SID. Future 645 documents may define additional SRv6 SIDs. In which case, the entire 646 content of this section will be defined in that document. 648 If the FIB entry represents a locally instantiated SRv6 SID, process 649 the next header chain of the IPv6 header as defined in section 4 of 650 [RFC8200]. Section 4.3.1.1 describes how to process an SRH, 651 Section 4.3.1.2 describes how to process an upper layer header or no 652 next header. 654 Processing this SID modifies the Segments Left and, if configured to 655 process TLVs, it may modify the "variable length data" of TLV types 656 that change en route. Therefore Segments Left is mutable and TLVs 657 that change en route are mutable. The remainder of the SRH (Flags, 658 Tag, Segment List, and TLVs that do not change en route) are 659 immutable while processing this SID. 661 4.3.1.1. SRH Processing 662 S01. When an SRH is processed { 663 S02. If Segments Left is equal to zero { 664 S03. Proceed to process the next header in the packet, 665 whose type is identified by the Next Header field in 666 the Routing header. 667 S04. } 668 S05. Else { 669 S06. If local configuration requires TLV processing { 670 S07. Perform TLV processing (see TLV Processing) 671 S08. } 672 S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1 673 S10. If ((Last Entry > max_last_entry) or 674 S11. (Segments Left is greater than (Last Entry+1)) { 675 S12. Send an ICMP Parameter Problem, Code 0, message to 676 the Source Address, pointing to the Segments Left 677 field, and discard the packet. 678 S13. } 679 S14. Else { 680 S15. Decrement Segments Left by 1. 681 S16. Copy Segment List[Segments Left] from the SRH to the 682 destination address of the IPv6 header. 683 S17. If the IPv6 Hop Limit is less than or equal to 1 { 684 S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in 685 Transit message to the Source Address and discard 686 the packet. 687 S19. } 688 S20. Else { 689 S21. Decrement the Hop Limit by 1 690 S22. Resubmit the packet to the IPv6 module for transmission 691 to the new destination. 692 S23. } 693 S24. } 694 S25. } 695 S26. } 697 4.3.1.1.1. TLV Processing 699 Local configuration determines how TLVs are to be processed when the 700 Active Segment is a local SID defined in this document. The 701 definition of local configuration is outside the scope of this 702 document. 704 For illustration purpose only, two example local configurations that 705 may be associated with a SID are provided below. 707 Example 1: 708 For any packet received from interface I2 709 Skip TLV processing 711 Example 2: 712 For any packet received from interface I1 713 If first TLV is HMAC { 714 Process the HMAC TLV 715 } 716 Else { 717 Discard the packet 718 } 720 4.3.1.2. Upper-layer Header or No Next Header 722 When processing the Upper-layer header of a packet matching a FIB 723 entry locally instantiated as an SRv6 SID defined in this document. 725 IF (Upper-layer Header is IPv4 or IPv6) and 726 local configuration permits { 727 Perform IPv6 decapsulation 728 Resubmit the decapsulated packet to the IPv4 or IPv6 module 729 } 730 ELSE { 731 Send an ICMP parameter problem message to the Source Address and 732 discard the packet. Error code (TBD by IANA) "SR Upper-layer 733 Header Error", pointer set to the offset of the upper-layer 734 header. 735 } 737 A unique error code allows an SR Source node to recognize an error in 738 SID processing at an endpoint. 740 4.3.2. FIB Entry Is A Local Interface 742 If the FIB entry represents a local interface, not locally 743 instantiated as an SRv6 SID, the SRH is processed as follows: 745 If Segments Left is zero, the node must ignore the Routing header 746 and proceed to process the next header in the packet, whose type 747 is identified by the Next Header field in the Routing Header. 749 If Segments Left is non-zero, the node must discard the packet and 750 send an ICMP Parameter Problem, Code 0, message to the packet's 751 Source Address, pointing to the unrecognized Routing Type. 753 4.3.3. FIB Entry Is A Non-Local Route 755 Processing is not changed by this document. 757 4.3.4. FIB Entry Is A No Match 759 Processing is not changed by this document. 761 5. Intra SR Domain Deployment Model 763 The use of the SIDs exclusively within the SR Domain and solely for 764 packets of the SR Domain is an important deployment model. 766 This enables the SR Domain to act as a single routing system. 768 This section covers: 770 o securing the SR Domain from external attempt to use its SIDs 772 o SR Domain as a single system with delegation between components 774 o handling packets of the SR Domain 776 5.1. Securing the SR Domain 778 Nodes outside the SR Domain are not trusted: they cannot directly use 779 the SIDs of the domain. This is enforced by two levels of access 780 control lists: 782 1. Any packet entering the SR Domain and destined to a SID within 783 the SR Domain is dropped. This may be realized with the 784 following logic. Other methods with equivalent outcome are 785 considered compliant: 787 * allocate all the SID's from a block S/s 789 * configure each external interface of each edge node of the 790 domain with an inbound infrastructure access list (IACL) which 791 drops any incoming packet with a destination address in S/s 793 * Failure to implement this method of ingress filtering exposes 794 the SR Domain to source routing attacks as described and 795 referenced in [RFC5095] 797 2. The distributed protection in #1 is complemented with per node 798 protection, dropping packets to SIDs from source addresses 799 outside the SR Domain. This may be realized with the following 800 logic. Other methods with equivalent outcome are considered 801 compliant: 803 * assign all interface addresses from prefix A/a 805 * at node k, all SIDs local to k are assigned from prefix Sk/sk 807 * configure each internal interface of each SR node k in the SR 808 Domain with an inbound IACL which drops any incoming packet 809 with a destination address in Sk/sk if the source address is 810 not in A/a. 812 5.2. SR Domain as A Single System with Delegation Among Components 814 All intra SR Domain packets are of the SR Domain. The IPv6 header is 815 originated by a node of the SR Domain, and is destined to a node of 816 the SR Domain. 818 All inter domain packets are encapsulated for the part of the packet 819 journey that is within the SR Domain. The outer IPv6 header is 820 originated by a node of the SR Domain, and is destined to a node of 821 the SR Domain. 823 As a consequence, any packet within the SR Domain is of the SR 824 Domain. 826 The SR Domain is a system in which the operator may want to 827 distribute or delegate different operations of the outer most header 828 to different nodes within the system. 830 An operator of an SR domain may choose to delegate SRH addition to a 831 host node within the SR domain, and validation of the contents of any 832 SRH to a more trusted router or switch attached to the host. 833 Consider a top of rack switch (T) connected to host (H) via interface 834 (I). H receives an SRH (SRH1) with a computed HMAC via some SDN 835 method outside the scope of this document. H classifies traffic it 836 sources and adds SRH1 to traffic requiring a specific SLA. T is 837 configured with an IACL on I requiring verification of the SRH for 838 any packet destined to the SID block of the SR Domain (S/s). T 839 checks and verifies that SRH1 is valid, contains an HMAC TLV and 840 verifies the HMAC. 842 An operator of the SR Domain may choose to have all segments in the 843 SR Domain verify the HMAC. This mechanism would verify that the SRH 844 segment list is not modified while traversing the SR Domain. 846 5.3. MTU Considerations 848 An SR Domain ingress edge node encapsulates packets traversing the SR 849 Domain, and needs to consider the MTU of the SR Domain. Within the 850 SR Domain, well known mitigation techniques are RECOMMENDED, such as 851 deploying a greater MTU value within the SR Domain than at the 852 ingress edges. 854 Encapsulation with an outer IPv6 header and SRH share the same MTU 855 and fragmentation considerations as IPv6 tunnels described in 856 [RFC2473]. In addition there are known issues with IPv6 tunnels 857 documented in [I-D.ietf-intarea-tunnels] section 5.2 that SHOULD be 858 considered. 860 5.4. ICMP Error Processing 862 ICMP error packets generated within the SR Domain are sent to source 863 nodes within the SR Domain. The invoking packet in the ICMP error 864 message may contain an SRH. Since the destination address of a 865 packet with an SRH changes as each segment is processed, it may not 866 be the destination used by the socket or application that generated 867 the invoking packet. 869 For the source of an invoking packet to process the ICMP error 870 message, the ultimate destination address of the IPv6 header may be 871 required. The following logic is used to determine the destination 872 address for use by protocol error handlers. 874 o Walk all extension headers of the invoking IPv6 packet to the 875 routing extension header preceding the upper layer header. 877 * If routing header is type TBD IANA (SRH) 879 + The SID at Segment List[0] may be used as the destination 880 address of the invoking packet. 882 ICMP errors are then processed by upper layer transports as defined 883 in [RFC4443]. 885 For IP packets encapsulated in an outer IPv6 header, ICMP error 886 handling is as defined in [RFC2473]. 888 5.5. Load Balancing and ECMP 890 For any inter domain packet, the SR Source node MUST impose a flow 891 label computed based on the inner packet. The computation of the 892 flow label is as recommended in [RFC6438] for the sending Tunnel End 893 Point. 895 For any intra domain packet, the SR Source node SHOULD impose a flow 896 label computed as described in [RFC6437] to assist ECMP load 897 balancing at transit nodes incapable of computing a 5-tuple beyond 898 the SRH. 900 At any transit node within an SR domain, the flow label MUST be used 901 as defined in [RFC6438] to calculate the ECMP hash toward the 902 destination address. If flow label is not used, the transit node 903 would likely hash all packets between a pair of SR Edge nodes to the 904 same link. 906 At an SR segment endpoint node, the flow label MUST be used as 907 defined in [RFC6438] to calculate any ECMP hash used to forward the 908 processed packet to the next segment. 910 5.6. Other Deployments 912 Other deployment models and their implications on security, MTU, 913 HMAC, ICMP error processing and interaction with other extension 914 headers are outside the scope of this document. 916 6. Illustrations 918 This section provides illustrations of SRv6 packet processing at SR 919 source, transit and SR segment endpoint nodes. 921 6.1. Abstract Representation of an SRH 923 For a node k, its IPv6 address is represented as Ak, its SRv6 SID is 924 represented as Sk. 926 IPv6 headers are represented as the tuple of (source, destination). 927 For example, a packet with source address A1 and destination address 928 A2 is represented as (A1,A2). The payload of the packet is omitted. 930 An SR Policy is a list of segments. A list of segments is 931 represented as where S1 is the first SID to visit, S2 is 932 the second SID to visit and S3 is the last SID to visit. 934 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 936 o Source Address is SA, Destination Addresses is DA, and next-header 937 is SRH. 939 o SRH with SID list with SegmentsLeft = SL. 941 o Note the difference between the <> and () symbols. 942 represents a SID list where the leftmost segment is the first 943 segment. Whereas, (S3, S2, S1; SL) represents the same SID list 944 but encoded in the SRH Segment List format where the leftmost 945 segment is the last segment. When referring to an SR policy in a 946 high-level use-case, it is simpler to use the 947 notation. When referring to an illustration of detailed behavior, 948 the (S3, S2, S1; SL) notation is more convenient. 950 At its SR Policy headend, the Segment List results in SRH 951 (S3,S2,S1; SL=2) represented fully as: 953 Segments Left=2 954 Last Entry=2 955 Flags=0 956 Tag=0 957 Segment List[0]=S3 958 Segment List[1]=S2 959 Segment List[2]=S1 961 6.2. Example Topology 963 The following topology is used in examples below: 965 + * * * * * * * * * * * * * * * * * * * * + 967 * [8] [9] * 968 | | 969 * | | * 970 [1]----[3]--------[5]----------------[6]---------[4]---[2] 971 * | | * 972 | | 973 * | | * 974 +--------[7]-------+ 975 * * 977 + * * * * * * * SR Domain * * * * * * * + 979 Figure 3 981 o 3 and 4 are SR Domain edge routers 983 o 5, 6, and 7 are all SR Domain routers 985 o 8 and 9 are hosts within the SR Domain 987 o 1 and 2 are hosts outside the SR Domain 988 o The SR domain implements ingress filtering as per Section 5.1 and 989 no external packet can enter the domain with a destination address 990 equal to a segment of the domain. 992 6.3. Source SR Node 994 6.3.1. Intra SR Domain Packet 996 When host 8 sends a packet to host 9 via an SR Policy the 997 packet is 999 P1: (A8,S7)(A9,S7; SL=1) 1001 6.3.1.1. Reduced Variant 1003 When host 8 sends a packet to host 9 via an SR Policy and it 1004 wants to use a reduced SRH, the packet is 1006 P2: (A8,S7)(A9; SL=1) 1008 6.3.2. Inter SR Domain Packet - Transit 1010 When host 1 sends a packet to host 2, the packet is 1012 P3: (A1,A2) 1014 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 1015 egress router 4 via an SR Policy . Router 3 encapsulates the 1016 received packet P3 in an outer header with an SRH. The packet is 1018 P4: (A3, S7)(S4, S7; SL=1)(A1, A2) 1020 If the SR Policy contains only one segment (the egress router 4), the 1021 ingress Router 3 encapsulates P3 into an outer header (A3, S4) 1022 without SRH. The packet is 1024 P5: (A3, S4)(A1, A2) 1026 6.3.2.1. Reduced Variant 1028 The SR Domain ingress router 3 receives P3 and steers it to SR Domain 1029 egress router 4 via an SR Policy . If router 3 wants to use 1030 a reduced SRH, Router 3 encapsulates the received packet P3 in an 1031 outer header with a reduced SRH. The packet is 1033 P6: (A3, S7)(S4; SL=1)(A1, A2) 1035 6.3.3. Inter SR Domain Packet - Internal to External 1037 When host 8 sends a packet to host 1, the packet is encapsulated for 1038 the portion of its journey within the SR Domain. From 8 to 3 the 1039 packet is 1041 P7: (A8,S3)(A8,A1) 1043 In the opposite direction, the packet generated from 1 to 8 is 1045 P8: (A1,A8) 1047 At node 3 P8 is encapsulated for the portion of its journey within 1048 the SR domain, with the outer header destined to segment S8. 1049 Resulting in 1051 P9: (A3,S8)(A1,A8) 1053 At node 8 the outer IPv6 header is removed by S8 processing, then 1054 processed again when received by A8. 1056 6.4. Transit Node 1058 Nodes 5 acts as transit nodes for packet P1, and sends packet 1060 P1: (A8,S7)(A9,S7;SL=1) 1062 on the interface toward node 7. 1064 6.5. SR Segment Endpoint Node 1066 Node 7 receives packet P1 and, using the logic in Section 4.3.1, 1067 sends packet 1069 P7: (A8,A9)(A9,S7; SL=0) 1071 on the interface toward router 6. 1073 6.6. Delegation of Function with HMAC Verification 1075 This section describes how a function may be delegated within the SR 1076 Domain. In the following sections consider a host 8 connected to a 1077 top of rack 5. 1079 6.6.1. SID List Verification 1081 An operator may prefer to apply the SRH at source 8, while 5 verifies 1082 the SID list is valid. 1084 For illustration purpose, an SDN controller provides 8 an SRH 1085 terminating at node 9, with segment list , and HMAC TLV 1086 computed for the SRH. The HMAC key ID and key associated with the 1087 HMAC TLV is shared with 5. Node 8 does not know the key. Node 5 is 1088 configured with an IACL applied to the interface connected to 8, 1089 requiring HMAC verification for any packet destined to S/s. 1091 Node 8 originates packets with the received SRH including HMAC TLV. 1093 P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC) 1095 Node 5 receives and verifies the HMAC for the SRH, then forwards the 1096 packet to the next segment 1098 P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC) 1100 Node 6 receives 1102 P17:(A8,S6)(A9,S6,S7,S5;SL=1;HMAC) 1104 Node 9 receives 1106 P18:(A8,A9)(A9,S6,S7,S5;SL=0;HMAC) 1108 This use of an HMAC is particularly valuable within an enterprise 1109 based SR Domain [SRN]. 1111 7. Security Considerations 1113 This section reviews security considerations related to the SRH, 1114 given the SRH processing and deployment models discussed in this 1115 document. 1117 As described in Section 5, it is necessary to filter packets ingress 1118 to the SR Domain, destined to SIDs within the SR Domain (i.e., 1119 bearing a SID in the destination address). This ingress filtering is 1120 via an IACL at SR Domain ingress border nodes. Additional protection 1121 is applied via an IACL at each SR Segment Endpoint node, filtering 1122 packets not from within the SR Domain, destined to SIDs in the SR 1123 Domain. ACLs are easily supported for small numbers of prefixes, 1124 making summarization important, and when the prefixes requiring 1125 filtering is kept to a seldom changing set. 1127 Additionally, ingress filtering of IPv6 source addresses as 1128 recommended in BCP38 [RFC2827] SHOULD be used. 1130 7.1. Source Routing Attacks 1132 [RFC5095] deprecates the Type 0 Routing header due to a number of 1133 significant attacks that are referenced in that document. Such 1134 attacks include bypassing filtering devices, reaching otherwise 1135 unreachable Internet systems, network topology discovery, bandwidth 1136 exhaustion, and defeating anycast. 1138 Because this document specifies that the SRH is for use within an SR 1139 domain protected by ingress filtering via IACLs; such attacks cannot 1140 be mounted from outside an SR Domain. As specified in this document, 1141 SR Domain ingress edge nodes drop packets entering the SR Domain 1142 destined to segments within the SR Domain. 1144 Additionally, this document specifies the use of IACL on SR Segment 1145 Endpoint nodes within the SR Domain to limit the source addresses 1146 permitted to send packets to a SID in the SR Domain. 1148 Such attacks may, however, be mounted from within the SR Domain, from 1149 nodes permitted to source traffic to SIDs in the domain. As such, 1150 these attacks and other known attacks on an IP network (e.g. DOS/ 1151 DDOS, topology discovery, man-in-the-middle, traffic interception/ 1152 siphoning), can occur from compromised nodes within an SR Domain. 1154 7.2. Service Theft 1156 Service theft is defined as the use of a service offered by the SR 1157 Domain by a node not authorized to use the service. 1159 Service theft is not a concern within the SR Domain as all SR Source 1160 nodes and SR segment endpoint nodes within the domain are able to 1161 utilize the services of the Domain. If a node outside the SR Domain 1162 learns of segments or a topological service within the SR domain, 1163 IACL filtering denies access to those segments. 1165 7.3. Topology Disclosure 1167 The SRH is unencrypted and may contain SIDs of some intermediate SR- 1168 nodes in the path towards the destination within the SR Domain. If 1169 packets can be snooped within the SR Domain, the SRH may reveal 1170 topology, traffic flows, and service usage. 1172 This is applicable within an SR Domain, but the disclosure is less 1173 relevant as an attacker has other means of learning topology, flows, 1174 and service usage. 1176 7.4. ICMP Generation 1178 The generation of ICMPv6 error messages may be used to attempt 1179 denial-of-service attacks by sending an error-causing destination 1180 address or SRH in back-to-back packets. An implementation that 1181 correctly follows Section 2.4 of [RFC4443] would be protected by the 1182 ICMPv6 rate-limiting mechanism. 1184 7.5. Applicability of AH 1186 The SR Domain is a trusted domain, as defined in [RFC8402] Section 2 1187 and Section 8.2. The SR Source is trusted to add an SRH (optionally 1188 verified as having been generated by a trusted source via the HMAC 1189 TLV in this document), and segments advertised within the domain are 1190 trusted to be accurate and advertised by trusted sources via a secure 1191 control plane. As such the SR Domain does not rely on the 1192 Authentication Header (AH) as defined in [RFC4302] to secure the SRH. 1194 The use of SRH with AH by an SR source node, and processing at a SR 1195 segment endpoint node is not defined in this document. Future 1196 documents may define use of SRH with AH and its processing. 1198 8. IANA Considerations 1200 This document makes the following registrations in the Internet 1201 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1202 maintained by IANA: 1204 Suggested Description Reference 1205 Value 1206 ---------------------------------------------------------- 1207 4 Segment Routing Header (SRH) This document 1209 This document makes the following registrations in "Type 4 - 1210 Parameter Problem" message of the "Internet Control Message Protocol 1211 version 6 (ICMPv6) Parameters" registry maintained by IANA: 1213 CODE NAME/DESCRIPTION 1214 ---------------------------------------------------------- 1215 TBD IANA SR Upper-layer Header Error 1217 This section provides guidance to the Internet Assigned Numbers 1218 Authority (IANA) regarding registration of values related to the SRH, 1219 in accordance with BCP 26, [RFC8126]. 1221 The following terms are used here with the meanings defined in BCP 1222 26: "namespace", "assigned value", "registration". 1224 The following policies are used here with the meanings defined in BCP 1225 26 [RFC8126]: "IETF Review". 1227 8.1. Segment Routing Header Flags Register 1229 This document requests the creation of a new IANA managed registry to 1230 identify SRH Flags Bits. The registration procedure is "IETF 1231 Review". Suggested registry name is "Segment Routing Header Flags". 1232 Flags is 8 bits. 1234 8.2. Segment Routing Header TLVs Register 1236 This document requests the creation of a new IANA managed registry to 1237 identify SRH TLVs. The registration procedure is "IETF Review". 1238 Suggested registry name is "Segment Routing Header TLVs". A TLV is 1239 identified through an unsigned 8 bit codepoint value, with assigned 1240 values 0-127 for TLVs that do not change en route, and 128-255 for 1241 TLVs that may change en route. The following codepoints are defined 1242 in this document: 1244 Assigned Description Reference 1245 Value 1246 ----------------------------------------------------- 1247 0 Pad1 TLV This document 1248 1 Reserved This document 1249 2 Reserved This document 1250 3 Reserved This document 1251 4 PadN TLV This document 1252 5 HMAC TLV This document 1253 6 Reserved This document 1254 124-126 Experimentation and Test This document 1255 127 Reserved This document 1256 252-254 Experimentation and Test This document 1257 255 Reserved This document 1259 Values 1,2,3,6 were defined in draft versions of this specification 1260 and are Reserved for backwards compatibility with early 1261 implementations and should not be reassigned. Values 127 and 255 are 1262 Reserved to allow for expansion of the Type field in future 1263 specifications if needed. 1265 9. Implementation Status 1267 This section is to be removed prior to publishing as an RFC. 1269 See [I-D.matsushima-spring-srv6-deployment-status] for updated 1270 deployment and interoperability reports. 1272 9.1. Linux 1274 Name: Linux Kernel v4.14 1276 Status: Production 1278 Implementation: adds SRH, performs END processing, supports HMAC TLV 1280 Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and 1281 [I-D.filsfils-spring-srv6-interop] 1283 9.2. Cisco Systems 1285 Name: IOS XR and IOS XE 1287 Status: Production (IOS XR), Pre-production (IOS XE) 1289 Implementation: adds SRH, performs END processing, no TLV processing 1291 Details: [I-D.filsfils-spring-srv6-interop] 1293 9.3. FD.io 1295 Name: VPP/Segment Routing for IPv6 1297 Status: Production 1299 Implementation: adds SRH, performs END processing, no TLV processing 1301 Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and 1302 [I-D.filsfils-spring-srv6-interop] 1304 9.4. Barefoot 1306 Name: Barefoot Networks Tofino NPU 1308 Status: Prototype 1310 Implementation: performs END processing, no TLV processing 1312 Details: [I-D.filsfils-spring-srv6-interop] 1314 9.5. Juniper 1316 Name: Juniper Networks Trio and vTrio NPU's 1318 Status: Prototype & Experimental 1319 Implementation: SRH insertion mode, Process SID where SID is an 1320 interface address, no TLV processing 1322 9.6. Huawei 1324 Name: Huawei Systems VRP Platform 1326 Status: Production 1328 Implementation: adds SRH, performs END processing, no TLV processing 1330 10. Contributors 1332 Kamran Raza, Zafar Ali, Brian Field, Daniel Bernier, Ida Leung, Jen 1333 Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk 1334 Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre 1335 Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta 1336 Maglione, James Connolly, Aloys Augustin contributed to the content 1337 of this document. 1339 11. Acknowledgements 1341 The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, 1342 Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, 1343 David Lebrun, Benjamin Kaduk, Frank Xialiang, Mirja Kuhlewind, Roman 1344 Danyliw, Joe Touch, and Magnus Westerlund for their comments to this 1345 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 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1358 Hashing for Message Authentication", RFC 2104, 1359 DOI 10.17487/RFC2104, February 1997, 1360 . 1362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1363 Requirement Levels", BCP 14, RFC 2119, 1364 DOI 10.17487/RFC2119, March 1997, 1365 . 1367 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1368 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1369 December 1998, . 1371 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1372 Defeating Denial of Service Attacks which employ IP Source 1373 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1374 May 2000, . 1376 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1377 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 1378 2004, . 1380 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1381 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1382 June 2005, . 1384 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1385 DOI 10.17487/RFC4302, December 2005, 1386 . 1388 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1389 of Type 0 Routing Headers in IPv6", RFC 5095, 1390 DOI 10.17487/RFC5095, December 2007, 1391 . 1393 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1394 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1395 October 2011, . 1397 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1398 "IPv6 Flow Label Specification", RFC 6437, 1399 DOI 10.17487/RFC6437, November 2011, 1400 . 1402 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1403 for Equal Cost Multipath Routing and Link Aggregation in 1404 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1405 . 1407 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1408 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1409 May 2017, . 1411 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1412 (IPv6) Specification", STD 86, RFC 8200, 1413 DOI 10.17487/RFC8200, July 2017, 1414 . 1416 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1417 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1418 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1419 July 2018, . 1421 12.2. Informative References 1423 [I-D.filsfils-spring-srv6-interop] 1424 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 1425 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 1426 "SRv6 interoperability report", draft-filsfils-spring- 1427 srv6-interop-02 (work in progress), March 2019. 1429 [I-D.ietf-intarea-tunnels] 1430 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1431 Architecture", draft-ietf-intarea-tunnels-10 (work in 1432 progress), September 2019. 1434 [I-D.matsushima-spring-srv6-deployment-status] 1435 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 1436 Implementation and Deployment Status", draft-matsushima- 1437 spring-srv6-deployment-status-01 (work in progress), May 1438 2019. 1440 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1441 Control Message Protocol (ICMPv6) for the Internet 1442 Protocol Version 6 (IPv6) Specification", STD 89, 1443 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1444 . 1446 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1447 DOI 10.17487/RFC5308, October 2008, 1448 . 1450 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1451 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1452 . 1454 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1455 Writing an IANA Considerations Section in RFCs", BCP 26, 1456 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1457 . 1459 [SRN] Lebrun, D., Jadin, M., Clad, F., Filsfils, C., and O. 1460 Bonaventure, "Software Resolved Networks: Rethinking 1461 Enterprise Networks with IPv6 Segment Routing", 2018, 1462 . 1465 Authors' Addresses 1467 Clarence Filsfils (editor) 1468 Cisco Systems, Inc. 1469 Brussels 1470 BE 1472 Email: cfilsfil@cisco.com 1474 Darren Dukes (editor) 1475 Cisco Systems, Inc. 1476 Ottawa 1477 CA 1479 Email: ddukes@cisco.com 1481 Stefano Previdi 1482 Huawei 1483 Italy 1485 Email: stefano@previdi.net 1487 John Leddy 1488 Individual 1489 US 1491 Email: john@leddy.net 1493 Satoru Matsushima 1494 Softbank 1496 Email: satoru.matsushima@g.softbank.co.jp 1498 Daniel Voyer 1499 Bell Canada 1501 Email: daniel.voyer@bell.ca