idnits 2.17.1 draft-bourbaki-6man-classless-ipv6-04.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 163: '...t clarifies that a node or router MUST...' RFC 2119 keyword, line 175: '... 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 (September 15, 2018) is 2049 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) September 15, 2018 5 Intended status: Standards Track 6 Expires: March 19, 2019 8 IPv6 is Classless 9 draft-bourbaki-6man-classless-ipv6-04 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 March 19, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Problems Reinforced by Classful Addressing . . . . . . . . . 3 56 4. Identifier and Subnet Length Statements . . . . . . . . . . . 4 57 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 9.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Over the history of the IPv6 protocol, several classful addressing 69 models have been proposed. The most notable example recommended Top- 70 Level Aggregation (TLA) and Next-Level Aggregation (NLA) Identifiers 71 [RFC2450], but was obsoleted by [RFC3587], leaving a single remnant 72 of classful addressing in IPv6: a rigid network interface identifier 73 boundary at /64. This document removes the fixed position of that 74 boundary for interface addressing. 76 Recent proposed changes to the IP Version 6 Addressing Architecture 77 specification [RFC4291] have caused controversy. While link prefixes 78 of varied lengths, e.g. /127, /126, /124, /120, ... /64 have been 79 successfully deployed for many years, glaring mismatches between a 80 formal specification and long-standing field deployment practices are 81 never wise, not least because of the strong risk of mis- 82 implementation, which can easily result in serious operational 83 problems. 85 This document also clarifies that IPv6 routing subnets may be of any 86 length up to 128. 88 2. Suggested Reading 90 It is assumed that the reader understands the history of classful 91 addressing in IPv4 and why it was abolished [RFC4632]. Of course, 92 the acute need to conserve address space that forced the adoption of 93 classless addressing for IPv4 does not apply to IPv6, but the 94 arguments for operational flexibility in address assignment remain 95 compelling. 97 It is also assumed that the reader understands IPv6 [RFC2460], the IP 98 Version 6 Addressing Architecture [RFC4291], the proposed changes to 99 RFC4291 [I-D.ietf-6man-rfc4291bis] and RFC2464 100 [I-D.hinden-6man-rfc2464bis], [RFC7608] an IPv6 Prefix Length 101 Recommendation for Forwarding, and the IETF recommendation for the 102 generation of stable Interface Identifiers [RFC8064]. 104 [I-D.jinmei-6man-prefix-clarify] is also worth reading to clarify 105 uses of varying prefix lengths on a single link. 107 3. Problems Reinforced by Classful Addressing 109 For host computers on local area networks, generation of interface 110 identifiers is no longer necessarily bound to layer 2 addresses 111 (MACs) [RFC7217] [RFC8064]. Therefore their length, previously fixed 112 at 64 bits [RFC7136], is in fact a variably-sized parameter as 113 explicitly acknowledged in Section 5.5.3(d) of [RFC4862] which 114 states: 116 Note that a future revision of the address architecture [RFC4291] 117 and a future link-type-specific document, which will still be 118 consistent with each other, could potentially allow for an 119 interface identifier of length other than the value defined in the 120 current documents. Thus, an implementation should not assume a 121 particular constant. Rather, it should expect any lengths of 122 interface identifiers 124 As IPv6 use has evolved and grown, it has become evident that it 125 faces several scaling and coordination problems. These problems are 126 analogous to allocation and coordination problems that motivated IPv4 127 CIDR allocation and later abundant IPv4 PAT, they include: 129 Address allocation models for specific counts of fixed length 130 subnets to downstream networks or devices from /48 down to /64 are 131 based on design assumptions of how subnets are or should be 132 allocated and populated within IPv4 networks. 134 Hierarchical allocation of fixed-length subnets requires 135 coordination between lower / intermediate / upper network 136 elements. It has implicit assumption that policies and size 137 allocation allowed at the top of the hierarchy will accommodate 138 present and future use cases with fixed length subnet allocation. 140 Coordination with upstream networks across administrative domains 141 for the allocation of fixed length subnets reveals topology and 142 intent that may be private in scope, allowing the upstream 143 networks to restrict the topology that may be built. Policies for 144 hierarchical allocation are applied top-down and amount to 145 permission to build a particular topology (for example mobile 146 device tethering, virtual machine instantiation, containers and so 147 on). 149 In the case where a device is given a /64 (e.g. mobile phone 150 running SLAAC only, not DHCP), there is no protocol allowing them 151 to provide downstream routed layer 3 subnets, because all they 152 have is a /64. This applies more to nodes which do not have 153 DHCPv6. 155 4. Identifier and Subnet Length Statements 157 IPv6 unicast interfaces may use any subnet length up to 128 except 158 for situations where an Internet Standard document may impose a 159 particular length, for example Stateless Address Autoconfiguration 160 (SLAAC) [RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router 161 Links [RFC6164]. 163 Additionally, this document clarifies that a node or router MUST 164 support routing of any valid network prefix length, even if SLAAC or 165 other standards are in use, because routing could choose to 166 differentiate at a different granularity than is used by any such 167 automated link local address configuration tools. 169 5. Recommendations 171 For historical reasons, when a prefix is needed on a link, barring 172 other considerations, a /64 is recommended [RFC7136]. 174 The length of the Interface Identifier in Stateless Address 175 Autoconfiguration [RFC4862] is a parameter; its length SHOULD be 176 sufficient for effective randomization for privacy reasons. For 177 example, 48 bits might be sufficient. But operationally we 178 recommend, barring strong considerations to the contrary, using 179 64-bits for SLAAC in order not to discover bugs where 64 was hard- 180 coded, and to favor portability of devices and operating systems. 182 Note that OpenBSD ships with SLAAC for lengths longer than /64. 184 Nonetheless, there is no reason in theory why an IPv6 node should not 185 operate with different interface identifier lengths on different 186 physical interfaces. Thus, a correct implementation of SLAAC must in 187 fact allow for any prefix length, with the value being a parameter 188 per interface. For instance, the Interface Identifier length in the 189 recommended (see [RFC8064]) algorithm for selecting stable interface 190 identifiers [RFC7217] is a parameter, rather than a hard-coded value. 192 6. Security Considerations 194 Assuming that nodes employ unpredictable interface identifiers 195 [RFC7721], the subnet size may have an impact on some security and 196 privacy properties of a network. Namely, the smaller the subnet 197 size, the more feasible it becomes to perform IPv6 address scans 198 [RFC7707] [RFC7721]. For some specific subnets, such as point to 199 point links, this may be less of an issue. 201 On the other hand, we assume that a number of IPv6 implementations 202 fail to enforce limits on the size of some of the data structures 203 they employ for communicating with neighboring nodes, such as the 204 Neighbor Cache. In such cases, the use of smaller subnets forces an 205 operational limit on such data structures, thus helping mitigate some 206 pathological behaviors (such as Neighbor Cache Exhaustion attacks). 208 7. IANA Considerations 210 This document has no IANA Considerations. 212 8. Authors 214 The authors of this document are as follows: 216 Randy Bush , Internet Initiative Japan 218 Brian Carpenter , University of 219 Auckland 221 Fernando Gont , SI6 Networks / UTN-FRH 223 Nick Hilliard , INEX 225 Joel Jaeggli , Fastly 227 Geoff Huston , APNIC 229 Chris Morrow , Google, Inc. 231 Job Snijders , NTT Communications 233 9. References 235 9.1. Normative References 237 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 238 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 239 December 1998, . 241 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 242 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 243 2006, . 245 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 246 Interface Identifiers with IPv6 Stateless Address 247 Autoconfiguration (SLAAC)", RFC 7217, 248 DOI 10.17487/RFC7217, April 2014, 249 . 251 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 252 "Recommendation on Stable IPv6 Interface Identifiers", 253 RFC 8064, DOI 10.17487/RFC8064, February 2017, 254 . 256 9.2. Informative References 258 [I-D.hinden-6man-rfc2464bis] 259 Crawford, M. and R. Hinden, "Transmission of IPv6 Packets 260 over Ethernet Networks", draft-hinden-6man-rfc2464bis-02 261 (work in progress), March 2017. 263 [I-D.ietf-6man-rfc4291bis] 264 Hinden, R. and S. Deering, "IP Version 6 Addressing 265 Architecture", draft-ietf-6man-rfc4291bis-09 (work in 266 progress), July 2017. 268 [I-D.jinmei-6man-prefix-clarify] 269 Jinmei, T., "Clarifications on On-link and Subnet IPv6 270 Prefixes", draft-jinmei-6man-prefix-clarify-00 (work in 271 progress), March 2017. 273 [RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rule", 274 RFC 2450, DOI 10.17487/RFC2450, December 1998, 275 . 277 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 278 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 279 August 2003, . 281 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 282 (CIDR): The Internet Address Assignment and Aggregation 283 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 284 2006, . 286 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 287 Address Autoconfiguration", RFC 4862, 288 DOI 10.17487/RFC4862, September 2007, 289 . 291 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 292 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 293 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 294 . 296 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 297 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 298 February 2014, . 300 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 301 Length Recommendation for Forwarding", BCP 198, RFC 7608, 302 DOI 10.17487/RFC7608, July 2015, 303 . 305 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 306 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 307 . 309 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 310 Considerations for IPv6 Address Generation Mechanisms", 311 RFC 7721, DOI 10.17487/RFC7721, March 2016, 312 . 314 Author's Address 316 Nicolas Bourbaki 317 The Intertubes 318 42 Rue du Jour 319 Sophia-Antipolis ::1 320 FR 322 Email: bourbaki@bogus.com