I want everyone to think of IPv6 in terms of 64 bits. (Yes, I know that IPv6 is really 128 bits for the address, but as you’ll discover that isn’t the point I am trying to make!) Now that we have that out of the way, let’s talk about why it’s better to think of IPv6 in terms of the network address space (i.e., the left-most 64 bits of that 128-bit address) and stop thinking about the host space completely.
IPv4 Subnet
Let’s digress slightly and talk about the challenge we face in IPv4 networks (and why I am even bringing up this idea as something to consider). When designing and thinking about networks for IPv4, we have to first consider the number of network segments we require (need or want) and the end-node sizing of those network segments (i.e., how many hosts would operate potentially in that network segment). Each of us are used to making these sorts of IPv4 design tradeoffs every time a new network segment is required. Most often this is the retrofit of an IPv4 address allocation that has already been made but isn’t “efficient” enough given the limited addresses you are given. Let’s look at a specific example.
Perhaps you have a remote branch site that you were only able to allocate 10.24.7.0/24 to. This allocation was made from your RFC 1918 10.0.0.0/8 address space you use for your company. So, how do we make this remote branch site work for the requirements it has? Do we simply give the router interface 10.24.7.1/24 and set up a DHCP pool with the rest of the addresses (obviously reserving the .1 for the router from the pool)? For a simple remote office this might work. We could have up to 253 hosts operating at that location (plus one router). That optimizes the number of hosts we could potentially support. But such an assignment doesn’t make any accommodations for network segmentation or security boundaries. Perhaps we should create at least 2 subnets to divide up our “servers” from our “clients” at the site. This means setting up two /25 subnets. The Layer 3 switch or router has 10.24.7.1/ configured for the server subnet and 10.24.7.129/25 for the clients. But let’s suppose that there are only 4 servers we need to run at this site (e.g., an Active Directory server, a printer server, a file server and a custom application server). You are using up 128 addresses for 4 hosts and, as it happens, you have more than 128 hosts in the client network. So, what do you do now? In addition, if you decide to do this, you pay an additional penalty of losing two host addresses to the network and subnet reservation for each subnet you build. The waste becomes proportionally more and more of the address space the more you subnet that address space. That doesn’t feel like a win at all.
It is all ugly tradeoffs with no easy answers. For instance, a simple solution might be to allocate some larger subnets to the site. But you might not have available address space due to poor planning (or the fact you might already be using the majority of your address space and have none to assign). And so, and hope the next drive-by exploit doesn’t impact your network too badly.
Simplicity and Abundancy with IPv6 /64s
The limitation we are dealing with in using IPv4 is that for a given network, we must provide addresses for all hosts, but we might have more hosts than what an IPv4 subnet has available.
This problem completely disappears with IPv6! Remember, with IPv6 the standard prefix size for a typical network segment is a /64. This works out to 264 or 18,446,744,073,709,551,616 addresses that can be assigned to hosts. This number is so large it isn’t possible to put it into a relatable context so let’s do some simple math to make it more understandable.
For the sake of argument, let’s assume we have a host with an application that requires 10 million addresses per second (yes, I am making this up, but 10 million is a number we can relate too). Let’s also stipulate that this application never, ever reuses an address. At 1 second we have used 10 million addresses, at 2 seconds 20 million, at 3 seconds 30 million, etc. You get the idea. Just intuitively guessing, how long do you think it might take to use up all 1.8×1019 IPv6 addresses in the /64?
Let’s do the math:
18,446,744,073,709,551,616 IPv6 addresses / (10,000,000 IPv6 addresses/second * 60 sec/min * 60 min/hr. * 24 hr./day * 365 days/yr.) = 58,494 years
This means that for that single /64 prefix, it would take the application running on that host more than 58,000 years to use up the address space. For our purposes, that is equivalent to infinity. The message is clear: You will never run out of IPv6 addresses in a /64 to configure hosts with, ever. Surprisingly, there are people who want to challenge that statement. So, my simple questions to you are these:
Will your data center or cloud provider be around in 58,000 years?
Will your data center be around in 1,000 years?
Will it even make it to 100 years?
Almost everyone concedes that their data center will not last 100 years. Yet somehow, some of the same people are still comfortable challenging the idea that we will never run out of addresses in a /64. But if you concur that your data center will go away more than 49,900 years before you even come close to running out of IPv6 address in a /64, then why? Also, my prediction is that in 100+ years we will likely have moved onto a new networking protocol, likely one not backward compatible with IPv6.
This leaves us with a simple conclusion: Stop worrying about the supply of addresses in a /64!
Doing the math is how I learned to stop worrying about hosts and love a /64 and I hope it helped you to do so too!
It will always meet your host numbering requirements no matter how small or large a network segment you want to operate. As a result, the only thing you need to consider when designing and architecting your network is how many network segments you need to have to accommodate your company’s needs. It likely makes sense for you to project out many years into the future depending on your growth needs and requirements (maybe 25, 50 or 100 years?)
As I stated in the beginning, think of IPv6 in terms of the network address (i.e., the left most 64 bits of that 128-bit address) and stop thinking about the host space completely. That leaves us with the question: What do you need to do around network prefix sizing? You can check out Tom Coffeen’s excellent articles on why a /48 will be the standard (and likely smallest “site”) prefix you will utilize in IPv6 at:
A /48 For Every Site and For Every Site a /48
A /48 For Every Site and For Every Site a /48 Part 2
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now
– Ed
Ed Horley (@ehorley) is CEO of HexaBuild.io, an IPv6 consulting and training company. Ed is Co-chair of the California IPv6 Task Force (CAv6TF) and authored the Apress Press book on Practical IPv6 for Windows Administrators. Follow HexaBuild on Twitter and LinkedIn.
