idnits 2.17.1 draft-bourbaki-6man-classless-ipv6-06.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 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 162: '...t clarifies that a node or router MUST...' RFC 2119 keyword, line 174: '... Autoconfiguration [RFC4862] is a parameter; its length SHOULD be...' -- The draft header indicates that this document updates RFC4291, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4291, updated by this document, for RFC5378 checks: 2003-10-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 April 2022) is 711 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man N. Bourbaki 3 Internet-Draft The Intertubes 4 Updates: 4291 (if approved) 18 April 2022 5 Intended status: Standards Track 6 Expires: 20 October 2022 8 IPv6 is Classless 9 draft-bourbaki-6man-classless-ipv6-06 11 Abstract 13 Over the history of IPv6, various classful address models have been 14 proposed, none of which has withstood the test of time. The last 15 remnant of IPv6 classful addressing is a rigid network interface 16 identifier boundary at /64. This document removes the fixed position 17 of that boundary for interface addressing. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 20 October 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Problems Reinforced by Classful Addressing . . . . . . . . . 3 55 4. Identifier and Subnet Length Statements . . . . . . . . . . . 4 56 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 9.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 Over the history of the IPv6 protocol, several classful addressing 68 models have been proposed. The most notable example recommended Top- 69 Level Aggregation (TLA) and Next-Level Aggregation (NLA) Identifiers 70 [RFC2450], but was obsoleted by [RFC3587], leaving a single remnant 71 of classful addressing in IPv6: a rigid network interface identifier 72 boundary at /64. This document removes the fixed position of that 73 boundary for interface addressing. 75 Recent proposed changes to the IP Version 6 Addressing Architecture 76 specification [RFC4291] have caused controversy. While link prefixes 77 of varied lengths, e.g. /127, /126, /124, /120, ... /64 have been 78 successfully deployed for many years, glaring mismatches between a 79 formal specification and long-standing field deployment practices are 80 never wise, not least because of the strong risk of mis- 81 implementation, which can easily result in serious operational 82 problems. 84 This document also clarifies that IPv6 routing subnets may be of any 85 length up to 128. 87 2. Suggested Reading 89 It is assumed that the reader understands the history of classful 90 addressing in IPv4 and why it was abolished [RFC4632]. Of course, 91 the acute need to conserve address space that forced the adoption of 92 classless addressing for IPv4 does not apply to IPv6, but the 93 arguments for operational flexibility in address assignment remain 94 compelling. 96 It is also assumed that the reader understands IPv6 [RFC2460], the IP 97 Version 6 Addressing Architecture [RFC4291], the proposed changes to 98 RFC4291 [I-D.ietf-6man-rfc4291bis] and RFC2464 99 [I-D.hinden-6man-rfc2464bis], [RFC7608] an IPv6 Prefix Length 100 Recommendation for Forwarding, and the IETF recommendation for the 101 generation of stable Interface Identifiers [RFC8064]. 103 [I-D.jinmei-6man-prefix-clarify] is also worth reading to clarify 104 uses of varying prefix lengths on a single link. 106 3. Problems Reinforced by Classful Addressing 108 For host computers on local area networks, generation of interface 109 identifiers is no longer necessarily bound to layer 2 addresses 110 (MACs) [RFC7217] [RFC8064]. Therefore their length, previously fixed 111 at 64 bits [RFC7136], is in fact a variably-sized parameter as 112 explicitly acknowledged in Section 5.5.3(d) of [RFC4862] which 113 states: 115 Note that a future revision of the address architecture [RFC4291] 116 and a future link-type-specific document, which will still be 117 consistent with each other, could potentially allow for an 118 interface identifier of length other than the value defined in the 119 current documents. Thus, an implementation should not assume a 120 particular constant. Rather, it should expect any lengths of 121 interface identifiers 123 As IPv6 use has evolved and grown, it has become evident that it 124 faces several scaling and coordination problems. These problems are 125 analogous to allocation and coordination problems that motivated IPv4 126 CIDR allocation and later abundant IPv4 PAT, they include: 128 Address allocation models for specific counts of fixed length 129 subnets to downstream networks or devices from /48 down to /64 are 130 based on design assumptions of how subnets are or should be 131 allocated and populated within IPv4 networks. 133 Hierarchical allocation of fixed-length subnets requires 134 coordination between lower / intermediate / upper network 135 elements. It has implicit assumption that policies and size 136 allocation allowed at the top of the hierarchy will accommodate 137 present and future use cases with fixed length subnet allocation. 139 Coordination with upstream networks across administrative domains 140 for the allocation of fixed length subnets reveals topology and 141 intent that may be private in scope, allowing the upstream 142 networks to restrict the topology that may be built. Policies for 143 hierarchical allocation are applied top-down and amount to 144 permission to build a particular topology (for example mobile 145 device tethering, virtual machine instantiation, containers and so 146 on). 148 In the case where a device is given a /64 (e.g. mobile phone 149 running SLAAC only, not DHCP), there is no protocol allowing them 150 to provide downstream routed layer 3 subnets, because all they 151 have is a /64. This applies more to nodes which do not have 152 DHCPv6. 154 4. Identifier and Subnet Length Statements 156 IPv6 unicast interfaces may use any subnet length up to 128 except 157 for situations where an Internet Standard document may impose a 158 particular length, for example Stateless Address Autoconfiguration 159 (SLAAC) [RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router 160 Links [RFC6164]. 162 Additionally, this document clarifies that a node or router MUST 163 support routing of any valid network prefix length, even if SLAAC or 164 other standards are in use, because routing could choose to 165 differentiate at a different granularity than is used by any such 166 automated link local address configuration tools. 168 5. Recommendations 170 For historical reasons, when a prefix is needed on a link, barring 171 other considerations, a /64 is recommended [RFC7136]. 173 The length of the Interface Identifier in Stateless Address 174 Autoconfiguration [RFC4862] is a parameter; its length SHOULD be 175 sufficient for effective randomization for privacy reasons. For 176 example, 48 bits might be sufficient. But operationally we 177 recommend, barring strong considerations to the contrary, using 178 64-bits for SLAAC in order not to discover bugs where 64 was hard- 179 coded, and to favor portability of devices and operating systems. 181 Note that OpenBSD ships with SLAAC for lengths longer than /64. 183 Nonetheless, there is no reason in theory why an IPv6 node should not 184 operate with different interface identifier lengths on different 185 physical interfaces. Thus, a correct implementation of SLAAC must in 186 fact allow for any prefix length, with the value being a parameter 187 per interface. For instance, the Interface Identifier length in the 188 recommended (see [RFC8064]) algorithm for selecting stable interface 189 identifiers [RFC7217] is a parameter, rather than a hard-coded value. 191 6. Security Considerations 193 Assuming that nodes employ unpredictable interface identifiers 194 [RFC7721], the subnet size may have an impact on some security and 195 privacy properties of a network. Namely, the smaller the subnet 196 size, the more feasible it becomes to perform IPv6 address scans 197 [RFC7707] [RFC7721]. For some specific subnets, such as point to 198 point links, this may be less of an issue. 200 On the other hand, we assume that a number of IPv6 implementations 201 fail to enforce limits on the size of some of the data structures 202 they employ for communicating with neighboring nodes, such as the 203 Neighbor Cache. In such cases, the use of smaller subnets forces an 204 operational limit on such data structures, thus helping mitigate some 205 pathological behaviors (such as Neighbor Cache Exhaustion attacks). 207 7. IANA Considerations 209 This document has no IANA Considerations. 211 8. Authors 213 The authors of this document are as follows: 215 Randy Bush , Internet Initiative Japan 217 Brian Carpenter , University of 218 Auckland 220 Fernando Gont , SI6 Networks / UTN-FRH 222 Nick Hilliard , INEX 224 Joel Jaeggli , Fastly 226 Geoff Huston , APNIC 228 Chris Morrow , Google, Inc. 230 Job Snijders , NTT Communications 232 9. References 234 9.1. Normative References 236 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 237 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 238 December 1998, . 240 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 241 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 242 2006, . 244 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 245 Interface Identifiers with IPv6 Stateless Address 246 Autoconfiguration (SLAAC)", RFC 7217, 247 DOI 10.17487/RFC7217, April 2014, 248 . 250 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 251 "Recommendation on Stable IPv6 Interface Identifiers", 252 RFC 8064, DOI 10.17487/RFC8064, February 2017, 253 . 255 9.2. Informative References 257 [I-D.hinden-6man-rfc2464bis] 258 Crawford, M. and R. M. Hinden, "Transmission of IPv6 259 Packets over Ethernet Networks", Work in Progress, 260 Internet-Draft, draft-hinden-6man-rfc2464bis-02, 13 March 261 2017, . 264 [I-D.ietf-6man-rfc4291bis] 265 Hinden, R. M. and S. E. Deering, "IP Version 6 Addressing 266 Architecture", Work in Progress, Internet-Draft, draft- 267 ietf-6man-rfc4291bis-09, 3 July 2017, 268 . 271 [I-D.jinmei-6man-prefix-clarify] 272 Jinmei, T., "Clarifications on On-link and Subnet IPv6 273 Prefixes", Work in Progress, Internet-Draft, draft-jinmei- 274 6man-prefix-clarify-00, 13 March 2017, 275 . 278 [RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rule", 279 RFC 2450, DOI 10.17487/RFC2450, December 1998, 280 . 282 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 283 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 284 August 2003, . 286 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 287 (CIDR): The Internet Address Assignment and Aggregation 288 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 289 2006, . 291 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 292 Address Autoconfiguration", RFC 4862, 293 DOI 10.17487/RFC4862, September 2007, 294 . 296 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 297 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 298 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 299 . 301 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 302 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 303 February 2014, . 305 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 306 Length Recommendation for Forwarding", BCP 198, RFC 7608, 307 DOI 10.17487/RFC7608, July 2015, 308 . 310 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 311 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 312 . 314 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 315 Considerations for IPv6 Address Generation Mechanisms", 316 RFC 7721, DOI 10.17487/RFC7721, March 2016, 317 . 319 Author's Address 321 Nicolas Bourbaki 322 The Intertubes 323 42 Rue du Jour 324 ::1 Sophia-Antipolis 325 France 326 Email: bourbaki@bogus.com