[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            R. Bush
Internet-Draft                                 Internet Initiative Japan
Updates: 4291 (if approved)                                 B. Carpenter
Intended status: Standards Track                       Univ. of Auckland
Expires: November 23, 2017                                       F. Gont
                                                  SI6 Networks / UTN-FRH
                                                             N. Hilliard
                                                               G. Huston
                                                               C. Morrow
                                                             J. Snijders
                                                            May 22, 2017

                           IPv6 is Classless


   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 November 23, 2017.

Bush, et al.            Expires November 23, 2017               [Page 1]

Internet-Draft              IPv6 is Classless                   May 2017

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
   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 . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Identifier and Subnet Length Statements . . . . . . . . . . .   3
   4.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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

Bush, et al.            Expires November 23, 2017               [Page 2]

Internet-Draft              IPv6 is Classless                   May 2017

   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

   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.

   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

      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.

3.  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

Bush, et al.            Expires November 23, 2017               [Page 3]

Internet-Draft              IPv6 is Classless                   May 2017

   differentiate at a different granularity than is used by any such
   automated link local address configuration tools.

4.  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, a /48 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 identfier 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 hardcoded value.

5.  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).

6.  IANA Considerations

   This document has no IANA Considerations.

Bush, et al.            Expires November 23, 2017               [Page 4]

Internet-Draft              IPv6 is Classless                   May 2017

7.  References

7.1.  Normative References

   [RFC2450]  Hinden, R., "Proposed TLA and NLA Assignment Rules",
              RFC 2450, December 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, 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,

7.2.  Informative References

              Crawford, M. and R. Hinden, "Transmission of IPv6 Packets
              over Ethernet Networks", draft-hinden-6man-rfc2464bis-02
              (work in progress), March 2017.

              Hinden, R. and S. <>, "IP Version 6 Addressing
              Architecture", draft-ietf-6man-rfc4291bis-07 (work in
              progress), January 2017.

              Jinmei, T., "Clarifications on On-link and Subnet IPv6
              Prefixes", draft-jinmei-6man-prefix-clarify-00 (work in
              progress), March 2017.

   [RFC3587]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
              Unicast Address Format", RFC 3587, August 2003.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

Bush, et al.            Expires November 23, 2017               [Page 5]

Internet-Draft              IPv6 is Classless                   May 2017

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, 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, April 2011.

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014, <http://www.rfc-editor.org/info/rfc7136>.

   [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,

Authors' Addresses

   Randy Bush
   Internet Initiative Japan
   5147 Crystal Springs
   Bainbridge Island, Washington  98110

   Email: randy@psg.com

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland  1142
   New Zealand

   Email: brian.e.carpenter@gmail.com

Bush, et al.            Expires November 23, 2017               [Page 6]

Internet-Draft              IPv6 is Classless                   May 2017

   Fernando Gont
   SI6 Networks / UTN-FRH
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com

   Nick Hilliard
   4027 Kingswood Road
   Dublin  24

   Email: nick@inex.ie

   Geoff Huston

   Email: gih@apnic.net

   Chris Morrow
   Google, Inc.
   1600 Ampitheatre Parkway
   Mountain View, California
   United States of America

   Email: morrowc@google.com

   Job Snijders
   NTT Communications
   Theodorus Majofskistraat 100
   Amsterdam  1065 SZ
   The Netherlands

   Email: job@ntt.net

Bush, et al.            Expires November 23, 2017               [Page 7]

Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/