In IPv4, the subnet mask
255.255.255.0 is 32 bits and consists of four 8-bit octets. The address:
10.10.10.0 subnet mask
255.255.255.0 means that the subnet is a range of IP addresses from
10.10.10.0 - 10.10.10.255.
The prefix-length in IPv6 is the equivalent of the subnet mask in IPv4. However, rather than being expressed in four octets like it is in IPv4, it is expressed as an integer between 1 through 128. For example:
2001:db8:abcd:0012::0/64 specifies a subnet with a range of IP addresses from:
2001:db8:abcd:0012:0000:0000:0000:0000 - 2001:db8:abcd:0012:ffff:ffff:ffff:ffff. The portion in bold is called the network portion of the IP address, or the prefix. The non-bold portion is called the host portion of the IP address, since it identifies an individual host on the network.
An IPv6 address is eight groupings of numbers:
- Network address – the first three groupings of numbers (first 48 bits) in the subnet mask
- Subnet address – the fourth grouping of numbers (the 49th through 64th bits) in the subnet mask
- Device address – the last four groupings of numbers (the last 64 bits) in the subnet mask
For example, in the following IPv6 address:
The network address is
2001:db8:abcd, and the subnet address is
12 (using the short form notation and eliminating the leading zeroes). Together, these two groupings are the IPv6 prefix. The device address in the example is
Each device in the network has a unique device address. But, the network address and subnet address portions of the IPv6 address are the same for every device in the network. So, the first four groupings of numbers in every IPv6 address remain constant, and the last four groupings of numbers vary with each device. You can simplify your list of devices by substituting a prefix-length in place of the device address portion of the IPv6 address. The prefix-length specifies a range of devices. It is expressed as a slash (/), followed by an integer between 1 through 128. For example, a prefix-length of
/64 specified like this:
2001:db8:abcd:0012::/64 tells the system to divide the network into 64 subnetworks. Each subnetwork contains 1/64th of the devices on the network. Table 1 shows the resulting network ranges for prefix lengths of IPv6 addresses.
Real Environment Subnetting.
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.
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:
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:
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!