idnits 2.17.1 draft-bourbaki-6man-classless-ipv6-01.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 (July 30, 2017) is 2434 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) July 30, 2017 5 Intended status: Standards Track 6 Expires: January 31, 2018 8 IPv6 is Classless 9 draft-bourbaki-6man-classless-ipv6-01 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 http://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 January 31, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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 (http://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, a /48 might be sufficient. But operationally we recommend, 178 barring strong considerations to the contrary, using 64-bits for 179 SLAAC in order not to discover bugs where 64 was hard-coded, and to 180 favor portability of devices and operating systems. 182 Nonetheless, there is no reason in theory why an IPv6 node should not 183 operate with different interface identifier lengths on different 184 physical interfaces. Thus, a correct implementation of SLAAC must in 185 fact allow for any prefix length, with the value being a parameter 186 per interface. For instance, the Interface Identifier length in the 187 recommended (see [RFC8064]) algorithm for selecting stable interface 188 identifiers [RFC7217] is a parameter, rather than a hard-coded value. 190 6. Security Considerations 192 Assuming that nodes employ unpredictable interface identifiers 193 [RFC7721], the subnet size may have an impact on some security and 194 privacy properties of a network. Namely, the smaller the subnet 195 size, the more feasible it becomes to perform IPv6 address scans 196 [RFC7707] [RFC7721]. For some specific subnets, such as point to 197 point links, this may be less of an issue. 199 On the other hand, we assume that a number of IPv6 implementations 200 fail to enforce limits on the size of some of the data structures 201 they employ for communicating with neighboring nodes, such as the 202 Neighbor Cache. In such cases, the use of smaller subnets forces an 203 operational limit on such data structures, thus helping mitigate some 204 pathological behaviors (such as Neighbor Cache Exhaustion attacks). 206 7. IANA Considerations 208 This document has no IANA Considerations. 210 8. Authors 212 The authors of this document are as follows: 214 Randy Bush , Internet Initiative Japan 216 Brian Carpenter , University of 217 Auckland 219 Fernando Gont , SI6 Networks / UTN-FRH 221 Nick Hilliard , INEX 223 Joel Jaeggli , Fastly 225 Geoff Huston , APNIC 227 Chris Morrow , Google, Inc. 229 Job Snijders , NTT Communications 231 9. References 233 9.1. Normative References 235 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 236 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 237 December 1998, . 239 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 240 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 241 2006, . 243 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 244 Interface Identifiers with IPv6 Stateless Address 245 Autoconfiguration (SLAAC)", RFC 7217, 246 DOI 10.17487/RFC7217, April 2014, 247 . 249 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 250 "Recommendation on Stable IPv6 Interface Identifiers", 251 RFC 8064, DOI 10.17487/RFC8064, February 2017, 252 . 254 9.2. Informative References 256 [I-D.hinden-6man-rfc2464bis] 257 Crawford, M. and R. Hinden, "Transmission of IPv6 Packets 258 over Ethernet Networks", draft-hinden-6man-rfc2464bis-02 259 (work in progress), March 2017. 261 [I-D.ietf-6man-rfc4291bis] 262 Hinden, R. and S. Deering, "IP Version 6 Addressing 263 Architecture", draft-ietf-6man-rfc4291bis-09 (work in 264 progress), July 2017. 266 [I-D.jinmei-6man-prefix-clarify] 267 Jinmei, T., "Clarifications on On-link and Subnet IPv6 268 Prefixes", draft-jinmei-6man-prefix-clarify-00 (work in 269 progress), March 2017. 271 [RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rule", 272 RFC 2450, DOI 10.17487/RFC2450, December 1998, 273 . 275 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 276 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 277 August 2003, . 279 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 280 (CIDR): The Internet Address Assignment and Aggregation 281 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 282 2006, . 284 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 285 Address Autoconfiguration", RFC 4862, 286 DOI 10.17487/RFC4862, September 2007, 287 . 289 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 290 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 291 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 292 . 294 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 295 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 296 February 2014, . 298 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 299 Length Recommendation for Forwarding", BCP 198, RFC 7608, 300 DOI 10.17487/RFC7608, July 2015, 301 . 303 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 304 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 305 . 307 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 308 Considerations for IPv6 Address Generation Mechanisms", 309 RFC 7721, DOI 10.17487/RFC7721, March 2016, 310 . 312 Author's Address 314 Nicolas Bourbaki 315 The Intertubes 316 42 Rue du Jour 317 Sophia-Antipolis ::1 318 FR 320 Email: bourbaki@bogus.com