LACNIC Blog
> IPv6 > The benefits of assigning more than a /48 per site*
The benefits of assigning more than a /48 per site*
07/03/2024
Written by Tom Coffeen, Co-founder of HexaBuild.io
Originally published in Infoblox blog on February 22, 2024
In my blog A /48 for Every Site and For Every Site a /48 (Parts 1 and 2), the title itself attempts to capture and summarize a general but critical IPv6 address planning principle: When designing an address plan, assign at least a /48 to every site. But is a single /48 always enough for every site? And if not, what prefix size would be and how would the assignment of a larger prefix impact the overall address plan?
To recap briefly, recall that for most network engineers and architects the word “site” has very tangible associations with specific physical network locations: data centers, campuses with LANs, remote offices, etc. Since the networks at each of these locations vary both in size and the number of users they support, it’s natural to attempt to categorize them accordingly; e.g., small, medium, large, extra-large. As it turns out, the scarcity of IPv4 addressing makes such categorization essential. The IPv4 prefix or prefixes available to assign to a site may be few and constrained in size. Because of this, a small remote office might need only a /28 of IPv4 while a headquarters campus LAN might require a /20. If we’re exceedingly lucky, our small, medium, large, and extra-large sites might at least have consistently sized prefixes sufficiently available for each size category. For example:
Size of Site
IPv4 Prefix Assigned
IPv4 Addresses
Small
/28
16
Medium
/24
256
Large
/20
4096
Extra-large
/16
65536
But realistically, the availability of private (i.e., RFC 1918) IP address space is so limited in most enterprises that even such minimal consistency is often impossible. What results are site prefixes of various lengths that are difficult if not impossible to easily summarize for routing, or to permit the simplification of security ACLs.
By comparison, the overall abundance of IPv6 allows for the assignment of a consistently sized, or “one size fits all,” IPv6 prefix for a site (for example, a /48 or larger) regardless of the site’s physical size, diameter of networks, number of users, etc. The uniformity of such site assignments makes routing summarization and ACL simplification much easier. This consistency can also further simplify network administration and operations – especially given that the recommended IPv6 prefix size should always fall on a nibble boundary. The unique network portion of a nibble-aligned prefix assigned to a site can be used to identify the site more easily – most beneficially when administering or troubleshooting the network.
In my blog IPv6 Prefix Allocation Methods (Parts 1 and 2) I describe the most typical methods for assigning prefixes from a larger allocation. Of these, we’ll demonstrate the next available method, and its limitations, first. The following graphic depicts an initial address plan with resulting site assignments of a /48 per site. Each site prefix is assigned sequentially from a /44 which provides up to 16 total sites.
(Free access, no subscription required)
Note that in the example this total of available prefixes decreases to 15 because we have skipped using the first available prefix of 2001:db8:1000::/48. This is done to align the site count with the prefix enumeration (e.g., Site 1 = 2001:db8:1001::/48, Site 2 = 2001:db8:1002::/48). This also may help avoid confusing two prefixes that appear identical because of IPv6 address zero compression rules but that have different CIDR lengths (e.g., 2001:db8:1000::/44 and 2001:db8:1000::/48).
But what should happen when a site grows or changes in a way that requires additional IPv6 prefix space? And how can we then plan to provide additional prefix space while maintaining those planning practices that provide the greatest operational benefits? We wouldn’t want to have to renumber our site to try to extend the use of the single assigned /48 site prefix – especially when a properly large overall allocation should provide enough /48s to allow the addition of one or more to an existing site. But if we don’t plan, it’s possible that additional /48s for a site could be noncontiguous with the initial /48 site allocation. Such lack of contiguousness isn’t necessarily the end of the world, but it can result in more (and earlier) disaggregation of the IPv6 address space within the network. Always being able to identify a site by a single prefix that is summarized in the routing table and that has a single security boundary (and associated ACL entry) provides clear operational and administrative benefits.
One way to ensure that contiguous /48s are available is to reserve them in advance – ideally at the same time the initial address plan is being designed. But how many additional /48s should be reserved per site? The lower bound is obviously one additional /48. Any additional reserved /48s up to the first nibble could only be summarized along a non-nibble boundary. But any attempt to only add additional /48s as each site needs them, and then to summarize as much as possible, will result in a collection of different summary prefixes for different sites. These summaries would not be as legible in a routing table as a single nibble-aligned prefix for each site.
Note that in the example this total of available prefixes decreases to 15 because we have skipped using the first available prefix of 2001:db8:1000::/48. This is done to align the site count with the prefix enumeration (e.g., Site 1 = 2001:db8:1001::/48, Site 2 = 2001:db8:1002::/48). This also may help avoid confusing two prefixes that appear identical because of IPv6 address zero compression rules but that have different CIDR lengths (e.g., 2001:db8:1000::/44 and 2001:db8:1000::/48).
But what should happen when a site grows or changes in a way that requires additional IPv6 prefix space? And how can we then plan to provide additional prefix space while maintaining those planning practices that provide the greatest operational benefits? We wouldn’t want to have to renumber our site to try to extend the use of the single assigned /48 site prefix – especially when a properly large overall allocation should provide enough /48s to allow the addition of one or more to an existing site. But if we don’t plan, it’s possible that additional /48s for a site could be noncontiguous with the initial /48 site allocation. Such lack of contiguousness isn’t necessarily the end of the world, but it can result in more (and earlier) disaggregation of the IPv6 address space within the network. Always being able to identify a site by a single prefix that is summarized in the routing table and that has a single security boundary (and associated ACL entry) provides clear operational and administrative benefits.
One way to ensure that contiguous /48s are available is to reserve them in advance – ideally at the same time the initial address plan is being designed. But how many additional /48s should be reserved per site? The lower bound is obviously one additional /48. Any additional reserved /48s up to the first nibble could only be summarized along a non-nibble boundary. But any attempt to only add additional /48s as each site needs them, and then to summarize as much as possible, will result in a collection of different summary prefixes for different sites. These summaries would not be as legible in a routing table as a single nibble-aligned prefix for each site.
To better demonstrate this, here’s a graphic depicting an example of future assignments of /48s to our original sites based on the next available prefix allocation method. Site 4 goes first in asking for additional IPv6 space (say, for an Out-of-Band (OOB) overlay network) and is assigned the next available prefix of 2001:db8:1004::/48. Later still, Site 4 adds a data center that will need its own /48 and the next available prefix of 2001:db8:1005::/48 is assigned. Site 1 learns about the cool OOB overlay Site 4 deployed and wants to do the same thing. So, the next available prefix of 2001:db8:1006::/48 is assigned to them. The same thing happens with Site 3: They are assigned the next available prefix of 2001:db8:1007::/48. Now site 4 realizes they need to add another data center, but this time with more multi-tenant support, and so the next two available prefixes are assigned: 2001:db8:1008::/48 and 2001:db8:1009::/48. As a result of these asynchronous IPv6 prefix requests met by assigning the next available prefix, the routing table and/or ACL entries are a bit of a mess (and will likely only get messier with the further application of this method).
So, if we’re better off using a single nibble-aligned prefix, what should it be? To answer this question, it might be helpful to think through what a reasonable upper bound on the number of additional /48s per site might be necessary. Keep in mind that this would be the upper bound for the largest of our sites overall (with every other remaining site of any size receiving the same assignment as the largest site). The next largest nibble-aligned prefix is a /44, which provides 16 /48s in total – one initial /48 assigned to the site and 15 /48s held in reserve. A /40 would provide 256 /48s (or 255 /48s held in reserve). A /36 would provide a reserve of 4,095 /48s.
So, which of the larger nibble-aligned should we select for our largest site? The reality is that it’s hard if not impossible to know in advance how much additional prefix space may be required and/or prove useful. We must keep in mind that, the more site prefixes we hold in reserve for each site, the more of our overall allocation we will consume. This may reduce the ability to create additional structure at the top of our address plan. For example, perhaps we require having enough prefixes to allow for regional summarization on a nibble boundary for a prefix that summarizes sites. Or perhaps we need to hold in reserve nibble-aligned prefixes for future use at the top level of the address plan (e.g., the first 16 nibble-aligned prefixes derived from the overall IPv6 allocation). But for now, let’s continue to focus on the question of how to best size our site assignments.
The following graphic depicts an alternate, more optimal outcome based on our previous example. Instead of assigning only 1 /48 per site initially, a /44 is per site is allocated. For this example, the network team doesn’t anticipate adding more than 16 sites total in Region 1 and so a /40 is allocated to it from which the /44 prefix per site is taken. Now when each of the sites require additional /48s – for whatever purpose – up to 15 additional prefixes will be available. These additional /48s per site will always be summarized as a /44 to Region 1, and Region 1 will summarize these upstream as a /40.
Note that the regional assignment of a /40 shown above is just to demonstrate a nibble aligned summarization of the /44 site prefixes. It’s based on the assumption that the example network already finds it beneficial to manage the network using a geographically-based topology. By contrast, some networks are large enough that a single site might benefit from the allocation of a /40 to that site followed by one or more initial /48 assignments. In that case any desired regional summarization might ideally take place at the next largest nibble boundary of a /36.
Regardless, it is evident that using this sparse allocation method for site assignment within the enterprise may result in the need for a larger IPv6 allocation. This is especially true where the address planning best practice of maintaining strict nibble alignment for IPv6 prefix assignments is followed. Many enterprises that have already obtained IPv6 allocations may find that the size of those allocations will not simultaneously support sparse allocation for site assignments and/or strict nibble alignment of IPv6 prefixes.
Fortunately, it is a relatively easy and inexpensive process to obtain a larger allocation from whichever of the five Regional Internet Registries (RIRs) corresponds to your primary operational region. Also keep in mind that whatever your on-premises network requirements for IPv6 address space happen to be, you’ll also need to consider your current and planned cloud deployment addressing needs (perhaps utilizing BYOIPv6). It may be desirable for security reasons (or even just administrative ease) to maintain one or more address spaces outside of (but perhaps parallel with) your on-premises IPv6 address space. And don’t forget to consider future networks added due to Merger and Acquisition activity. While it’s always possible to get additional IPv6 address space, future allocations are not likely to be contiguous with your initial allocation and may increase the risks of having to renumber. This is especially true if you’re trying to “make do” with your initial IPv6 allocation from years past.
*Reposted with permission, courtesy of Infoblox”
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
