(Oprah IPv6 meme courtesy of Scott Hogg!)
Among the available IPv6 address planning principles, the general rule of assigning a /48 per site is particularly significant and beneficial. It’s significant because it acknowledges a basic unit of address resource consumption with IPv6. And why is that? Well, given that right-most 64 bits of the 128 bits available in an IPv6 are reserved for host identification, the smallest permissible subnet (with a few historically significant exceptions) is a /64. Also, recall that this is the subnet size designated for assignment to a single network interface. But since the 64 bits available for host addressing in a /64 provides 18 quintillion – i.e., 1.8E19 or 18,446,744,073,709,551,616 host addresses, any proposed metric of consumption given such an astronomically large pool is essentially meaningless. Thus, it makes more sense to use IPv6 prefixes to measure IPv6 address consumption.
Since we’re picking on the /64 at the moment, we could consider using it. And indeed, as a metric of consumption for smaller deployments it works perfectly well. But recall that we began our discussion with the principle of assigning a /48 per site. As it happens, the Regional Internet Registries (RIRs) tasked with allocating IPv6 (and IPv4) address resources use a /48 as the basic measure of address consumption in IPv6. This would seem intuitively to align well with the idea of assigning a /48 per site. To add to this significance, a /48 is the smallest Internet routable IPv6 prefix. Thus, assigning a /48 to a site ensures that site can be directly connected to the Internet immediately as well as in the future. Wearing my network architect hat, I take comfort in the assumption that I’m future-proofing the direct Internet routability of any site along with the resulting guaranteed flexibility of my routing policies.
An obvious question that arises from asserting the principle of assigning a /48 per site is, well, what exactly constitutes a site? The simple answer is whatever we decide makes sense for the definition of a site given the operational requirements of our network and organization. Examples from enterprises and service providers in the real world have defined sites variously as corporate campus networks, data centers, IoT gateways, regional offices, home gateways (e.g., cable or DSL modems), and even endpoints for 6to4 tunnels terminated to a single host! Given the various relative sizes of the networks associated with each of these examples, we should be comfortable inferring that no effort is made to reduce the size of the assigned prefix and resulting subnets and host addresses to match the size of the location. Note that the opposite case of sites with very large networks, or sites requiring an abundance of IPv6 prefixes for operational, security, or routing policy reasons, might require us to increase the size assigned to such a site beyond a /48 to say a /44 or even a /40.
Once we’ve allocated a /48 to a site, we’ve got to make some design choices for how to divide up and assign the prefixes it contains. Fortunately, some simple organizing principles will make this task much easier to manage effectively.
16 Bits to Freedom
With a /48 assigned to a site and a /64 as the smallest prefix assignable to an interface, we can identify the scope of the address resources we have at our disposal. Essentially, we have a total of 16 bits to work with. How we choose to organize these available 16 bits will determine the structure of our address plan for a given site.
The simplest choice requires little additional organizational thought or effort: just begin assigning /64s from the pool available in a /48. For example, if our site prefix is 2001:db8:abcd::/48, that gives us 65,536 /64 prefixes. A list of these would start with:
2001:db8:abcd::/64
2001:db8:abcd:1::/64
2001:db8:abcd:2::/64
.
.
.
2001:db8:abcd:ffff::/64
Note that the zero compression rules of IPv6 address representation require us to drop any leading zeros. This means we have to pay close attention to the CIDR notation of the prefix to make sure we haven’t confused two prefixes that have the same address representation but are actually of different sizes (as in our example above, 2001:db8:abcd::/48 and 2001:db8:abcd::/64).
Starting with this pool of 65,536 /64s we could start by assigning the first /64 from the list to the first interface and proceed sequentially in assigning additional /64s. Such an approach makes perfect sense for a very small site that has a very small number of total interfaces and/or very little internal organizational structure or network topology complexity.
For most larger or more complex sites however, assigning IPv6 subnets in a way that reflects some or all of the hierarchy and/or internal organization within the site can provide immediate and future operational benefits. As it happens, the hexadecimal structure of an IPv6 address and its associated network prefix provides an inherent method to efficiently and neatly represent such hierarchy in the form of the nibble boundary.
Respecting One’s (Nibble) Boundaries
A nibble boundary is the boundary that naturally occurs between any two adjacent groups of 4 bits whose value is factorable by 24n. If that definition is little too formal, it’s perhaps easier to visualize using a random string of bits starting at the first bit of the address:
1011|0111|1100|0010|0010|etc.
Adhering to this boundary has specific consequences. First, it produces CIDR values for any IPv6 prefixes that are always multiples of four. For example, we’re discussing an overall site prefix that is a /48 (12×4). The next nibble boundary for smaller prefixes would be a /52 (13×4), then /56, /60, and finally /64. As mentioned already, we don’t generally subnet beyond a /64. And of course, moving beyond an individual site to larger prefixes, such as those for an organizational allocation, the same concept applies (e.g., /44, /40, /36, /32, etc.).
The next consequence of adhering to the nibble boundary is that it makes a specific prefix more legible and easier to identify for address management and tracking as well as operational purposes.
In the example above I have two prefixes with the same first three hextets of 2001:db8:1. The first is a /48 (on the nibble boundary) and the second is a /49 (not on the nibble boundary). In the case of the /48, we may observe that the 2001:db8:1 value will always precisely identify whatever entity it is assigned to (given that it’s a /48 in this example, that entity would most commonly be a particular site). In the case of the /49, the same 2001:db8:1 doesn’t provide information sufficient enough for immediate identification. In fact, by moving away from the nibble boundary, it becomes necessary to examine the next hexadecimal character in the address (e.g., just to the right of the prefix defined by the nibble boundary) in order to determine which group of subnets resulting from a non-nibble CIDR value the prefix refers to. In the specific example above, the non-nibble boundary /49 creates two prefixes of 2001:db8:1:0::/49 and 2001:db8:1:8::/49 resulting in ranges of 2001:db8:1:[0-7]… and 2001:db8:1:[8-f]. Let’s look at the results of moving one more bit away from the nibble boundary to a /50 given our example.
In an instance where we are required to troubleshoot a network issue involving any of these non-nibble prefixes, we can’t rely on the first three hextets alone to precisely identify the entity a particular prefix is assigned to. Rather we must correlate the CIDR value to a range of hexadecimal values in the character just to the right of the nibble boundary in the address. The values in this address location will vary depending on which non-nibble CIDR value we have used. By comparison, skipping past the non-nibble CIDR values to the next nibble boundary (the /52) results in the following:
As with a /48 being assigned to an entire site, each of the /52s might be assigned to a particular logical entity (such as a routing or security domain) or physical entity (such as a building or floor) within that site (something we’ll discuss in more detail in Part 2 of this blog). But regardless of what a prefix is assigned to, the legibility of the prefix and ease of identification gained by adhering to the nibble boundary is greatly improved.
Hopefully, these examples make it clearer that adhering to the nibble boundary when creating and assigning IPv6 prefixes results in faster identification and any subsequent management and operations that much easier.
In Part 2 of the blog, we’ll explore our options for creating organization and different logical hierarchies within a given site by assigning different groups of IPv6 prefixes. Stay tuned!
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.
