How to: calculating IPv6 subnets outside the nibble boundary

A question that I’m often asked by people who are deploying IPv6 for the first time is, “How do you calculate subnets outside the 4-bit nibble boundary?”.

This also happens to be one of the starting points of an APNIC IPv6 Routing workshop that I occasionally instruct as a community trainer, and so, I thought I’d share in this post the basics of nibble boundaries and how to calculate subnets outside of them.

What is a nibble boundary?

In the context of IPv6, the nibble boundary refers to 4 bits. Any change in multiples of 4 bits is easy to calculate — here’s how.

Let’s say we have an allocation: 2001:db8::/32. Taking slices from this pool within a 4-bit boundary is quite easy.

/36 slices (1 x 4 bits)
2001:db8:0000::/36
2001:db8:1000::/36
2001:db8:2000::/36
and so on…

/40 slices (2 x 4 bits)
2001:db8:0000::/40
2001:db8:0100::/40
2001:db8:0200::/40

/44 slices (3 x 4 bits)
2001:db8:0000::/44
2001:db8:0010::/44
2001:db8:0020::/44

/48 slices (4 x 4 bits)
2001:db8:0000::/48
2001:db8:0001::/48
2001:db8:0002::/48

It seems like a simple process right? Which is why we often strongly recommend subnetting within the nibble boundary and not outside for all practical use cases. That said, understanding why it’s easy (and necessary) is important, particularly if you are running a very large network and have a /29 allocation.

Back to fundamentals

IPv6 addresses consist of 128-bit addressing and are represented in hexadecimal notation.

_ _ _ _: _ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _

In the above diagram, each dash represents 4 bits. Therefore 4+4+4+4 = 16 bits in each block. And 16 x 8 = 128-bit addressing. This represents that magical 4-bit nibble boundary.

So, if we expand 4 bits into binary, we can have the following combinations for each ‘dash’ in the above representation:

0 0 0 0
0 0 0 1
0 0 1 0
0 0 1 1
0 1 0 0
0 1 0 1
0 1 1 0
0 1 1 1
1 0 0 0
1 0 0 1
1 0 1 0
1 0 1 1
1 1 0 0
1 1 0 1
1 1 1 0
1 1 1 1

Remember just like the decimal system with base 10 (which we all are familiar with), we follow the same logic in the binary system where we start from the lowest digit (0 0 0 0) and go to the next digit (0 0 0 1). For base 2, we go to next logical number, which is (0 0 1 0) and so on.

When we modify these 4 bits together we don’t have to worry about the decimal part, but as soon as we try to go inside the 4-bit zone, we have to deal with the decimal counting.

So, let’s take a real-world case of American cable and broadband provider Comcast. They have an allocation 2001:558::/31

NetRange: 2001:558:: - 2001:559:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
CIDR: 2001:558::/31
NetName: COMCAST6NET
NetHandle: NET6-2001-558-1
Parent: ARIN-001 (NET6-2001-400-0)
NetType: Direct Allocation
OriginAS: AS7922
Organization: Comcast Cable Communications, LLC (CCCS)
RegDate: 2003-01-06
Updated: 2016-08-31
Ref: https://whois.arin.net/rest/net/NET6-2001-558-1

What exactly does /31 means here?

If we go back to CIDR fundamentals, the /31 refers to the 31 bits that are reserved and remaining from 128 (that leaves 97 bits available). How can you generate a /32 or say /36 out of this 2001:0558::/31 allocation?

The first 16 bits are reserved for 2001 but for the next part, 0558, only 15 bits are reserved.

Let’s expand the second block further:

0 5 5 8 = 15 bits reserved

Here 0 gives 4 bits (and in binary is 0 0 0 0).
5 gives 4 bits (and in binary is 0 1 0 1).
The next 5 also reserves 4 bits.

So far we are at (4 + 4 + 4). That makes it a 12-bit count. Because only 15 bits are reserved for this block, the 8 gives us 3 bits; the left over 1 bit is available for modification.

Let’s expand 8:

8 in hexadecimal = 1 0 0 0 in binary. Here 1 0 0 is reserved (each representing 1 binary bit, hence the 3 bits) and the 4th bit can vary. Hence, the possible combinations in binary are:

1 0 0 0
1 0 0 1

The remaining first 3 bits (1 0 0 ) cannot be altered as they are part of a network mask. Now 1 0 0 0 in binary gives us 8 in hexadecimal and 1 0 0 1 gives us 9. Therefore, the possible /32s out of this 2001:558::/31 allocation are:

2001:558::/32
2001:559::/32

Similarly, to calculate a /36 slice from it, we can vary this 1 bit (as we just did), as well as the next 4 bits altogether (5-bit variation). Hence, the possible /36 slices are:

2001:558:0000::/36
2001:558:1000::/36
2001:558:2000::/36
2001:558:3000::/36

and so on until 2001:558:f000::/36 (16 pools here). Next:

2001:559:0000::/36
2001:559:1000::/36
2001:559:2000::/36
2001:559:3000::/36

and so on until 2001:559:f000::/36 (16 pools here).

Thus, we get these 32 /36 blocks out of the /31 allocations.

As you can imagine, this practice of subnetting outside of the nibble boundary is quite useful for very large networks like Comcast’s, which allocate really large IPv6 blocks. It is less useful for standard allocations such as a /32 — you can have different subnet sizes such as /64s out of a /32 or a /48.

Usually it’s common to break down an allocation to have:

1. A large chunk as the allocation.
2. A small part for internal use.
3. The rest of it for allocation to the customer.

Once you understand the concept and use, you should be just fine with subnetting in the future.

Adapted from original post that appeared on anuragbhatia.com

Anurag works at global IP transit and datacenter provider Hurricane Electric and is based in India. His expertise is around DNS, BGP routing, anycast and IPv6.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.