Part one of this blog reviewed the concept of a site in IPv6 address planning. It also discussed the reasons why a /48 is considered the preferred prefix size for assignment to a site. This time around, we’ll take a look at what to do with a /48 once you’ve assigned it to a site.
As with other IPv6 prefixes, the sheer number of host addresses in a /48 (i.e., 1,208,925,819,614,629,174,706,176 or about 1.2×1024) means that without some sort of organizing framework we’ll probably have a hard time intuiting how to begin to assign them. Fortunately, we can conjure one pretty easily based on some other simple IPv6 principles.
Recall from part one that a /64 is considered to be the standard interface subnet. As such, it’s the smallest subnet we should ever assign. So how many of these smallest assignable subnets are available in a /48? The CIDR notation makes it easy to see that we’re working with a difference of 16 bits from a /48 to a /64 and 216 equals 65,536. Thus we have 65,536 /64s in a /48 to work with.
The number 65,536 is probably a little more in your comfort zone – it’s certainly in mine! Depending on the type of site we are allocating subnets to, we could simply begin assigning /64s to interfaces knowing that we have 65,536 of them neatly lined up (in the case where we begin assigning them sequentially) or, if you prefer, lying around in a big pile (in the case where we begin assigning them at random).
Sequential Assignment:
2001:db8:acdc::/48
2001:0db8:acdc:0000::/64
2001:0db8:acdc:0001::/64
2001:0db8:acdc:0002::/64
2001:0db8:acdc:0003::/64
…
2001:0db8:acdc:ffff::/64
Random Assignment:
2001:db8:acdc::/48
2001:db8:acdc:5bdc::/64
2001:db8:acdc:067c::/64
2001:db8:acdc:abe8::/64
2001:db8:acdc:2112::/64
…
2001:db8:acdc:7be1::/64
(Note that the above examples, as well as the ones to follow, use the IPv6 prefix reserved for documentation.)
There are of course other much more structured ways to assign /64s within a site, which we will discuss below. But either of the above methods is perfectly fine to use for any site that isn’t large, complex, or relatively flat from a L2/L3 perspective.
Examples of smaller sites using sequential or random allocation might include home networks or remote offices. Labs where IPv6 is being tested (especially in an ad-hoc fashion) may not require any particular structure to the subnet assignments. Even data centers, which might be relatively large in terms of the overall number of nodes, can still be flat enough that sequential or random assignment could work (though a reliable IPAM solution would likely be required).
The choice between sequential (sometimes referred to as N+1 or monotonic assignment) and random is probably somewhat arbitrary for smaller sites. As for larger sites, some network security doctrine (or dogma, depending on your particular perspective) suggests that a security dividend might be realized merely by obscuring network address topology in some general fashion (e.g., random assignment). If you read this blog on a regular basis or follow any of the IPv6 community you’re probably already aware that this “security through obscurity” argument is most often strongly rejected, mainly because of its association with IPv4 NAT (the legacy technology seen as both an impediment to IPv6 adoption and one that carries a tremendous amount of technical debt – Check out the IETF RFC 4864 “Local Network Protection for IPv6” for some reasons why NAT is unnecessary for IPv6).
For larger, more complex, and more hierarchical sites, organizing those 65,536 /64s in some fashion could help maintain or even improve operational efficiency. For example, let’s imagine a site comprised of a campus network with several (let’s say 10) buildings. Using nibble boundaries (if you’re unclear on what a nibble boundary is, please review part one of this blog), 16 bits of a /48 can be allocated in the following manner:
Each nibble boundary results in a group of prefixes with a number of /64 subnets. As we might infer, allocating more nibbles to provide a greater number of prefixes (e.g., /52, /56, /60, etc.) results in each of those available prefixes having fewer /64 subnets to assign to interfaces.
Using our example of a campus network site, we can proceed by counting the number of buildings we need prefixes for and determining which of the nibble boundaries provides a sufficient supply. From the above table, it’s apparent that any of the prefix sizes – /52, /56, or /60 – would provide enough prefixes. In case it’s not obvious, we exclude a /64 from the running given that choosing it would result in having to sequentially or randomly assign /64s without regard to site structure as in our description above.
Since a /52, /56, or /60 would all work given only 10 buildings, which do we choose? To help answer that, it might help to consider what level of growth, if any, we anticipate in the number of buildings. Ten buildings would consume 63% of the available pool of /52s (with each /52 providing 4,096 /64s). An often-used capacity planning principle when it comes to IPv6 prefixes is to move up to the next largest pool of subnets when consumption of the existing pool of subnets exceeds 75% (or in our example, 13 buildings requiring 13 /52 prefixes). Choosing a /56 prefix size would provide enough /56 prefixes for 256 buildings. But remember from the table that as we increase the number of prefixes we reduce the number of /64s available to assign to interfaces for each of those prefixes. For example, by the time we get to the /60 level, we could have 4,096 /60 prefixes but each would only give us 16 /64s for interface assignments – very likely an insufficient number given the networks typically found in a campus network building.
To complete our example, we’ll assume that we don’t anticipate any growth (i.e., additional buildings) at our site and that a /52 is the prefix size we wish to use for all buildings. From this choice we can proceed to planning our address assignments. Here’s an example showing the beginning of numbering for the first three buildings.
You’ll notice that the prefixes assigned provide unambiguous identification of both the site (e.g., 2001:db8:1::/48), each building (e.g., 2001:db8:1:1000::/52), and each interface assignment (e.g., 2001:db8:1:1001::/64). Such identification can be particularly useful when troubleshooting network issues. By always adhering to nibble boundaries in IPv6 assignment, such operationally beneficial identification is ensured.
At this point, you should have enough information to run through a few other scenarios applying the principles described above to your own network(s).
Reach out if you have any questions about the article. You can also hire my company HexaBuild to help you design and build your address plan if you are unsure of how to proceed!
Thanks for reading!
Tom Coffeen (@ipv6tom) is a co-founder of HexaBuild, an IPv6 consulting and IPv6 training company. Tom is the author of IPv6 Address Planning on O’Reilly Media. You can follow HexaBuild on Twitter and LinkedIn.
