IPv6 Address Assignment to End-Sites
draft-palet-v6ops-rfc6177-bis-01

Abstract

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

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 and so, policy should reflect that assignment of a single subnet is never appropriate.

This document obsoletes RFC6177 (IPv6 Address Assignment to End Sites).

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 January 21, 2019.

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. Considerations Regarding the Prefix Length
• 3. On /48 Assignments to End-Sites
• 4. Summary
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. Informative References
• Authors' Addresses

1. Introduction

There are a number of considerations that factor into address assignment policies. For example, to provide for the long-term health and scalability of the public routing infrastructure, it is important that addresses 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 those recommendations, and it triggered the development of [RFC6177]. However, some of the RIRs, have later on updated those policies, which still allow using /48, but leave the decision in the hands of the ISP, or even, in some cases, encourage the assignment of smaller (e.g., /56) blocks to residential end-sites, while keeping /48 for business.

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 a possible misinterpretation of [RFC6177] by at least 1/3rd of the operational 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 language:

• A key principle for address management is that end-sites always be able to obtain a reasonable amount of address space 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 is not a choice, even for a small residential network, which following technology trends will need a sufficiently big number of /64's. 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 accordingly.

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

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

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

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 50.000 years.

This document does not advocate careless use of address space, but there is objectively no reason to be restrictive.

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

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.

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

1. It should be easy and inexpensive for an end-site to obtain address space to number 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).
2. 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.
3. 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.
4. 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.
5. 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.
6. 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 end-site.

The considerations of this document are meant mainly for end-sites, regardless of being connected by cellular, wired or other 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 "sparsly 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, .... TBD.

8. Informative References

Authors' Addresses