diff --git a/draft-nbourbaki-6man-classless-ipv6.txt b/draft-nbourbaki-6man-classless-ipv6.txt deleted file mode 100644 index 4d92f1e..0000000 --- a/draft-nbourbaki-6man-classless-ipv6.txt +++ /dev/null @@ -1,392 +0,0 @@ - - - - -6man N. Bourbaki -Internet-Draft The Intertubes -Updates: 4291 (if approved) July 31, 2017 -Intended status: Standards Track -Expires: February 1, 2018 - - - IPv6 is Classless - draft-bourbaki-6man-classless-ipv6-01 - -Abstract - - Over the history of IPv6, various classful address models have been - proposed, none of which has withstood the test of time. The last - remnant of IPv6 classful addressing is a rigid network interface - identifier boundary at /64. This document removes the fixed position - of that boundary for interface addressing. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on February 1, 2018. - -Copyright Notice - - Copyright (c) 2017 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - - - - -Bourbaki Expires February 1, 2018 [Page 1] - -Internet-Draft IPv6 is Classless July 2017 - - - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 - 3. Problems Reinforced by Classful Addressing . . . . . . . . . 3 - 4. Identifier and Subnet Length Statements . . . . . . . . . . . 4 - 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 - 8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 - 9.2. Informative References . . . . . . . . . . . . . . . . . 6 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 - -1. Introduction - - Over the history of the IPv6 protocol, several classful addressing - models have been proposed. The most notable example recommended Top- - Level Aggregation (TLA) and Next-Level Aggregation (NLA) Identifiers - [RFC2450], but was obsoleted by [RFC3587], leaving a single remnant - of classful addressing in IPv6: a rigid network interface identifier - boundary at /64. This document removes the fixed position of that - boundary for interface addressing. - - Recent proposed changes to the IP Version 6 Addressing Architecture - specification [RFC4291] have caused controversy. While link prefixes - of varied lengths, e.g. /127, /126, /124, /120, ... /64 have been - successfully deployed for many years, glaring mismatches between a - formal specification and long-standing field deployment practices are - never wise, not least because of the strong risk of mis- - implementation, which can easily result in serious operational - problems. - - This document also clarifies that IPv6 routing subnets may be of any - length up to 128. - -2. Suggested Reading - - It is assumed that the reader understands the history of classful - addressing in IPv4 and why it was abolished [RFC4632]. Of course, - the acute need to conserve address space that forced the adoption of - classless addressing for IPv4 does not apply to IPv6, but the - arguments for operational flexibility in address assignment remain - compelling. - - - -Bourbaki Expires February 1, 2018 [Page 2] - -Internet-Draft IPv6 is Classless July 2017 - - - It is also assumed that the reader understands IPv6 [RFC2460], the IP - Version 6 Addressing Architecture [RFC4291], the proposed changes to - RFC4291 [I-D.ietf-6man-rfc4291bis] and RFC2464 - [I-D.hinden-6man-rfc2464bis], [RFC7608] an IPv6 Prefix Length - Recommendation for Forwarding, and the IETF recommendation for the - generation of stable Interface Identifiers [RFC8064]. - - [I-D.jinmei-6man-prefix-clarify] is also worth reading to clarify - uses of varying prefix lengths on a single link. - -3. Problems Reinforced by Classful Addressing - - For host computers on local area networks, generation of interface - identifiers is no longer necessarily bound to layer 2 addresses - (MACs) [RFC7217] [RFC8064]. Therefore their length, previously fixed - at 64 bits [RFC7136], is in fact a variably-sized parameter as - explicitly acknowledged in Section 5.5.3(d) of [RFC4862] which - states: - - Note that a future revision of the address architecture [RFC4291] - and a future link-type-specific document, which will still be - consistent with each other, could potentially allow for an - interface identifier of length other than the value defined in the - current documents. Thus, an implementation should not assume a - particular constant. Rather, it should expect any lengths of - interface identifiers - - As IPv6 use has evolved and grown, it has become evident that it - faces several scaling and coordination problems. These problems are - analogous to allocation and coordination problems that motivated IPv4 - CIDR allocation and later abundant IPv4 PAT, they include: - - Address allocation models for specific counts of fixed length - subnets to downstream networks or devices from /48 down to /64 are - based on design assumptions of how subnets are or should be - allocated and populated within IPv4 networks. - - Hierarchical allocation of fixed-length subnets requires - coordination between lower / intermediate / upper network - elements. It has implicit assumption that policies and size - allocation allowed at the top of the hierarchy will accommodate - present and future use cases with fixed length subnet allocation. - - Coordination with upstream networks across administrative domains - for the allocation of fixed length subnets reveals topology and - intent that may be private in scope, allowing the upstream - networks to restrict the topology that may be built. Policies for - hierarchical allocation are applied top-down and amount to - - - -Bourbaki Expires February 1, 2018 [Page 3] - -Internet-Draft IPv6 is Classless July 2017 - - - permission to build a particular topology (for example mobile - device tethering, virtual machine instantiation, containers and so - on). - - In the case where a device is given a /64 (e.g. mobile phone - running SLAAC only, not DHCP), there is no protocol allowing them - to provide downstream routed layer 3 subnets, because all they - have is a /64. This applies more to nodes which do not have - DHCPv6. - -4. Identifier and Subnet Length Statements - - IPv6 unicast interfaces may use any subnet length up to 128 except - for situations where an Internet Standard document may impose a - particular length, for example Stateless Address Autoconfiguration - (SLAAC) [RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router - Links [RFC6164]. - - Additionally, this document clarifies that a node or router MUST - support routing of any valid network prefix length, even if SLAAC or - other standards are in use, because routing could choose to - differentiate at a different granularity than is used by any such - automated link local address configuration tools. - -5. Recommendations - - For historical reasons, when a prefix is needed on a link, barring - other considerations, a /64 is recommended [RFC7136]. - - The length of the Interface Identifier in Stateless Address - Autoconfiguration [RFC4862] is a parameter; its length SHOULD be - sufficient for effective randomization for privacy reasons. For - example, 48 bits might be sufficient. But operationally we - recommend, barring strong considerations to the contrary, using - 64-bits for SLAAC in order not to discover bugs where 64 was hard- - coded, and to favor portability of devices and operating systems. - - Nonetheless, there is no reason in theory why an IPv6 node should not - operate with different interface identifier lengths on different - physical interfaces. Thus, a correct implementation of SLAAC must in - fact allow for any prefix length, with the value being a parameter - per interface. For instance, the Interface Identifier length in the - recommended (see [RFC8064]) algorithm for selecting stable interface - identifiers [RFC7217] is a parameter, rather than a hard-coded value. - - - - - - - -Bourbaki Expires February 1, 2018 [Page 4] - -Internet-Draft IPv6 is Classless July 2017 - - -6. Security Considerations - - Assuming that nodes employ unpredictable interface identifiers - [RFC7721], the subnet size may have an impact on some security and - privacy properties of a network. Namely, the smaller the subnet - size, the more feasible it becomes to perform IPv6 address scans - [RFC7707] [RFC7721]. For some specific subnets, such as point to - point links, this may be less of an issue. - - On the other hand, we assume that a number of IPv6 implementations - fail to enforce limits on the size of some of the data structures - they employ for communicating with neighboring nodes, such as the - Neighbor Cache. In such cases, the use of smaller subnets forces an - operational limit on such data structures, thus helping mitigate some - pathological behaviors (such as Neighbor Cache Exhaustion attacks). - -7. IANA Considerations - - This document has no IANA Considerations. - -8. Authors - - The authors of this document are as follows: - - Randy Bush , Internet Initiative Japan - - Brian Carpenter , University of - Auckland - - Fernando Gont , SI6 Networks / UTN-FRH - - Nick Hilliard , INEX - - Joel Jaeggli , Fastly - - Geoff Huston , APNIC - - Chris Morrow , Google, Inc. - - Job Snijders , NTT Communications - -9. References - -9.1. Normative References - - [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, - December 1998, . - - - -Bourbaki Expires February 1, 2018 [Page 5] - -Internet-Draft IPv6 is Classless July 2017 - - - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, DOI 10.17487/RFC4291, February - 2006, . - - [RFC7217] Gont, F., "A Method for Generating Semantically Opaque - Interface Identifiers with IPv6 Stateless Address - Autoconfiguration (SLAAC)", RFC 7217, - DOI 10.17487/RFC7217, April 2014, - . - - [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, - "Recommendation on Stable IPv6 Interface Identifiers", - RFC 8064, DOI 10.17487/RFC8064, February 2017, - . - -9.2. Informative References - - [I-D.hinden-6man-rfc2464bis] - Crawford, M. and R. Hinden, "Transmission of IPv6 Packets - over Ethernet Networks", draft-hinden-6man-rfc2464bis-02 - (work in progress), March 2017. - - [I-D.ietf-6man-rfc4291bis] - Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", draft-ietf-6man-rfc4291bis-09 (work in - progress), July 2017. - - [I-D.jinmei-6man-prefix-clarify] - Jinmei, T., "Clarifications on On-link and Subnet IPv6 - Prefixes", draft-jinmei-6man-prefix-clarify-00 (work in - progress), March 2017. - - [RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rule", - RFC 2450, DOI 10.17487/RFC2450, December 1998, - . - - [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global - Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, - August 2003, . - - [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing - (CIDR): The Internet Address Assignment and Aggregation - Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August - 2006, . - - - - - - - -Bourbaki Expires February 1, 2018 [Page 6] - -Internet-Draft IPv6 is Classless July 2017 - - - [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless - Address Autoconfiguration", RFC 4862, - DOI 10.17487/RFC4862, September 2007, - . - - [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, - L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- - Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, - . - - [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 - Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, - February 2014, . - - [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix - Length Recommendation for Forwarding", BCP 198, RFC 7608, - DOI 10.17487/RFC7608, July 2015, - . - - [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 - Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, - . - - [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy - Considerations for IPv6 Address Generation Mechanisms", - RFC 7721, DOI 10.17487/RFC7721, March 2016, - . - -Author's Address - - Nicolas Bourbaki - The Intertubes - 42 Rue du Jour - Sophia-Antipolis ::1 - FR - - Email: bourbaki@bogus.com - - - - - - - - - - - - - - -Bourbaki Expires February 1, 2018 [Page 7]