Home / Blogs

IPv6 Subnetting - The Paradigm Shift

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!

By Chris Grundemann, Creative|Technologist

Filed Under


I will want to play with a Phil Howard  –  Jul 21, 2012 4:05 PM

I will want to play with a few subnets at home.  Comcast is likely to assign a single /64.  What to do.

You have options Chris Grundemann  –  Jul 21, 2012 4:23 PM

Well Phil, no matter what your ISP gives you (even if it's just IPv4), you can play with IPv6 subnets at least two ways: First, you can get a tunnel from Hurricane Electric and/or SixXS (perhaps others) and they will give you a public /48 to use as you will. You can also use ULA in your network to create subnets and route locally, but of course that won't get you Internet access. However, I wouldn't be surprised if you end up getting more than a /64 from Comcast. I don't have any specific knowledge of their plans but most cable operators are looking at /56 for each home at this point.

Actually, I have tunnels to HE and Phil Howard  –  Jul 24, 2012 4:26 PM

Actually, I have tunnels to HE and FDC now.  And I have used ULA.  Once I’m getting dual-stack delivered directly, then I want to set things up for that.

I guess we wait for Comcast to deploy and see what they assign.  I would be astonished if they give out more than /64 by default.  If I were running an ISP, I’d give out /64 by default and /60 by simply asking for it.  I’m afraid a company like Comcast could simply not set up such a system of “ask and ye shall receive” for anything like that.

Don't cripple your customers just because you can! Owen DeLong  –  Jul 25, 2012 1:09 PM

While I think Comcast is likely to short-change their customers and stick them with only a /56, ISPs that want to provide good customer experiences and allow for broader innovation will assign a /48 to each end-site, including residential customers.

Phil, I’m curious as to why you would want to so thoroughly disadvantage your customers if you were running an ISP.

For tunnelbroker users (a free service at HE), we provide a point-to-point /64 for the tunnel and a single routed /64 by default. However, for little more than clicking a checkbox, we provide a /48 (still for free). There is no need and no value whatsoever in playing around with issuing /60s, /56s, /52s, etc. All you accomplish by doing so is perpetuating the attitude of address scarcity and the conservation mentality that has mad a mess of the IPv4 routing table, subjected us to NAT/PAT, and otherwise stifled innovation and development of the internet.

The advantage of IPv6 is that we can move beyond scarcity to a world of abundance. Even if we gave every single BGP speaking ISP on the planet a /24 (16.7 million customer end-sites worth of /48s per ISP), we have enough addresses for about 12 million ISPs. (judging by the number of Autonomous Systems active in BGP at the moment, the worldwide number is currently more on the order of 50,000). The reason we don’t default to a /48 is that in the early days of tunnelbroker, many of our users were using hosts and not routers to terminate the tunnel and could not make proper use of the routed /48. At the time, there were also some limitations in RIR policy where it was difficult to expand address space for one tunnelbroker until we consumed most of our addresses across all the tunnelbrokers. The RIR policy has been improved and we now have an expanded allocation. We actually prefer to hand out /48s wherever possible.

Oh, and Chris… There are more than 18 quintillion addresses in a /64, so you’re off by almost half when you say “about 10 quintillion”. The actual number (if anyone cares, and you shouldn’t) is 18,446,744,073,709,551,616.

Thanks for keeping me honest Owen! 18,446,744,073,709,551,616 Chris Grundemann  –  Jul 31, 2012 3:54 PM

Thanks for keeping me honest Owen! 18,446,744,073,709,551,616 addresses in a /64 subnet it is. =)

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign


Sponsored byDNIB.com

New TLDs

Sponsored byRadix

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC


Sponsored byVerisign