idnits 2.17.00 (12 Aug 2021) /tmp/idnits24436/draft-ietf-6man-sids-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8754], [RFC4291], [RFC8986]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 125: '... interfaces annd MUST conform to [RFC4291]. So, the following...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (14 April 2022) is 30 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-ietf-spring-compression-analysis-00 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man S. Krishnan 3 Internet-Draft Cisco 4 Intended status: Informational 14 April 2022 5 Expires: 16 October 2022 7 Segment Identifiers in SRv6 8 draft-ietf-6man-sids-00 10 Abstract 12 The data plane for Segment Routing over IPv6 (SRv6) [RFC8754] is 13 built using IPv6 as the underlying forwarding plane. Due to this 14 underlying use of IPv6, Segment Identifiers (SIDs) used by SRv6 can 15 resemble IPv6 addresses and behave like them [RFC8754][RFC8986] while 16 exhibiting slightly different behaviors in some situations. This 17 document intends to explore the characteristics of SRv6 SIDs and to 18 clarify the relationship of SRv6 SIDs to the IPv6 Addressing 19 Architecture [RFC4291]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 16 October 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. SRv6 SIDs and the IPv6 addressing architecture . . . . . . . 3 57 4. Special Considerations for Compressed SIDs . . . . . . . . . 4 58 4.1. Open Issues to be Addressed with C-SIDs . . . . . . . . . 5 59 4.2. Applicability to other forms of compressed SIDs . . . . . 5 60 5. Allocation of a Global Unicast Prefix for SIDs . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 9.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 Segment Routing over IPv6 (SRv6) [RFC8754] uses IPv6 as the 72 underlying data plane. In SRv6, SR source nodes initiate packets 73 with a segment in the Destination Address of the IPv6 header, and SR 74 segment endpoint nodes that process a local segment present the 75 Destination Address of an IPv6 header. Thus Segment Identifiers 76 (SIDs) in SRv6 can and do appear in the Destination Address field of 77 IPv6 datagrams by design. 79 2. Terminology 81 The following terms are used as defined in [RFC8402]. 83 * Segment Routing (SR) 85 * SR Domain 87 * Segment 89 * Segment ID (SID) 90 * SRv6 92 * SRv6 SID 94 * SR Policy. 96 The following terms are used as defined in [RFC8754]. 98 * Segment Routing Header (SRH) 100 * SR Source Node 102 * Transit Node 104 * SR Segment Endpoint Node 106 * Reduced SRH 108 * Segments Left 110 * Last Entry 112 3. SRv6 SIDs and the IPv6 addressing architecture 114 [RFC8754] defines the Segment List of the SRH as a contiguous array 115 of 128-bit IPv6 addresses, and that each of the elements in this list 116 are SIDs. But all of these elements are not necessarily made equal. 117 Some of these elements may represent a local interface as described 118 in Section 4.3 of [RFC8754] as "A FIB entry that represents a local 119 interface, not locally instantiated as an SRv6 SID". From this it 120 follows that all the SIDs that appear in the SRH are not SRv6 SIDs as 121 defined by [RFC8402]. 123 It is also fairly clear that the non-SRv6-SID elements that appear in 124 the SRH SID list are simply IPv6 addresses assigned to local 125 interfaces annd MUST conform to [RFC4291]. So, the following 126 discussions are intended to be applicable solely to SRv6 SIDs that 127 are not assigned to local interfaces. 129 One of the key questions to address is how these SRv6 SIDs appearing 130 as IPv6 Destination Addresses are perceived and treated by "transit 131 nodes" (that are not required to be capable of processing a Segment 132 or the Segment Routing Header). 134 Section 3.1. of [RFC8986] describes the format of an SRv6 SID as 135 composed of three parts LOC:FUNCT:ARG, where a locator (LOC) is 136 encoded in the L most significant bits of the SID, followed by F bits 137 of function (FUNCT) and A bits of arguments (ARG). Such a SID is 138 assigned to a node within a prefix defined as a Locator of length L. 139 When an SRv6 SID occurs in the IPv6 destination address field of an 140 IPv6 header, only the longest match prefix corresponding to the 141 locator is used to forward the packet to the node identified by the 142 Locator. 144 It is clear that this format for SRv6 SIDs is not compliant with the 145 requirements set forth in [RFC4291] for IPv6 addresses but it is also 146 clear that SRv6 SIDs are not intended for assignment onto interfaces 147 on end hosts. They look and act similar to other mechanisms that use 148 IPv6 addresses with different formats such as [RFC6052] that defines 149 the IPv6 Addressing of IPv4/IPv6 Translators and [RFC7343] that 150 describes ORCHIDv2 (a cryptographic hash identifier format). 152 While looking at the transit nodes it becomes apparent that these 153 addresses are used purely for routing and not for packet delivery to 154 end hosts. Hence the relevant standard to apply here is [RFC7608] 155 that allows the use of variable length prefixes in forwarding while 156 explicitly decoupling IPv6 routing and forwarding from the IPv6 157 address/prefix semantics described in [RFC4291]. Please note that 158 [RFC7608] does not override the rules in [RFC4291], but merely limits 159 where their impact is observed 161 Furthermore, in the SRv6 specifications, all SIDs assigned within a 162 given Locator prefix are located inside the node identified by 163 Locator. Therefore there does not appear to be a conflict with 164 section 2.6.1 of [RFC4291] since subnet-router anycast addresses are 165 neither required nor useful within a node. 167 4. Special Considerations for Compressed SIDs 169 The C-SID document [I-D.filsfilscheng-spring-srv6-srh-compression] 170 describes how to use a single entry in the SRH list as a container 171 for multiple SIDs and defines a few flavors of how to do so. A node 172 taking part in this mechanism accomplishes this by using the ARG part 173 [RFC8986] of the Destination address field of the IPv6 header to come 174 up with a new Destination address in some of these flavors. i.e. The 175 destination address field of the packet changes on the fly in a way 176 similar to how the address changes as the result of processing a 177 segment in the SRH. 179 One key thing to note in here is that the Locator Block at the 180 beginning of the address does not get modified by the operations 181 needed for supporting compressed SIDs. As we have established that 182 the SRv6 SIDs are being treated simply as routing prefixes on transit 183 nodes this does not constitute a modification to the IPv6 data plane 184 on such transit nodes and any changes are restricted to SR aware 185 nodes. 187 4.1. Open Issues to be Addressed with C-SIDs 189 There are a few issues that need to be addressed in the C-SID draft 190 prior to its publication as RFC: 192 * This draft needs to provide an updated definition for the 193 SegmentsLeft field of the SRH since the current definition in 194 [RFC8754][RFC8200] no longer holds true in the presence of C-SIDs. 196 * In some cases it is possible that the SR policy can be expressed 197 purely with C-SIDs without requiring an SRH. In this case, to 198 allow the SR domain to fail closed, some form of filtering based 199 on the LOC part of the SRv6 SID is required as relying purely on 200 the presence of an SRH will not be sufficient. 202 * The use of C-SIDs might cause some difficulty in troubleshooting 203 error conditions signaled by ICMPv6. Section 5.4 of [RFC8754] 204 describes the ICMPv6 error processing that is required to be 205 performed on the SR Source Nodes to correlate packets since the 206 Destination Address field of the packet changes in flight. 207 Similar logic needs to be specified for SR Source Nodes that use 208 C-SIDs to determine the destination address for use by protocol- 209 error handlers. 211 4.2. Applicability to other forms of compressed SIDs 213 The spring working group is in the process of analyzing multiple 214 mechanisms for compressing the SRv6 SID list as described in 215 [I-D.ietf-spring-compression-analysis]. Even though this document 216 focuses on [I-D.filsfilscheng-spring-srv6-srh-compression], the 217 considerations specified in this document might also be applicable to 218 the other mechanisms being analyzed and compared. 220 5. Allocation of a Global Unicast Prefix for SIDs 222 All of the SRv6 related specifications discussed above are intended 223 to be applicable to a contained SR Domain or between collaborating SR 224 Domains. Hence the behavior of SRv6 SIDs is visible purely within 225 the SR domain and they would be treated solely as IPv6 routing 226 prefixes by nodes that are not SR aware. 228 As an added factor of safety, it might be prudent to allocate some 229 address space that explicitly signals that the addresses within that 230 space are not intended to comply with [RFC4291]. As described in 231 Section 3 above, there is precedent for mechanisms that use IPv6 232 addresses in a manner different from that specified in [RFC4291]. 233 This would be useful in identifying and potentially filtering packets 234 at the edges of the SR Domains as described in Section 4.1. 236 The SRv6 operational community, which is the first intended user of 237 this block, is requested to come up with conventions and guidelines 238 for the use of this newly allocated address block in line with their 239 requirements. 241 6. IANA Considerations 243 IANA is requested to assign a /16 global unicast address block for 244 the purposes described in Section 5 out of the "Reserved by IETF" 245 range defined in the Internet Protocol Version 6 Address Space 246 registry. 248 7. Security Considerations 250 The security considerations for the use of Segment Routing [RFC8402], 251 SRv6 [RFC8754], and SRv6 network programming [RFC8986] apply to the 252 use of these addresses. The use of IPv6 tunneling mechanisms 253 (including SRv6) also brings up additional concerns such as those 254 described in [RFC6169]. 256 8. Acknowledgments 258 The author would like to extend a special note of thanks to Brian 259 Carpenter and Erik Kline for their precisely summarized thoughts on 260 this topic that provided the seed of this draft. The author would 261 also like to thank Andrew Alston, Ron Bonica, Bruno Decraene, Darren 262 Dukes, Clarence Filsfils, Jim Guichard, Joel Halpern, Bob Hinden, 263 Alvaro Retana, Ole Troan, and Eric Vyncke for their ideas and 264 comments to improve this document. 266 9. References 268 9.1. Normative References 270 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 271 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 272 2006, . 274 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 275 Length Recommendation for Forwarding", BCP 198, RFC 7608, 276 DOI 10.17487/RFC7608, July 2015, 277 . 279 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 280 (IPv6) Specification", STD 86, RFC 8200, 281 DOI 10.17487/RFC8200, July 2017, 282 . 284 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 285 Decraene, B., Litkowski, S., and R. Shakir, "Segment 286 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 287 July 2018, . 289 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 290 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 291 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 292 . 294 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 295 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 296 (SRv6) Network Programming", RFC 8986, 297 DOI 10.17487/RFC8986, February 2021, 298 . 300 9.2. Informative References 302 [I-D.filsfilscheng-spring-srv6-srh-compression] 303 Cheng, W., Filsfils, C., Li, Z., Decraene, B., Cai, D., 304 Voyer, D., Clad, F., Zadok, S., Guichard, J., Liu, A., 305 Raszuk, R., and C. Li, "Compressed SRv6 Segment List 306 Encoding in SRH", Work in Progress, Internet-Draft, draft- 307 filsfilscheng-spring-srv6-srh-compression-02, 28 July 308 2021, . 311 [I-D.ietf-spring-compression-analysis] 312 Bonica, R., Cheng, W., Dukes, D., Henderickx, W., Li, C., 313 Peng, S., and C. Xie, "Compressed SRv6 SID List Analysis", 314 Work in Progress, Internet-Draft, draft-ietf-spring- 315 compression-analysis-00, 27 September 2021, 316 . 319 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 320 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 321 DOI 10.17487/RFC6052, October 2010, 322 . 324 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 325 Concerns with IP Tunneling", RFC 6169, 326 DOI 10.17487/RFC6169, April 2011, 327 . 329 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 330 Routable Cryptographic Hash Identifiers Version 2 331 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 332 2014, . 334 Author's Address 336 Suresh Krishnan 337 Cisco 338 Email: suresh.krishnan@gmail.com