draft-nbourbaki-6man-classless-ipv6.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>

<rfc category="std" docName="draft-bourbaki-6man-classless-ipv6-05" ipr="trust200902" updates="4291">

<front>

  <title>IPv6 is Classless</title>

  <author fullname="Nicolas Bourbaki" initials="N." surname="Bourbaki">
    <organization>The Intertubes</organization>
    <address>
      <postal>
        <street>42 Rue du Jour</street>
        <city>Sophia-Antipolis</city>
        <region></region>
        <code>::1</code>
        <country>FR</country>
        </postal>
       <email>bourbaki@bogus.com</email>
     </address>
   </author>

  <date />

  <area>Internet</area>
  <workgroup>6man</workgroup>

  <abstract>

    <t>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.</t>

  </abstract>

<!--
  <note title="Requirements Language">

    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
      are to be interpreted as described in <xref target="RFC2119">RFC
      2119</xref> only when they appear in all upper case.  They may
      also appear in lower or mixed case as English words, without
      normative meaning.</t>

    </note>
-->

  </front>

<middle>

  <section anchor="intro" title="Introduction">

    <t>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 <xref target="RFC2450"/>, but was obsoleted by
    <xref target="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.</t>

    <t>Recent proposed changes to the IP Version 6 Addressing
    Architecture specification <xref target="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.</t>

    <t>This document also clarifies that IPv6 routing subnets may be of
    any length up to 128.</t>

    </section>

  <section anchor="reading" title="Suggested Reading">

    <t>It is assumed that the reader understands the history of classful
    addressing in IPv4 and why it was abolished <xref
    target="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.</t>

    <t>It is also assumed that the reader understands IPv6 <xref
    target="RFC2460"/>, the IP Version 6 Addressing Architecture <xref
    target="RFC4291"/>, the proposed changes to RFC4291 <xref
    target="I-D.ietf-6man-rfc4291bis"/> and RFC2464 <xref
    target="I-D.hinden-6man-rfc2464bis"/>, <xref target="RFC7608"/> an
    IPv6 Prefix Length Recommendation for Forwarding, and the IETF
    recommendation for the generation of stable Interface Identifiers
    <xref target="RFC8064"/>.</t>

    <t><xref target="I-D.jinmei-6man-prefix-clarify"/> is also worth
    reading to clarify uses of varying prefix lengths on a single
    link.</t>

<!--
    <t>NOTE: do we mean 4291bis (currently moribund) or 2464bis?</t>

[fgont] We do mean 4291bis. That say, RFC8064/RFC7217 already do part of
the job: they replace the algorithm of "embedding the MAC address in the
IPv6" with one that embeds random bits of an appropriate length. That
is, strictly speaking, we don't een need /64 for SLAAC, except for
backward compatibility. (*)

(*) as long as the local subnet is large enough and the IID collision
rate is low enough.
-->

    </section>

  <section anchor="Problem" title="Problems Reinforced by Classful Addressing">

   <t>For host computers on local area networks, generation of interface
   identifiers is no longer necessarily bound to layer 2 addresses
   (MACs) <xref target="RFC7217"/> <xref target="RFC8064"/>.  Therefore
   their length, previously fixed at 64 bits <xref target="RFC7136"/>,
   is in fact a variably-sized parameter as explicitly acknowledged in
   Section 5.5.3(d) of <xref target="RFC4862"/> which states:

   <list>

     <t>Note that a future revision of the address architecture <xref
     target="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</t>

     </list>
   </t>

   <t>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:

   <list>

     <t>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.</t>

     <t>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.</t>

     <t>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
     permission to build a particular topology (for example mobile
     device tethering, virtual machine instantiation, containers and so
     on).</t>

     <t>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.</t>

     </list>
     </t>

    </section>

  <section anchor="statement" title="Identifier and Subnet Length Statements">

    <t>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) <xref target="RFC4862"/>, or Using 127-Bit IPv6 Prefixes on
    Inter-Router Links <xref target="RFC6164"/>.</t>

    <t>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.</t>

    </section>

<!-- [fgont] I think these section is mixing up to things:

* Routing: Nodes must *always* support rotuing on any valid length, even
           if, say, SLAAC is in use.  Even when SLAAC is used, I might
           want to install a host-specific rule (a /128 rule), if I
           please. And I think this point has never been contended
           (except for vendors that go lazy/cheap and just don't want to
           use mre than 64-bits in each FIB entry.

* Subnet size: This is what you're really referring to here. Nodes
               should be able to employ any subnet size that they
               please, except when slaac is in use (for backwards
               compatibility) or e.g. when /127 (or the like) prefixes
               are employed for point to point links.
-->

  <section anchor="notes" title="Recommendations">

    <t>For historical reasons, when a prefix is needed on a link,
    barring other considerations, a /64 is recommended <xref
    target="RFC7136"/>.</t>

    <t>The length of the Interface Identifier in Stateless Address
    Autoconfiguration <xref target="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.</t>

    <t>Note that OpenBSD ships with SLAAC for lengths longer than
    /64.</t>

    <t>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 <xref target="RFC8064"/>) algorithm
    for selecting stable interface identifiers <xref target="RFC7217"/>
    is a parameter, rather than a hard-coded value.</t>

    </section>

  <section anchor="security" title="Security Considerations">

    <t>Assuming that nodes employ unpredictable interface identifiers
    <xref target="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 <xref target="RFC7707"/> <xref target="RFC7721"/>.
    For some specific subnets, such as point to point links, this may be
    less of an issue.</t>

    <t>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).</t>

 <!-- [fgont] Still need to add references here... e.g. to Joel's RFC -->

    </section>

  <section anchor="iana" title="IANA Considerations">

    <t>This document has no IANA Considerations.</t>

    </section>

  <section anchor="authors" title="Authors">
    <t>The authors of this document are as follows:
    <list>
      <t> Randy Bush &lt;randy@psg.com&gt;, Internet Initiative Japan</t>
      <t> Brian Carpenter &lt;brian.e.carpenter@gmail.com&gt;, University of Auckland</t>
      <t> Fernando Gont &lt;fgont@si6networks.com&gt;, SI6 Networks / UTN-FRH</t>
      <t> Nick Hilliard &lt;nick@netability.ie&gt;, INEX</t>
      <t> Joel Jaeggli &lt;joelja@bogus.com&gt;, Fastly</t>
      <t> Geoff Huston &lt;gih@apnic.net&gt;, APNIC</t>
      <t> Chris Morrow &lt;morrowc@ops-netman.net&gt;, Google, Inc.</t>
      <t> Job Snijders &lt;job@net.net&gt;, NTT Communications</t>
      </list>
    </t>

  </section>

</middle>

<back>

  <references title="Normative References">
    <!-- <?rfc include="reference.RFC.2119"?> -->
    <?rfc include="reference.RFC.2460"?>
    <?rfc include="reference.RFC.4291"?>
    <?rfc include="reference.RFC.7217"?>
    <?rfc include="reference.RFC.8064"?>
    </references>

  <references title="Informative References">
    <?rfc include="reference.RFC.2450"?>
    <?rfc include="reference.RFC.4862"?>
    <?rfc include="reference.RFC.6164"?>
    <?rfc include="reference.RFC.3587"?>
    <?rfc include="reference.RFC.4632"?>
    <?rfc include="reference.RFC.7608"?>
    <?rfc include="reference.RFC.7707"?>
    <?rfc include="reference.RFC.7136"?>
    <?rfc include="reference.RFC.7721"?>
    <?rfc include="reference.I-D.ietf-6man-rfc4291bis"?>
    <?rfc include="reference.I-D.hinden-6man-rfc2464bis"?>
    <?rfc include="reference.I-D.jinmei-6man-prefix-clarify"?>
    </references>
  </back>

</rfc>