IPv6 Operations (v6ops)                                J. Palet Martinez
Internet-Draft                                          The IPv6 Company
Obsoletes: 6177 (if approved)                                 L. Roberts
Intended status: Best Current Practice          Stanford University, UIT
Expires: April 12, 2019                                  October 9, 2018

                  IPv6 Address Assignment to End-Sites


   The Regional Internet Registries (RIRs) policies have different views
   regarding the recommendation of the prefix to be assigned to end-
   sites.  However, all them allow up to a /48 without further
   justification and clearly state that the exact choice of how much
   address space should be assigned to end-sites is a decision of each

   This document reviews the architectural and operational
   considerations of end-site assignments, and reiterates that
   assignment policy and guidelines belong to the RIR community.  This
   revision is being made to emphasize that IPv6 protocol evolution
   requires an ever-increasing availability of subnets at the end-site,
   so policy should reflect that assignment of a single subnet is never

   This document obsoletes RFC6177 (IPv6 Address Assignment to End

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 https://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 April 12, 2019.

Palet Martinez & Roberts Expires April 12, 2019                 [Page 1]

Internet-Draft    IPv6 Address Assignment to End-Sites      October 2018

Copyright Notice

   Copyright (c) 2018 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
   (https://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.  Considerations Regarding the Prefix Length  . . . . . . . . .   4
   3.  On /48 Assignments to End-Sites . . . . . . . . . . . . . . .   5
   4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   There are a number of considerations that factor into address and
   prefix assignment policies.  For example, to provide for the long-
   term health and scalability of the public routing infrastructure, it
   is important that prefixes aggregate well [Route-Scaling].  Likewise,
   giving out an excessive amount of address space could result in
   premature depletion of the address space.  This document focuses on
   the (narrower) question of what is an appropriate IPv6 address
   assignment size for end-sites.  That is, when end-sites request IPv6
   address space from ISPs, what is an appropriate assignment size.

   [RFC3177] called for a default end-site IPv6 assignment size of /48.
   Subsequently, the Regional Internet Registries (RIRs) developed and
   adopted IPv6 address assignment and allocation policies consistent
   with ISP practices, and it triggered the development of [RFC6177].
   Current RIR policies still allow using /48, but leave the decision in
   the hands of the ISP.  In some cases, encourage the assignment /48
   blocks for all, while other RIRs encourage the assignment of smaller
   (e.g., /56) blocks to residential end-sites, while keeping /48 for

Palet Martinez & Roberts Expires April 12, 2019                 [Page 2]

Internet-Draft    IPv6 Address Assignment to End-Sites      October 2018

   More recently, a Global IPv6 Deployment Survey (for residential/
   household services) has been conducted since May 2016, with responses
   from over 1.559 ISPs, from 105 different countries, which latest
   results have been presented in January 2018 [IPv6-Survey].  This
   survey is showing that 23% of the responders (generally in more
   advanced countries, in terms of IPv6 deployment) assign a /48, 35%
   assign a /56 and 33% assign a single /64.

   This raises the question of over-zealous interpretation of [RFC6177]
   by at least one third of the ISP community and consequently, the need
   to revisit it.

   This document obsoletes [RFC6177], updating its recommendations in
   the following ways:

   1.  It is extremely discouraged that /128s are assigned.  While there
       may be some applications where assigning only a single address
       may be tolerated (e.g., an IoT object), a site, by definition,
       implies multiple subnets and multiple devices.  Also, a /128
       prevents any form of privacy-based addressing.

   2.  [RFC3177] specifically recommended using prefix lengths of /48,
       /64, and /128.  Specifying a small number of fixed boundaries has
       raised concerns that implementations and operational practices
       might become "hard-coded" to recognize only those fixed
       boundaries (i.e., a return to "classful addressing").  The actual
       intention has always been that there must be no hard-coded
       boundaries within addresses, and that Classless Inter-Domain
       Routing (CIDR) continues to apply to all bits of the routing
       prefixes [RFC7608].

   3.  [RFC6177] moved away from the previous recommendation that a
       single default assignment size (e.g., a /48) makes sense for all
       end-sites in the general case.  End-sites come in different
       shapes and sizes, and a one-size-fits-all approach is not
       necessary or appropriate.

   4.  This revision has been created to more clearly assert the
       requirement to ensure that address assignments to end-sites
       provide a sufficiently big number of subnets (/64 on classic
       networks) to each end-site, taking under consideration the end-
       site's future expected needs, new deployment expectations and new
       protocol requirements, among others.  Once all these are
       considered, it seems unlikely that a single subnet (/64) or even
       a small number of them should be assigned.

   This document reaffirms, as [RFC6177] did, an important assumption
   behind [RFC3177], using however, a much stronger and clearer

Palet Martinez & Roberts Expires April 12, 2019                 [Page 3]

Internet-Draft    IPv6 Address Assignment to End-Sites      October 2018


      A key principle for address management is that end-sites always be
      able to obtain a reasonable number of /64 subnets for their actual
      and planned usage, and over time ranges specified in many years,
      probably decades, rather than just months.  In practice, that
      means that a single /64 subnet is not a choice, even for a small
      residential network, which following technology trends will need a
      sufficiently big number of /64 subnets.  One particular situation
      that must be avoided is having an end-site feel compelled to use
      IPv6-to-IPv6 Network Address Translation or other burdensome
      address conservation techniques (e.g., [RFC7278]) because it could
      not get sufficient address space.

   This document does not make a formal recommendation on what the exact
   assignment size should be, beyond what has been indicated in the
   precedent paragraph.  The exact choice of how much address space to
   assign end-sites is an operational issue and under that context,
   discussed already in [RIPE-690].

   The IETF's role in this case is limited to providing guidance on IPv6
   architectural and operational considerations.  This document provides
   input into those discussions.  The focus of this document is to
   examine the architectural issues and some of the operational
   considerations relating to the size of the end-site assignment.

2.  Considerations Regarding the Prefix Length

   [RFC7608] already discusses about the IPv6 prefix length
   recommendations for forwarding, and the need for routing and
   forwarding implementations to ensure that longest-prefix-match works
   on any prefix length.

   Any prefix length up to /128 is treated identically by routing
   protocols, however for a given network, end-site, subnet or link,
   there always exists a Longest Acceptable Prefix (LAP,
   [I-D.carpenter-6man-lap]), whose length is locally determined, e.g.,
   a site or link that uses SLAAC has a LAP of /64 and will not work
   with a longer one.

   This consideration should be noticed, across this document, in the
   sense that end-sites usually have subnets that use, by default,
   SLAAC, and consequently, the LAP is mandatorily a /64.  Future
   technologies, may have a different LAP, which must be used

Palet Martinez & Roberts Expires April 12, 2019                 [Page 4]

Internet-Draft    IPv6 Address Assignment to End-Sites      October 2018

3.  On /48 Assignments to End-Sites

   Looking back at some of the original motivations behind the /48
   recommendation [RFC3177], there were three main concerns.  The first
   motivation was to ensure that end-sites could easily obtain
   sufficient address space without having to "jump through hoops" to do
   so.  For example, if someone felt they needed more space, just the
   act of asking would at some level be sufficient justification.  As a
   comparison point, in IPv4, typical home users are given a single
   public IP address (though even this is not always assured), but
   getting any more than one address is often difficult or even
   impossible -- unless one is willing to pay a (significantly)
   increased fee for what is often considered to be a "higher grade" of
   service.  It should be noted that increased ISP charges to obtain a
   small number of additional addresses cannot usually be justified by
   the real per-address cost levied by RIRs, but additional addresses
   are frequently only available to end users as part of a different
   type or "higher grade" of service, for which an additional charge is
   levied.  The point here is that the additional cost is not due to the
   RIR fee structures, but to business choices ISPs make.  An important
   goal in IPv6 is to significantly change the default and minimal end
   site assignment, from "a single address" to "multiple networks" and
   to ensure that end-sites can easily obtain address space.

   Furthermore, as the operational costs of carrier-grade NAT and
   address+port sharing have shown, availability of multiple addresses
   and prefixes to end-sites will be a considerable saving to their

   It might be tempting to give home sites a single /64, since that is
   already significantly more address space compared with today's IPv4
   practice.  However, this precludes the certainty that even home sites
   will grow to support multiple subnets going forward, as expected by
   the "IPv6 Home Networking Architecture" [RFC7368].  Hence, it is
   strongly intended that even home sites be given a big number of
   subnets worth of space, by default.  Hence, this document still
   recommends giving home sites significantly many more than a single

   A second motivation behind the original /48 recommendation was to
   simplify the management of an end-site's addressing plan in the
   presence of renumbering (e.g., when switching ISPs).  In IPv6, a site
   may simultaneously use multiple prefixes, including one or more
   public prefixes from ISPs as well as Unique Local Addresses
   [RFC4193].  In the presence of multiple prefixes, it is significantly
   less complex to manage a numbering plan if the same subnet numbering
   plan can be used for all prefixes.  That is, for a link that has
   (say) three different prefixes assigned to it, the subnet portion of

Palet Martinez & Roberts Expires April 12, 2019                 [Page 5]

Internet-Draft    IPv6 Address Assignment to End-Sites      October 2018

   those prefixes would be identical for all assigned addresses.  In
   contrast, renumbering from a larger set of "subnet bits" into a
   smaller set is often painful, as it can require making changes to the
   network itself (e.g., collapsing subnets).  Hence, renumbering a site
   into a prefix that has (at least) the same number of subnet bits is
   more straightforward, because only the top-level bits of the address
   need to change.  A key goal of the recommendations in [RFC3177] was
   to ensure that upon renumbering, one does not have to deal with
   renumbering into a smaller subnet size.  In particular, this would
   apply to any site that switches to an ISP that provides a longer

   It should be noted that similar arguments apply to the management of
   zone files in the DNS.  In particular, managing the reverse
   (ip6.arpa) tree is simplified when all links are renumbered using the
   same subnet ids.

   Furthermore, to keep addressing plans usable and understandable, and
   to align with DNS reverse zone delegations, the size of the assigned
   prefix should be aligned with a nibble boundary.  Each hexadecimal
   character in an IPv6 prefix represents one nibble, which is 4 bits.
   The length of a delegated prefix should therefore always be a
   multiple of 4, so the possible choices are /48, /52, /56 and /60.

   A third motivation behind the /48 recommendation was to better
   support network growth common at many sites.  In IPv4, it is usually
   difficult (or impossible) to obtain public address space for more
   than a few months' worth of projected growth.  Thus, even slow growth
   over several years can lead to the need to renumber into a larger
   address block.  With IPv6's vast address space, end-sites can easily
   be given more address space (compared with IPv4) to support expected
   growth over multi-year time periods.

   While the /48 recommendation does simplify address space management
   for end-sites, it has also been widely criticized as being wasteful.
   While reasonable people may disagree over whether all end sites
   should get a /48 assignment by default, reasonable people do agree
   that an end-site should be able to get up to a /48 by request.  It is
   important to stress that the strength of IPv6 is the vast size of its
   address space, which should allow users to easily acquire as many
   subnets as required for their applications, plus room to grow.
   Math's show that even assuming 32 billion of humans (2^35), and
   assigning each of them 4 /48's, with a 50% routing efficiency, we can
   repeat that 2^10 times, so if average life span of each human is 100
   years, and we don't recover back the /48's, we will be able to use
   IPv6 addressing space for over 102.400 years.

   This document does not advocate careless use of address space, but

Palet Martinez & Roberts Expires April 12, 2019                 [Page 6]

Internet-Draft    IPv6 Address Assignment to End-Sites      October 2018

   shows that there is objectively no reason to be restrictive.  It is
   important to leave behind the mind set of IPv4 address scarcity and
   embrace the wealth of IPv6 address abundance.

   A large business (which may have thousands of employees) would, by
   default, receive the same amount of address space, for each of its
   end-sites, as a home user.  However, it is clear that that for each
   corporate end-site it is perfectly feasible to justify further needs
   if that becomes the case, and RIR policies allow that.

   Today typically, a home has already a considerable number of possible
   subnets (a common CE has 4 LAN ports, 2 WiFi radios which support
   several SSIDs each one, VoIP subnet, IPTV subnet, additional VLANs)
   and if downstream routers are used, there is a need for further
   subnets.  This means that in a short term, assigning a /60 (16
   subnets), it is already a really bad decision.

   It will become very common that homes start using technologies like
   HNCP [RFC7788], and this increases the need for more subnets, which
   means that /56 (256 subnets) may be too short also in very few years.

   Finally, considerations about multiple addresses per host [RFC7934]
   and techniques to allow a single /64 per host/interface [RFC7934],
   means that we will see in the short term, many home devices that will
   take advantage of that, either for security reasons, or because they
   may need to run internally multiple virtual machines, or many other
   reasons, which will again, push the limit of the regular home needs,
   beyond the /56, and consequently, suggesting that /48 is a smarter

   The above-mentioned goals of [RFC3177] could be met by giving home
   users a default assignment of less than /48, such as a /56, as
   suggested in [RFC6177], however, there are new motivations and
   technologies, to reconsider that a /48 is a much better choice.

4.  Summary

   The exact choice of how much address space to assign end-sites is an
   issue for the operational community, discussed with much more detail
   in a recent document [RIPE-690].

   While the recommendation to assign /48s as a default, is not a
   requirement of the IPv6 architecture and anything of length /64 or
   shorter works from a standards perspective, there are important
   operational considerations as well, some of which are important if
   users are to share in the key benefit of IPv6: expanding the usable
   address space of the Internet.

Palet Martinez & Roberts Expires April 12, 2019                 [Page 7]

Internet-Draft    IPv6 Address Assignment to End-Sites      October 2018

   The IETF recommends that any policy on IPv6 address assignment to
   end-sites take into consideration the following:

   a.  It should be easy and inexpensive for an end-site to obtain
       address space to deploy a sufficiently big number of subnets
       (i.e., a big number of /64's) and to support reasonable growth
       projections over long time periods (e.g., more than a decade).

   b.  An end-user should be able to receive any prefix length up to /48
       simply by asking. it is critical that the community shed the
       restrictive view of IP addresses that grew up during the end of
       IPv4.  IPv6 addresses should be freely available, not a tiered
       cost structure.

   c.  The default assignment size should take into consideration the
       likelihood that an end-site will have need for multiple subnets
       in the near future and many more in a medium and longer terms,
       avoiding the IPv4 practice of having frequent and continual
       justification for obtaining small amounts of additional space.

   d.  Although a /64 can (in theory) address an almost unlimited number
       of devices, end-sites should be given sufficient address space to
       be able to lay out subnets as appropriate, and not be forced to
       use address conservation techniques such as using bridging, NAT,
       proxy or other techniques.  Whether or not those techniques are
       an appropriate choice is an end-site matter.

   e.  Assigning a longer prefix to an end-site, compared with the
       existing prefixes the end-site already has assigned to it, is
       likely to increase operational costs and complexity for the end-
       site, with insufficient benefit to anyone.

   f.  The operational considerations of managing and delegating the
       reverse DNS tree under ip6.arpa on nibble versus non-nibble
       boundaries should be given adequate consideration.

   As a consequence, it is strongly discouraged to assign to end-sites a
   single /64 or even a reduced number of them.

   Instead, it is strongly suggested considering a /48, or
   alternatively, a trade-off choice is to reserve a /48 for each end-
   site, and actually assign them only the first /56, so in the future
   renumbering is not needed and either in a case by case, by demand, or
   across all the network, the complete /48 can be re-assigned to each

   The considerations of this document are meant mainly for end-sites,
   regardless of being connected by cellular, wired or other

Palet Martinez & Roberts Expires April 12, 2019                 [Page 8]

Internet-Draft    IPv6 Address Assignment to End-Sites      October 2018

   technologies.  They don't apply to single cellular devices such as
   smartphones, which typically will get a single /64 for each
   connection (PDP context).  Even in the case of a handset, assigning a
   single /64 may require some hacks on the handset, for example to
   support tethering.  This is typically the reason [RFC7849] argued for
   aligning prefix assignments practices in both cellular and wired
   networks.  Indeed, cellular networks are more and more perceived as
   an alternative to non-cellular networks for home IP-based services
   delivery; especially with the advent of 3GPP data dongles.  There is
   a need for an efficient mechanism to assign larger prefixes to
   cellular hosts so that each LAN segment can get its own /64 prefix
   and multi-link subnet issues to be avoided.  The support of this
   functionality in both cellular and non-cellular networks is key for
   fixed-mobile convergence.

   A broadband cellular router connecting an end-site falls within the
   scope of this document.

5.  Security Considerations

   A shorter prefix has more potential space for scanning attacks, which
   would require more time, especially if the subnets and hosts are
   "sparsely assigned".

   More prefix space allows the use of slightly randomized prefixes and/
   or prefix-per-host [RFC8273].

   The use of /128 would prevent any form of privacy-based addressing.

6.  IANA Considerations

   This document has no actions for IANA.

7.  Acknowledgements

   The authors of this document will like to acknowledge the authors and
   contributors of previous versions ([RFC3177], [RFC6177]) and the
   inputs to this version from Brian Carpenter, Mohamed Boucadair, Dusan
   Mudric, David Farmer, Fred Baker, Barbara Stark, Rajiv Asati, Owen
   DeLong, .... TBD.

8.  Informative References

              Carpenter, B., "The Longest Acceptable Prefix for IPv6
              Links", draft-carpenter-6man-lap-01 (work in progress),
              June 2018.

Palet Martinez & Roberts Expires April 12, 2019                 [Page 9]

Internet-Draft    IPv6 Address Assignment to End-Sites      October 2018

              Palet Martinez, J., "IPv6 Deployment Survey (Residential/
              Household Services)", January 2018,

   [RFC3177]  IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
              Allocations to Sites", RFC 3177, DOI 10.17487/RFC3177,
              September 2001, <https://www.rfc-editor.org/info/rfc3177>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,

   [RFC6177]  Narten, T., Huston, G., and L. Roberts, "IPv6 Address
              Assignment to End Sites", BCP 157, RFC 6177,
              DOI 10.17487/RFC6177, March 2011,

   [RFC7278]  Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
              /64 Prefix from a Third Generation Partnership Project
              (3GPP) Mobile Interface to a LAN Link", RFC 7278,
              DOI 10.17487/RFC7278, June 2014,

   [RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
              Weil, "IPv6 Home Networking Architecture Principles",
              RFC 7368, DOI 10.17487/RFC7368, October 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,

   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
              2016, <https://www.rfc-editor.org/info/rfc7788>.

   [RFC7849]  Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley,
              N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner,
              "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849,
              DOI 10.17487/RFC7849, May 2016,

Palet Martinez & Roberts Expires April 12, 2019                [Page 10]

Internet-Draft    IPv6 Address Assignment to End-Sites      October 2018

   [RFC7934]  Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
              "Host Address Availability Recommendations", BCP 204,
              RFC 7934, DOI 10.17487/RFC7934, July 2016,

   [RFC8273]  Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
              per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,

              RIPE, "Best Current Operational Practice for Operators:
              IPv6 prefix assignment for end-users - persistent vs non-
              persistent, and what size to choose", October 2017,

              "Routing and Addressing Problem Statement", February 2010,

Authors' Addresses

   Jordi Palet Martinez
   The IPv6 Company
   Molino de la Navata, 75
   La Navata - Galapagar, Madrid  28420

   EMail: jordi.palet@theipv6company.com
   URI:   http://www.theipv6company.com/

   Rosalea G Roberts
   Stanford University, UIT
   P.O. Box 19131
   Stanford  CA  94309-9131

   Phone: +1-650-723-3352
   EMail: lea.roberts@stanford.edu

Palet Martinez & Roberts Expires April 12, 2019                [Page 11]