idnits 2.17.1 draft-bourbaki-6man-classless-ipv6-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 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 138: '...t clarifies that a node or router MUST...' RFC 2119 keyword, line 150: '... 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 (May 22, 2017) is 2531 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) ** Downref: Normative reference to an Informational RFC: RFC 2450 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-09) exists of draft-ietf-6man-rfc4291bis-07 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Internet Initiative Japan 4 Updates: 4291 (if approved) B. Carpenter 5 Intended status: Standards Track Univ. of Auckland 6 Expires: November 23, 2017 F. Gont 7 SI6 Networks / UTN-FRH 8 N. Hilliard 9 INEX 10 G. Huston 11 APNIC 12 C. Morrow 13 GOOG 14 J. Snijders 15 NTT 16 May 22, 2017 18 IPv6 is Classless 19 draft-bourbaki-6man-classless-ipv6-00 21 Abstract 23 Over the history of IPv6, various classful address models have been 24 proposed, none of which has withstood the test of time. The last 25 remnant of IPv6 classful addressing is a rigid network interface 26 identifier boundary at /64. This document removes the fixed position 27 of that boundary for interface addressing. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 23, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Identifier and Subnet Length Statements . . . . . . . . . . . 3 66 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 7.2. Informative References . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 Over the history of the IPv6 protocol, several classful addressing 77 models have been proposed. The most notable example recommended Top- 78 Level Aggregation (TLA) and Next-Level Aggregation (NLA) Identifiers 79 [RFC2450], but was obsoleted by [RFC3587], leaving a single remnant 80 of classful addressing in IPv6: a rigid network interface identifier 81 boundary at /64. This document removes the fixed position of that 82 boundary for interface addressing. 84 Recent proposed changes to the IP Version 6 Addressing Architecture 85 specification [RFC4291] have caused controversy. While link prefixes 86 of varied lengths, e.g. /127, /126, /124, /120, ... /64 have been 87 successfully deployed for many years, glaring mismatches between a 88 formal specification and long-standing field deployment practices are 89 never wise, not least because of the strong risk of mis- 90 implementation, which can easily result in serious operational 91 problems. 93 This document also clarifies that IPv6 routing subnets may be of any 94 length up to 128. 96 2. Suggested Reading 98 It is assumed that the reader understands the history of classful 99 addressing in IPv4 and why it was abolished [RFC4632]. Of course, 100 the acute need to conserve address space that forced the adoption of 101 classless addressing for IPv4 does not apply to IPv6, but the 102 arguments for operational flexibility in address assignment remain 103 compelling. 105 It is also assumed that the reader understands IPv6 [RFC2460], the IP 106 Version 6 Addressing Architecture [RFC4291], the proposed changes to 107 RFC4291 [I-D.ietf-6man-rfc4291bis] and RFC2464 108 [I-D.hinden-6man-rfc2464bis], [RFC7608] an IPv6 Prefix Length 109 Recommendation for Forwarding, and the IETF recommendation for the 110 generation of stable Interface Identifiers [RFC8064]. 112 [I-D.jinmei-6man-prefix-clarify] is also worth reading to clarify 113 uses of varying prefix lengths on a single link. 115 For host computers on local area networks, generation of interface 116 identifiers is no longer necessarily bound to layer 2 addresses 117 (MACs) [RFC7217] [RFC8064]. Therefore their length, previously fixed 118 at 64 bits [RFC7136], is in fact a variably-sized parameter as 119 explicitly acknowledged in Section 5.5.3(d) of [RFC4862] which 120 states: 122 Note that a future revision of the address architecture [RFC4291] 123 and a future link-type-specific document, which will still be 124 consistent with each other, could potentially allow for an 125 interface identifier of length other than the value defined in the 126 current documents. Thus, an implementation should not assume a 127 particular constant. Rather, it should expect any lengths of 128 interface identifiers. 130 3. Identifier and Subnet Length Statements 132 IPv6 unicast interfaces may use any subnet length up to 128 except 133 for situations where an Internet Standard document may impose a 134 particular length, for example Stateless Address Autoconfiguration 135 (SLAAC) [RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router 136 Links [RFC6164]. 138 Additionally, this document clarifies that a node or router MUST 139 support routing of any valid network prefix length, even if SLAAC or 140 other standards are in use, because routing could choose to 141 differentiate at a different granularity than is used by any such 142 automated link local address configuration tools. 144 4. Recommendations 146 For historical reasons, when a prefix is needed on a link, barring 147 other considerations, a /64 is recommended [RFC7136]. 149 The length of the Interface Identifier in Stateless Address 150 Autoconfiguration [RFC4862] is a parameter; its length SHOULD be 151 sufficient for effective randomization for privacy reasons. For 152 example, a /48 might be sufficient. But operationally we recommend, 153 barring strong considerations to the contrary, using 64-bits for 154 SLAAC in order not to discover bugs where 64 was hard-coded, and to 155 favor portability of devices and operating systems. 157 Nonetheless, there is no reason in theory why an IPv6 node should not 158 operate with different interface identfier lengths on different 159 physical interfaces. Thus, a correct implementation of SLAAC must in 160 fact allow for any prefix length, with the value being a parameter 161 per interface. For instance, the Interface Identifier length in the 162 recommended (see [RFC8064]) algorithm for selecting stable interface 163 identifiers [RFC7217] is a parameter, rather than a hardcoded value. 165 5. Security Considerations 167 Assuming that nodes employ unpredictable interface identifiers 168 [RFC7721], the subnet size may have an impact on some security and 169 privacy properties of a network. Namely, the smaller the subnet 170 size, the more feasible it becomes to perform IPv6 address scans 171 [RFC7707] [RFC7721]. For some specific subnets, such as point to 172 point links, this may be less of an issue. 174 On the other hand, we assume that a number of IPv6 implementations 175 fail to enforce limits on the size of some of the data structures 176 they employ for communicating with neighboring nodes, such as the 177 Neighbor Cache. In such cases, the use of smaller subnets forces an 178 operational limit on such data structures, thus helping mitigate some 179 pathological behaviors (such as Neighbor Cache Exhaustion attacks). 181 6. IANA Considerations 183 This document has no IANA Considerations. 185 7. References 187 7.1. Normative References 189 [RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rules", 190 RFC 2450, December 1998. 192 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 193 (IPv6) Specification", RFC 2460, December 1998. 195 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 196 Architecture", RFC 4291, February 2006. 198 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 199 Interface Identifiers with IPv6 Stateless Address 200 Autoconfiguration (SLAAC)", RFC 7217, 201 DOI 10.17487/RFC7217, April 2014, 202 . 204 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 205 "Recommendation on Stable IPv6 Interface Identifiers", 206 RFC 8064, DOI 10.17487/RFC8064, February 2017, 207 . 209 7.2. Informative References 211 [I-D.hinden-6man-rfc2464bis] 212 Crawford, M. and R. Hinden, "Transmission of IPv6 Packets 213 over Ethernet Networks", draft-hinden-6man-rfc2464bis-02 214 (work in progress), March 2017. 216 [I-D.ietf-6man-rfc4291bis] 217 Hinden, R. and S. <>, "IP Version 6 Addressing 218 Architecture", draft-ietf-6man-rfc4291bis-07 (work in 219 progress), January 2017. 221 [I-D.jinmei-6man-prefix-clarify] 222 Jinmei, T., "Clarifications on On-link and Subnet IPv6 223 Prefixes", draft-jinmei-6man-prefix-clarify-00 (work in 224 progress), March 2017. 226 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 227 Unicast Address Format", RFC 3587, August 2003. 229 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 230 (CIDR): The Internet Address Assignment and Aggregation 231 Plan", BCP 122, RFC 4632, August 2006. 233 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 234 Address Autoconfiguration", RFC 4862, September 2007. 236 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 237 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 238 Router Links", RFC 6164, April 2011. 240 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 241 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 242 February 2014, . 244 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 245 Length Recommendation for Forwarding", BCP 198, RFC 7608, 246 DOI 10.17487/RFC7608, July 2015, 247 . 249 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 250 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 251 . 253 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 254 Considerations for IPv6 Address Generation Mechanisms", 255 RFC 7721, DOI 10.17487/RFC7721, March 2016, 256 . 258 Authors' Addresses 260 Randy Bush 261 Internet Initiative Japan 262 5147 Crystal Springs 263 Bainbridge Island, Washington 98110 264 US 266 Email: randy@psg.com 268 Brian Carpenter 269 Department of Computer Science 270 University of Auckland 271 PB 92019 272 Auckland 1142 273 New Zealand 275 Email: brian.e.carpenter@gmail.com 276 Fernando Gont 277 SI6 Networks / UTN-FRH 278 Evaristo Carriego 2644 279 Haedo, Provincia de Buenos Aires 1706 280 Argentina 282 Phone: +54 11 4650 8472 283 Email: fgont@si6networks.com 284 URI: http://www.si6networks.com 286 Nick Hilliard 287 INEX 288 4027 Kingswood Road 289 Dublin 24 290 Ireland 292 Email: nick@inex.ie 294 Geoff Huston 296 Email: gih@apnic.net 298 Chris Morrow 299 Google, Inc. 300 1600 Ampitheatre Parkway 301 Mountain View, California 302 United States of America 304 Email: morrowc@google.com 306 Job Snijders 307 NTT Communications 308 Theodorus Majofskistraat 100 309 Amsterdam 1065 SZ 310 The Netherlands 312 Email: job@ntt.net