IPv6 Subnetting - Bit Based Subnetting

IPv6 Subnetting is fairly simple if you can subdivide your addresses with 16 branches at each of four levels (as covered in the Basic Concepts article):

1 /48 block (2001:470:3d::/48) - 65,536 subnets per /48
-- 16 /52 blocks (e.g. 2001:470:3d:2000::/52) - 4096 subnets per /52
---- 256 /56 blocks (e.g. 2001:470:3d:2400::/56) - 256 subnets per /56
------ 4,096 /60 blocks (e.g. 2001:470:3d:2410::/60) - 16 subnets per /60
-------- 65,536 /64 blocks (e.g. 2001:470:3d:2414::/64) - 1 /subnet per /64

But what if your requirement doesn't fall neatly into these levels? For example, you have a /48 and need to divide it up into 900 equal sized blocks for a lot of branch offices, each of which want to be able to provision as many subnets as possible with /64 blocks.

You can't use /52 blocks, you have only 16 of them. You can't use /56 blocks, you have only 256 of them. You could use /60 blocks, because you have 4096 of them. But with /60 blocks, you can only provision 16 subnets in each. But 75% of your /60 subnets are not being used.

The solution is to do bit-based subnetting - in other words, using a block size that is not on a 4-bit boundary. How do you calculate how many bits to use?

You could try them one by one. The /56 blocks are too big (not enough of them), and the /60 blocks aren't big enough (can only provision 16 subnets with each). So, try the values in between:

There are 512 /57 blocks in a /48, each of which can provision 128 subnets.

There are 1024 /58 blocks in a /48, each of which can provision 64 subnets.

There are 2048 /59 blocks in a /48, each of which can provision 32 subnets.

Ah! We have an answer - break your /48 up into 1024 /58 blocks. That will handle your 900 branch offices, and allow each of them to have 64 subnets (better than only 16 subnets each). The only problem is the prefixes are a little tricky since /58 doesn't fall on hex digit boundaries. So what do your prefixes look like?

If your /48 was 2001:470:3d::/48, the prefixes of the 1024 /58 blocks would be:

and so on up to the 1024th one

You could calculate how many bits you need, but since there are only 16 possible places to divide the Subnet ID, the easiest solution is to use the following chart:

Prefixlen     # blocks      # /64 subnets per block
   48                1            65,536
   49                2            32,768
   50                4            16,384
   51                8             8,192
   52               16             4,096
   53               32             2,048
   54               64             1,024
   55              128               512
   56              256               256
   57              512               128
   58            1,024                64
   59            2,048                32
   60            4,096                16
   61            8,192                 8
   62           16,384                 4
   63           32,768                 2
   64           65,536                 1

A quick glance at this would tell you that /58 is the shortest prefix length that will give you enough equal sized blocks to provision 900 branch offices, and each is able to provision 64 subnets.

You should of course take growth into account. The /58 prefix length could only accomodate 1024 branch offices. Is your organization likely to add more than 124 additional branch offices in the next decade? If not, great - use /58. If so, it would be safer to choose /59 block size (assuming being able to provision only 32 subnets per branch is sufficient). This would allow growth to more than double the current 900 branch offices (actually up to 2048 branch offices).

What if you have a few big branch offices that need to provision more than 32 subnets each? You could simply allocate multiple contiguous /59 blocks to those offices (on power of two boundaries, so that a single CIDR prefix could specify it). For example, your biggest branch office might require four /59 blocks (they need to provision up to 128 subnets). Give them the first four contiguous /59 blocks (that is actually a /57 block). The next three branch offices might require two /59 blocks each (they need to provision up to 64 subnets each). Given each of them two contiguous /59 blocks (those are actually /58 blocks). All the rest can make do with a single /59 block. The routing can be set up easily to provide each branch office what they need. For example:

route 2001:470:3d::/57 to branch office 1 (the big one)
route 2001:470:3d:80::/58 to branch office 2
route 2001:470:3d:c0::/58 to branch office 3
route 2001:470:3d:100::/58 to branch office 4
route 2001:470:3d:140::/59 to branch office 5
route 2001:470:3d:160::/59 to branch office 6
and so on

To provide for growth, you could provide the big branch offices with even larger contiguous chunks (e.g. give your biggest branch not just 4 contiguous /59 blocks, but 8 - a /56 block), until you get down to those for which a /59 block will be enough for the next decade. Just be careful to line up allocated blocks on power of two boundaries. If you allocate contiguous blocks in power of two groups (2, 4, 8, 16), and start with the first /59 block, this will naturally happen.

The IPv6 subnet calculators available online may help you with these decisions. For example, see the calculator at subnetonline.com. If you enter the "Address" (actually prefix) as 2001:470:3d:/48, and choose 900 subnets (enter 900 and click Add Level), it will tell you that you need 10 bits (hence /58 blocks). On the result page (if you expand the 2001:470:3d::/48 item), it will show the following list:

1     2001:470:3d::/58
2     2001:470:3d:40::/58
3     2001:470:3d:80::/58

and so on. Looks a lot like what we came up with by hand. You would have to know that 210 is 1,024, which doesn't leave a lot of room to expand. In my opinion, it's easier to do it by hand, using the above table.