IPv6 address space layout best practices
I'm comfortable with IPv4 address space allocations. By which I mean: Given services to plan for, or an organization to network, I have a good grasp of how to plan IP address space usage. (or at least, I think I do. :)
Are there any best practices guidance, or case studies, for IPv6 address space layout?
Super short answer: Starting at /56 try to project what will be used in the next several years and adjust up or down accordingly. People requesting a single address should still have a few allocated for future expansion, avoiding allocation fragmentation is important, moreso than slight over-allocation.
A longer answer:
Internet Engineering Task Force (IETF) - Best Current Practices:
RFC 6177 and BCP 157 - "IPv6 Address Assignment to End Sites" clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.
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 (more narrow) 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.
This document focuses on the (more narrow) 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.
This document does not make a formal recommendation on what the exact assignment size should be. The exact choice of how much address space to assign end sites is an issue for the operational community. 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.
2. 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.
A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for the vast majority of end sites, e.g., home sites) would result in a savings of up to 8 bits, reducing 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.)
3. Other RFC 3177 Considerations - ... Given the large amount of address space in IPv6, there is plenty of space to grant end sites enough space to be consistent with reasonable growth projections over multi-year time frames. Thus, it remains highly desirable to provide end sites with enough space (on both initial and subsequent assignments) to last several years. Fortunately, this goal can be achieved in a number of ways and does not require that all end sites receive the same default size assignment.".
RFC 7608 and BCP 198 - "IPv6 Prefix Length Recommendation for Forwarding"
Abstract - IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.
RFC 7934 and BCP 204 - "Host Address Availability Recommendations" recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so.
Introduction - "Unlike IPv4, IPv6 networks are not forced by address scarcity concerns to provide only one address per host. ... Furthermore, providing multiple addresses has many benefits, including application functionality and simplicity, privacy, and flexibility to accommodate future applications. Another significant benefit is the ability to provide Internet access without the use of Network Address Translation (NAT). Providing only one IPv6 address per host negates these benefits.
2. Common IPv6 Deployment Model - IPv6 is designed to support multiple addresses, including multiple global addresses, per interface (see Section 2.1 of [RFC4291] and Section 5.9.4 of [RFC6434]). Today, many general-purpose IPv6 hosts are configured with three or more addresses per interface: a link- local address, a stable address (e.g., using 64-bit Extended Unique Identifiers (EUI-64) or Opaque Interface Identifiers [RFC7217]), one or more privacy addresses [RFC4941], and possibly one or more temporary or non-temporary addresses obtained using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315].
In most general-purpose IPv6 networks, hosts have the ability to configure additional IPv6 addresses from the link prefix(es) without explicit requests to the network. Such networks include all 3GPP networks ([RFC6459], Section 5.2), in addition to Ethernet and Wi-Fi networks using Stateless Address Autoconfiguration (SLAAC) [RFC4862].".
RFC 4862 - "IPv6 Stateless Address Autoconfiguration" explains:
3. Design Goals
Stateless autoconfiguration is designed with the following goals in mind: o Manual configuration of individual machines before connecting them to the network should not be required. ... Address autoconfiguration assumes that each interface can provide a unique identifier for that interface (i.e., an "interface identifier"). ...
Small sites consisting of a set of machines attached to a single link should not require the presence of a DHCPv6 server or router as a prerequisite for communicating. Plug-and-play communication is achieved through the use of link-local addresses. Link-local addresses have a well-known prefix that identifies the (single) shared link to which a set of nodes attach. A host forms a link- local address by appending an interface identifier to the link- local prefix.
A large site with multiple networks and routers should not require the presence of a DHCPv6 server for address configuration. In order to generate global addresses, hosts must determine the prefixes that identify the subnets to which they attach. Routers generate periodic Router Advertisements that include options listing the set of active prefixes on a link.
Address configuration should facilitate the graceful renumbering of a site's machines. For example, a site may wish to renumber all of its nodes when it switches to a new network service provider. Renumbering is achieved through the leasing of addresses to interfaces and the assignment of multiple addresses to the same interface. Lease lifetimes provide the mechanism through which a site phases out old prefixes. The assignment of multiple addresses to an interface provides for a transition period during which both a new address and the one being phased out work simultaneously.
ARIN - "Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments".
ARIN - "Draft Policy ARIN-2011-3: Better IPv6 Allocations for ISPs".
All ARIN Policies.
IANA - Main Page - Protocol Registries - IANA-managed Reserved Domains.
IETF - "Considerations on the IPv6 Host density Metric - draft-huston-hd-metric-00.txt".
All IETF BCPs. (Archives).
Wikipedia's Best Current Practices (Currently not up to date).
APNIC - "IPv6 Best Current Practices".
Cloudmark's Whitepaper: "BCP for Near Term SMTP Deployments in IPv6 Networks".
NSRC.org - "Ingress & Egress Filtering Lab - Campus Network Design & Operations Workshop".
RIPE - "IPv6 Address Allocation and Assignment Policy" says (amongst many other things): "The minimum allocation size for IPv6 address space is /32. (for LIRs)", "To qualify for an initial allocation of IPv6 address space, an LIR must have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.", "LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 up to /29 without needing to supply any additional information.", ...
RIPE - "Understanding IP Addressing and CIDR Charts" (also see below) offers these helpful charts:
The original architecture of the Internet consisted mostly of large networks connecting to each other directly, and didn't look much like the hierarchical design used today. It was easy to give one huge address block to the military and another to Stanford University. In that model, routers had to remember only one IP address for each network, and could reach millions of hosts through each of those routes.
- IPv6 devices all have a unique address given to them as a default, IPv4 devices use a classful network and do not have a unique address due to an exhaustion of addresses which occurred between Jan 31 2011 and Sept 24 2015.
Here is an old map of the entire Internet in February 1982 compared with the Internet of today, StackExchange.com is the tiny dot in the center of the right image, click to zoom way in.
RFC 3484 - "Default Address Selection for Internet Protocol version 6 (IPv6)" was obsoleted by RFC 6724 (Sept 2012), new in the update is:
"Sections 2.1.4, 2.2.2, and 2.2.3 of RFC 5220 describe address selection problems related to Unique Local Addresses (ULAs) [RFC4193]. By default, global IPv6 destinations are preferred over ULA destinations, since an arbitrary ULA is not necessarily reachable.".
- A one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.
See: RIPE - "Understanding IP Addressing and CIDR Charts":
"Every device connected to the Internet needs to have an identifier. Internet Protocol (IP) addresses are the numerical addresses used to identify a particular piece of hardware connected to the Internet.
The two most common versions of IP in use today are Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). Both IPv4 and IPv6 addresses come from finite pools of numbers.
For IPv4, this pool is 32-bits (2^32) in size and contains 4,294,967,296 IPv4 addresses.
The IPv6 address space is 128-bits (2^128) in size, containing 340,282,366,920,938,463,463,374,607,431,768,211,456 IPv6 addresses.
Address Allocation Model
Currently, IANA allocates address blocks to the regional registries. The registries in turn assign address blocks to service providers. It is the service provider’s responsibility to hand out addresses to their respective customers.
The current policy varies by region and in the most conservative case dictates that an end user must go through the user’s service provider to get IPv6 address space rather than directly approaching the regional registry for IPv6 address space.
The figure graphically represents how this initial policy is enacted. This assignment model is commonly referred to as a provider assigned (PA) or provider dependent (PD) assignment. The prefix lengths that are shown in the figure are recommendations. The registries and service providers can assign blocks using the processes and procedures that they have established for their regions and customers. This is explained in RFC 6177.
RFC 6177 - "IPv6 Address Assignment to End Sites".
As an example of the policy, IANA has assigned 2600:0000::/12 to ARIN for assignment. This aligns with the top layer of the model. ARIN subsequently has assigned 2600::/29 block to Sprint, 2600:300::/24 to AT&T Mobility,
2600:7000::/24 to Hurricane Electric, etc.
These block assignments do not follow the original model defined in RFC 3177. The service providers subsequently assign blocks to their customers based on their customers’ needs. The Internet service provider (ISP) has the flexibility to assign a wide range of addresses to its customers.
For example, a large enterprise ISP customer might need a /40 assignment while a residential customer would only need a /60 assignment.
There is an exception to this policy enacted by the regional registries that allows end customers to directly approach registries and request IPv6 address space. This exception is known as provider independent (PI)
RFC 5375 - "IPv6 Unicast Address Assignment Considerations" outlines some issues that also need to be taken into account when building an addressing plan.
You should first decide if you want provider independent address blocks or is provider assigned addressing acceptable?
If the customer has PI addresses the assignment will remain valid providing the criteria for the original assignment are met.
Customers with PA addresses are recommended to obtain a new address space assignment from another LIR and return the PA address space that was assigned by their original LIR. In this
There's more, consulting the IANA and IETF links above is the best way to stay on top of the best practices.