RFC 6177

RFC 6177: IPv6 Address Assignment to End Sites 🎀

okay bestie, let's get into this one! 💖 It's a Best Current Practice that's all about how much IPv6 address space an end site should get. Here's the lowdown on the title block:

• Authors: T. Narten (IBM), G. Huston (APNIC), and L. Roberts (Stanford University) 🧚
• Category: Best Current Practice, aka BCP 157 💅
• Date: March 2011 📅
• Obsoletes: RFC 3177 💀
• Updates: none listed 🌸
• ISSN: 2070-1721

Abstract ✨

so RFC 3177 said that in IPv6, end sites should get /48 blocks in most cases 👑. The Regional Internet Registries (RIRs) adopted that in 2002, but they started rethinking the policy in 2005 🤔. This doc obsoletes the RFC 3177 recommendations on giving out IPv6 address space to end sites 🦋.

Picking how much space each end site gets is up to the operational community. The IETF's job here is just to give guidance on IPv6 architecture and operations 🫶. This document looks at the architectural and operational considerations behind end site assignments, plus the reasons RFC 3177 made its original recommendations ✨.

It also makes it clear that a one-size-fits-all /48 isn't nuanced enough for the huge range of end sites out there 🙈. It's no longer recommended as a single default. 💅

This document obsoletes RFC 3177. 💜

Status of This Memo 🌈

this memo documents an Internet Best Current Practice ✨.

This is a product of the Internet Engineering Task Force (IETF) 🧚. It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🔥. If you want more on BCPs, check out Section 2 of RFC 5741 📚.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6177 🎀.

Copyright Notice 💖

Copyright (c) 2011 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), as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜.

Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License 🧾.

This document may contain material from IETF Documents or IETF Contributions that were published, or made publicly available, before November 10, 2008 🕰️. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍.

Table of Contents 🧚

   1. Introduction ....................................................3
   2. On /48 Assignments to End Sites .................................4
   3. Other RFC 3177 Considerations ...................................6
   4. Impact on IPv6 Standards ........................................6
      4.1. RFC 3056: Connection of IPv6 Domains via IPv4 Clouds .......6
      4.2. IPv6 Multicast Addressing ..................................7
   5. Summary .........................................................7
   6. Security Considerations .........................................8
   7. Acknowledgments .................................................8
   8. Informative References ..........................................8

1. Introduction ✨

okay so there are a bunch of things that go into address assignment policies 💅. For example, if we want the public routing infrastructure to stay healthy and scalable long-term, it really matters that addresses aggregate well [ROUTE-SCALING] 🌸. Handing out way too much address space could also lead to premature depletion of the address space 💀.

This document zooms in on a narrower question: what's an appropriate IPv6 address assignment size for end sites? Like, when end sites ask ISPs for IPv6 address space, what size should they get? 🦋

RFC 3177 [RFC3177] called for a default end site IPv6 assignment size of /48. Then the Regional Internet Registries (RIRs) built and adopted IPv6 address assignment and allocation policies that matched RFC 3177's recommendations [RIR-IPV6] 🧚. In 2005 the RIRs started talking about IPv6 address assignment policy again 👀. Since then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE [RIPE-ENDSITE] have revised their end site assignment policies to encourage smaller blocks, i.e., /56, for end sites 🍓.

This document obsoletes RFC 3177 and updates its recommendations in three ways 💖:

1. It's no longer recommended that /128s be given out. Sure, there might be some cases where assigning just one address is justified, but a site, by definition, implies multiple subnets and multiple devices 🙈.
2. RFC 3177 specifically recommended prefix lengths of /48, /64, and /128. The worry is that when you specify a few fixed boundaries, implementations and operational practices might get "hard-coded" to recognize only those boundaries, which is basically a return to "classful addressing" 😭. The real intention was never to have hard-coded boundaries within addresses. Classless Inter-Domain Routing (CIDR) keeps applying to all bits of the routing prefixes 🌈.
3. This document moves away from the earlier idea that a single default assignment size, like /48, makes sense for all end sites in the general case. End sites come in all different shapes and sizes, so a one-size-fits-all approach isn't necessary or appropriate 👑.

BUT this document does reaffirm an important assumption behind RFC 3177, and it's a big one 🫶:

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 years rather than just months. In practice, that means at least one /64, and in most cases significantly more. 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 because it could not get sufficient address space.

This document doesn't make a formal recommendation on what the exact assignment size should be 🙅‍♀️. Picking how much space to give end sites is the operational community's call. The IETF's role is limited to guidance on IPv6 architectural and operational considerations. This doc is one input into those discussions 🎀. The focus here is on the architectural issues and some operational considerations around the size of the end site assignment ✨.

2. On /48 Assignments to End Sites ✨

okay so, looking back at why the /48 recommendation [RFC3177] even happened, there were three main concerns 💅. The first one was making sure end sites could get enough address space super easily, without having to "jump through hoops" 🎀. Like, if someone felt they needed more space, just the act of asking would basically be enough justification 🙈. Compare that to IPv4, where typical home users get a single public IP address (and even that's not always guaranteed 💀). Getting more than one is often difficult or even impossible, unless you're willing to pay a (significantly) increased fee for what's usually seen as a "higher grade" of service 😭. (Side note, and this matters: the extra ISP charge for a few more addresses usually can't be justified by the real per-address cost RIRs charge. The extra addresses are often only available as part of a different or "higher grade" type of service that has its own charge. So the extra cost isn't coming from RIR fee structures. It's coming from business choices ISPs make 🫶.) The big IPv6 goal is to totally change the default and minimal end site assignment, going from "a single address" to "multiple networks," and to make sure end sites can easily get address space ✨.

The second motivation was to simplify managing an end site's addressing plan when renumbering happens (e.g., when switching ISPs) 🔥. In IPv6, a site can use multiple prefixes at the same time, including one or more public prefixes from ISPs as well as Unique Local Addresses [ULA-ADDRESSES]. With multiple prefixes, it's way less complex to manage the numbering plan if the same subnet numbering plan can be used for all of them. So for a link with (say) three different prefixes assigned to it, the subnet portion of those prefixes would be identical for all assigned addresses 🧚. Renumbering from a larger set of "subnet bits" into a smaller set, on the other hand, is often painful, because it can mean changing the network itself (e.g., collapsing subnets) 😩. So renumbering into a prefix with (at least) the same number of subnet bits is more straightforward, since only the top-level bits of the address need to change 🌈. A key goal of the recommendations in RFC 3177 is that, when renumbering, you don't have to deal with moving into a smaller subnet size 👑.

It's worth noting that similar arguments apply to managing zone files in the DNS. Managing the reverse (ip6.arpa) tree is simplified when all links are numbered using the same subnet ids 🍓.

The third motivation was to better support the network growth that happens at many sites 📈. In IPv4, it's usually difficult (or impossible) to get public address space for more than a few months of projected growth. So even slow growth over several years can lead to needing to renumber into a larger address block 😵. With IPv6's vast address space, end sites can easily be given more space (compared with IPv4) to support expected growth over multi-year periods 💖.

While the /48 recommendation does simplify address space management for end sites, it has also been widely criticized as wasteful 🙃. For example, a large business (which may have thousands of employees) would get the same default amount of address space as a home user. A home user today typically has a single (or small number of) LAN and a small number of devices (dozens or less) 🏠. It seems likely that the size of a typical home network will grow over the next few decades, but it's hard to argue that home sites will use 65K subnets in the foreseeable future 🤷‍♀️. At the same time, it might be tempting to give home sites a single /64, since that's already significantly more address space than today's IPv4 practice. However, that rules out the expectation that even home sites will grow to support multiple subnets going forward. So it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either 🎀.

A change in policy like this would have a significant impact on address consumption projections and the expected longevity of IPv6 📉. For example, changing the default assignment from a /48 to a /56 (for the vast majority of end sites, e.g., home sites) would save up to 8 bits. That reduces the "total projected address consumption" by (up to) 8 bits, or two orders of magnitude 🔥. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.)

The goals of RFC 3177 mentioned above can easily be met by giving home users a default assignment of less than /48, such as a /56 💅✨.

3. Other RFC 3177 Considerations

RFC 3177 suggested that some multihoming approaches (e.g., Generalized Structure Element (GSE)) might benefit from having a fixed /48 boundary. This no longer appears to be a consideration 🙌.

RFC 3177 argued that having a "one-size-fits-all" default assignment size reduced the need for customers to continually or repeatedly justify using existing address space in order to get "a little more." Likewise, it reduces the need for ISPs to evaluate such requests 💁‍♀️. Given the huge amount of address space in IPv6, there's plenty of room to give end sites enough space to match reasonable growth projections over multi-year time frames. So it remains highly desirable to provide end sites with enough space (on both initial and subsequent assignments) to last several years 📅. The good news is this goal can be achieved in a number of ways, and it does not require that all end sites receive the same default size assignment 🦋.

4. Impact on IPv6 Standards

4.1. RFC 3056: Connection of IPv6 Domains via IPv4 Clouds

RFC 3056 [RFC3056] describes a way of generating IPv6 addresses from an existing public IPv4 address 🌸. That document describes an address format where the first 48 bits concatenate a well-known prefix with a globally unique public IPv4 address. The "SLA ID" field is assumed to be 16 bits, consistent with a 16-bit "subnet id" field 🧮. To make it easier to transition from the address numbering scheme in RFC 3056 to one based on a prefix obtained from an ISP, an end site would be advised to number out of the rightmost bits first, using the leftmost bits only if the size of the site made that necessary 🫶.

Similar considerations apply to other documents that allow for a 16-bit subnet id, including [ULA-ADDRESSES] 💜.

4.2. IPv6 Multicast Addressing

Some IPv6 multicast address assignment schemes embed a unicast IPv6 prefix into the multicast address itself [RFC3306] 🧚. Those documents don't assume a particular size for the subnet id, per se, but they do assume the IPv6 prefix is a /64. So the relative size of the subnet id has no direct impact on multicast address schemes ✨.

5. Summary

The exact choice of how much address space to assign to end sites is an issue for the operational community 🌈. The recommendation in RFC 3177 [RFC3177] to assign /48s as a default is not a requirement of the IPv6 architecture. Anything of length /64 or shorter works from a standards perspective. However, there are important operational considerations too, and some of them matter a lot if users are going 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 the following into consideration 📝:

• it should be easy for an end site to obtain address space to number multiple subnets (i.e., a block larger than a single /64) and to support reasonable growth projections over long time periods (e.g., a decade or more).
• the default assignment size should take into consideration the likelihood that an end site will need multiple subnets in the future, and avoid the IPv4 practice of frequent and continual justification for obtaining small amounts of additional space 💅.
• Although a /64 can (in theory) address an almost unlimited number of devices, sites should be given sufficient address space to lay out subnets as appropriate, and not be forced to use address conservation techniques such as bridging. Whether or not bridging is an appropriate choice is an end site matter 🌸.
• assigning a longer prefix to an end site, compared with the existing prefixes the end site already has assigned, is likely to increase operational costs and complexity for the end site, with insufficient benefit to anyone 😩.
• 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 🍓.

6. Security Considerations

This document has no known security implications 🛡️✨. (Not a single one! We love to see it 💖.)

7. Acknowledgments

This document was motivated by, and benefited from, numerous conversations held during the ARIN XV and RIPE 50 meetings in April-May, 2005 🫶🎀.

8. Informative References

[APNIC-ENDSITE] "prop-031: Proposal to amend APNIC IPv6 assignment
                and utilisation requirement policy,"
                http://www.apnic.net/policy/proposals/prop-031

[ARIN-ENDSITE]  "2005-8: Proposal to amend ARIN IPv6 assignment and
                utilisation requirement",
                http://www.arin.net/policy/proposals/2005_8.html

[RIR-IPV6]      ARIN: http://www.arin.net/policy/nrpm.html#ipv6; RIPE
                Document ID: ripe-267, Date: 22 January 2003
                http://www.ripe.net/ripe/docs/ipv6policy.html; APNIC:
                http://www.apnic.net/docs/policy/ipv6-address-
                policy.html

[RFC3056]       Carpenter, B. and K. Moore, "Connection of IPv6
                Domains via IPv4 Clouds", RFC 3056, February 2001.

[RFC3306]       Haberman, B. and D. Thaler, "Unicast-Prefix-based
                IPv6 Multicast Addresses", RFC 3306, August 2002.

[RFC3177]       IAB and IESG, "IAB/IESG Recommendations on IPv6
                Address Allocations to Sites", RFC 3177, September
                2001.

[RIPE-ENDSITE]  "Proposal to Amend the IPv6 Assignment and
                Utilisation Requirement Policy", 2005-8,
                http://www.ripe.net/ripe/policies/proposals/2005-08.

[ROUTE-SCALING] "Routing and Addressing Problem Statement", Work in
                Progress, February 2010.

[ULA-ADDRESSES] Hinden, R. and B. Haberman, "Unique Local IPv6
                Unicast Addresses", RFC 4193, October 2005.

Authors' Addresses

Thomas Narten
IBM Corporation
3039 Cornwallis Ave.
PO Box 12195
Research Triangle Park, NC 27709-2195

Phone: 919-254-7798
EMail: narten@us.ibm.com


Geoff Huston
APNIC

EMail: gih@apnic.net


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

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