Almost every conversation I have with folks just learning about IPv6 goes about the same way; once I’m finally able to convince them that IPv6 is not going away and is needed in their network, the questions start. One of the most practical and essential early questions that needs to be asked (but often isn’t) is “how do I lay out my IPv6 subnets?”

The reason this is such an important question is that it’s very easy to get IPv6 subnetting wrong by doing it like you do in IPv4. The problem is that there is a paradigm shift needed from IPv4 subnetting to IPv6 subnetting—you simply can’t approach them the same way. The reason for this harkens back to the primary driver for deploying IPv6 in the first place: More addresses! So many more in fact that individual addresses become essentially meaningless in IPv6 address planning and subnetting. A single IPv6 /64 subnet contains roughly ten quintillion addresses, quite obviously more than you will ever need in one IP network segment. Even considering machine to machine communications and all the myriads of devices which will someday be IP enabled, you are extremely unlikely to ever put more than 10,000,000,000,000,000,000 hosts on a single bridged network.

So, the first thing you must do when approaching IPv6 subnetting is to wrap your head around the new paradigm of address abundance, leaving behind the mentality of IPv4 address scarcity. While IPv4 subnetting is all about addresses, IPv6 subnetting is all about networks. Instead of counting hosts, and sizing individual subnets based on the number of addresses needed (managing scarcity), we now count routers and build hierarchy based on the networks they support. We know that a /64 can address any number of hosts we’ll through at it, so why worry about how many there are? The answer is that you don’t. You simply assign one subnet to each network and move on.

Another great aspect of address abundance is that hierarchy I just mentioned. In IPv4 you obtain just the addresses that you need for the next year or so and then go back for more, over and over again as you grow your network. This means fractured subnets, broken up and used where addresses are needed, often in a manner that does not allow aggregation within your network. With IPv6 we can flip this on its head and build our networks with true hierarchy, allowing aggregation at each level. Each region/campus/building/floor/etc. has it’s own identifying prefix, fitting one inside the other like a Matryoshka. This simplifies filters, firewall rules and ACLs. It shrinks our core routing tables and facilitates traffic engineering. It also simplifies operations and troubleshooting.

Another way we can simplify network operations a little by shifting our subnetting paradigm is to use nibbles. A nibble, for those unfamiliar, is half a byte or four bits. Starting at /64, the nibble aligned subnet masks are /60, /56, /52, /48, etc. Subnetting on nibble boundaries means only using nibble aligned subnet masks. Basically if you need more than one /64 you should jump to a /60 and don’t try to use /63, /62, nor /61. Yes, this may cause some “waste” but that’s one of the great things about this new paradigm of address abundance—we don’t care! Using nibble boundaries makes your subnetted prefixes much easier to read. When you see 2001:db8:2000::/36 you know that it comes after 2001:db8:1000::/36 and before 2001:db8:3000::/36. Because one 4-bit hex digit increments linearly when using nibbles, its easy to do the math in your head (plus one, minus one). This is not true if you use a non-nibble-aligned subnet like /37 or /35.

You can combine these practices and take it a step further by building homogenous hierarchies such that each prefix within a given level is the same size. Talk about an address planners wet dream! For example, you may want to give every department within each building a /56, each building a /48, and each campus on your network a /40. Now, these numbers are not arbitrary, they need to be carefully planned out ahead of time to ensure that your largest department, building, campus, etc. has room to grow within its assigned subnet.

Start at the bottom, whatever your most granular network division is, and work up. Our example starts with department, so you take the largest department in your organization and count how many networks will be needed to support the next 5 years of growth. One nibble up from /64 is /60, which gives you a maximum of 16 /64s. If you need more than that, jump to the next nibble; a /56, which gives you up to 256 /64 networks to work with—perfect! Now move up the hierarchy to the building level and again take the largest building in your organization (which may not house that largest department—that’s OK). This time you’re counting departments to see how many /56 subnets are required to sustain the building’s growth. A /48 again provides up to 256 /56 subnets (being two nibbles, or 8 bits, larger), so you pick that because you need more than the 16 that a /52 would yield. Repeat the process again by counting buildings in your largest campus and fitting that number to a nibble-aligned subnet size. Finally, count your campuses, round up to a nibble, and you know the size of prefix your organization needs! Of course this is just one example. Your network may logically be divided in different ways, perhaps your campuses need to be further grouped into regions or buildings are your lowest level. Maybe you start with headend or central office at the bottom level and work up through geographical regions. Obviously you’ll need to fit your IPv6 subnetting plan to your own network—what really matters is understanding the paradigm.

Once you have shifted your paradigm and are ready to go forth and subnet, I highly recommend starting with this Best Current Operational Practice on IPv6 subnetting written by engineers, for engineers. You’ll probably also want to look into IP Address Management (IPAM) software if your network is a large one (or if that last paragraph scared the bejesus out of you) as abundance can certainly bring some complexity along with it’s benefits. Happy subnetting!