The questions I am most often asked when I discuss IPv6 with someone for the first time are “what is IPv6” and “why do we need a new version of IP?” Once it is understood that we simply do not have enough IPv4 addresses available for the Internet to continue to grow much beyond its current state, the next question is the one that I explore here: How much IPv6 is there?
The most obvious answer is the one most commonly given; that IPv6 addresses are 128 bits long and since each bit is a binary digit, we get a theoretical total of 2^128 individual IPv6 addresses, which is 3.40282367 × 10^38 or 340,282,366,920,938,463,463,374,607,431,770,000,000!
Now we have this giant number but no real concept of what it means. Some have explained it as 5×10^28 (roughly 50,000,000,000,000,000,000,000,000,000) addresses per human on Earth or as 2^96 (7.92281625 × 10^28) times more unique addresses than are available with IPv4. But this is not a fair comparison because the IPv6 standards are designed in such a way that individual IPv6 addresses are almost meaningless, far less meaningful than individual IPv4 addresses currently are.
Basically, this is due to the fact that almost all IPv4 deployments leverage NAT or at least follow fairly strict efficient utilization requirements and IPv6 deployments do not. Network Address Translation (NAT) allows a single IPv4 address to represent multiple hosts and/or nodes on the Internet at the same time. Efficient utilization policies at the various RIRs require that individual IPv4 addresses assigned to an organization be utilized beyond a set threshold (80% at this time) before more IPv4 addresses will be allocated or assigned to that organization. Combined, this means that almost every single allocated IPv4 address represents (at least) one Internet host. IPv6 on the other hand does not use NAT (this is a very good thing overall but means that the many to one leveraging which is possible with IPv4 addresses is not possible with IPv6 addresses) and is subject to much looser efficient utilization policies in the various regions. All together, this just means that one to one comparisons between the numbers of individual addresses under each protocol are not an apples to apples contrast.
So what is an apples to apples comparison? There may not be one perfect answer to that but there are several possibilities which we can explore. They all include looking at common subnetting practices to find a more accurate basis for such comparisons.
To keep the numbers a tad smaller, let’s start by focusing on the current IPv6 minimum allocation (for the sake of simplicity I will use the ARIN policies as my reference going forward, most of the other registries have quite similar policy in place in most cases) which is a /32 (ipv6/32). There are a total of 4,294,967,296 (2^32) or roughly 4.2 billion ipv6/32s (which is also the number of individual IPv4 addresses). The current IPv4 minimum allocation is a /20 (ipv4/20) of which there are 1,048,576 (2^20). This means that there are only 4,096 times more ipv6/32s than ipv4/20s. I say only, because 4,096 times more is a much, much different number than the 7.9 × 10^28 times more individual IPv6 IPs there are. There are two problems with this approach however, the first is that the IPv4 minimum allocation has changed over time and at this point seems a little bit arbitrary. The second is that the number of addresses within these allocations is so vastly different. So let’s look at the addresses (or more accurately the subnetworks) within the IPv6 minimum allocation.
In a single ipv6/32 there are 65,536 possible ipv6/48s. Since an ipv6/48 is the “normal maximum” assignment we may rationally compare this to an ipv4/24 (I draw this comparison mostly because in the ISP networks I have worked on we typically made our first aggregation at the ipv4/24 line and it appears that the ipv6/48 will similarly be the city or PoP level aggregate of choice). To have 65,536 ipv4/24s at your disposal you would need an ipv4/8 assigned to your organization. There are only 256 unique ipv4/8s possible and (as mentioned above) there are about 4.2 billion ipv6/32s, making the difference a factor of 16,777,216. Quite a bit larger than the 4,096 we get comparing minimum allocations but still a very far cry from 7.9 × 10^28. We face a familiar problem again here though, an ipv6/48 contains roughly a septillion (1.209 x 10^24) individual addresses while an ipv4/24 holds only 256. Before moving on I would like to point out that while an IPv4 allocation that large may sound ridiculous; ipv4/8s were handed out in the early days of IPv4 much more freely than you might assume given today’s problem with scarcity. In fact, 41 out of the 256 total ipv4/8s are designated in full to a non-RIR organization; that adds up to 16% of all IPv4 addresses.
Leaving minimum allocations behind, let’s get down to the smallest subnetworks. An ipv4/30 contains just two usable IP addresses but (because of NAT) can represent an entire customer LAN on an ISP network. The IPv6 prefix which represents a single LAN segment is an ipv6/64. There are a possible total 1,073,741,824 (roughly 1 billion) ipv4/30s and 1.84467441 × 10^19 ipv6/64s. That’s about 17 billion (17,179,869,200 to be more exact) times more IPv6 than IPv4 when measured this way.
Finally there are the RIR utilization definitions. With IPv4, utilization requirements are based on individual IPv4 addresses (ipv4/32s), while IPv6 utilization requirements most commonly refer to /56 networks (ipv6/56). The maximum possible number of ipv4/32s is 4,294,967,296 or roughly 4.2 billion. The maximum possible number of unique ipv6/56s is 7.2057594 × 10^16. Some simple division here tells me that using this method of comparison, the size difference between IPv6 and IPv4 stands at a factor of 16,777,216; the same number we came up with when comparing ipv4/24s to ipv6/48s.
So, while there may be well over an octillion times more individual IPv6 addresses than there are IPv4 addresses; in terms of actually usability, IPv6 is only somewhere in the range of 16 million to 17 billion times larger than IPv4. Much larger, yes; infinite, no.
UPDATE: Check out my related post on IP vs MAC address space if this sort of thing interests you!
Your comparison of /32 to /20 is very misleading. Most medium to large ISPs consume multiple /20s where they would consume only 1 or perhaps 2 /32s. Even the largest providers which might have a /7 or a /6 worth of space under their current control are unlikely to consume more than 8 /32s.
In addition, the ARIN MAU for IPv6 to end users is currently /48, not /32, and, there are 65,536 times 4,096 times (268,435,436 times) as many of those as there are IPv4 /20s and 16,384 times 4,096 (67,108,864 times) as many as there are /22s (the current ARIN MAU for end users).
Your point that 41 IPv4 /8s were given out to individual organizations while accurate really doesn’t have a parallel in IPv6 policies. Today, those same organizations would probably receive a /32 under current IPv4 policies. As you have already pointed out, there are 16.7 million times as many IPv6 /32s as there are IPv4 /8s.
The reality is that there really isn’t an apples to apples comparison, but, when you consider that IPv6 supports roughly 16.7 million times as many organizations (/48s) or 4,294,967,296(/56s) as many households or some combination thereof, I think there are many other planetary scaling problems that will become a much larger issue before we run out of IPv6 numbers with current allocation policies.
Additionally, there is a somewhat built-in safety valve for this in IPv6. Only one /3 has been assigned for allocation at the current time by IANA. The remaining 7 /3s are held in reserve and if we hit the wall on the first /3 sooner than expected, I am confident that addressing policy for IPv6 will be reviewed and modified before we run out of the second /3. Once that is done, we should still have time to transition the first /3s over to new policy and continue with little or no disruption. One example of modified addressing policy would be to abandon EUI-64 and go to end user subnets of /96 instead of /64. This would result in the next /3 containing essentially 4+billion times as many usable subnets as the first /3s.
I agree that the v6/32 to v4/20 comparison is not really useful and tried to point that out, perhaps too briefly. I included it for the sake of being thorough. Your explanation is spot on.
My opinion is that the 16.7 million times greater figure is the most accurate. And while I agree that there are other planetary scaling barriers with lower thresholds I still don’t think that this is an extremely large number considering the number of devices which could benefit from having an IP address. Especially when you consider how early we are in the areas of Internet penetration, intraplanetary exploration (the Oceans) and interplanetary exploration. We have a lot of growing to do and the fairly common belief/statement that IPv6 won’t run out is simply wrong, quite possibly even in our lifetime.
Perhaps you can consider this my early vote for the /96…
But comparing devices is meaningless. The question in IPv4 is “Can we put enough devices on the network?”
In IPv6, the question really is “Do we run out of network numbers?”. With 64 bits for host addressing on every subnet in IPv6, I really don’t think any particular network will be short of ability to support hosts. 50 million cellphones if they all need a /64 each is a lot. Most of them, even in the foreseeable future, will not. In fact, I can see a /64 per cell tower being a much more realistic number. Now, there will be mobile users that require Prefix delegation and likely they will eventually result in a need for larger aggregates per tower or a different way of doing routing. However, even with a /56 per cell tower (providing for 16 customers with 16 /64 subnets each, for example) in addition to the shared /64, I still think we’re OK for far longer than the validity of any crystal ball when it comes to networking.
IPv4 Question: “Can we put enough devices on the network?”
IPv6 Question: “Do we run out of network numbers?”
Better IPv6 Question: “When do we run out of network numbers?”
Answer: It depends on how we use/waste them.
I plan to explore the details of this argument in more detail as soon as I can squeeze in some time to write it. In a nutshell: Our (network operators) attitude towards IPv6 will be a major factor in it’s longevity. The other factors are RIR policy and the IETF standards. All three of these are out of whack currently, imho. If we (NetOps, RIRs, Working Groups) fix them, I believe that you are correct and we can be OK well into the unforeseeable future. If we do not, the foreseeable future may contain the need for yet another IP protocol.
Not that I’m totally impressed, but this is more than I expected when I stumpled upon a link on Digg telling that the info here is quite decent. Thanks.
Remember that only a /3 or about 15% of the IPv6 addresses are allocated this way. If we in the future realize that the current allocation scheme wastes too many addresses we can invent a new for the other 85% of the IPv6 addresses space. Perhaps steal a few bits from the host ID part of the address so that every subnet is a /80 or /96 instead of today’s /64?
I think these huge numbers just aren’t very meaningful. They make peoples’ eyes glaze over. It’s the qualitative things that matter, like whether you have to do handsprings to get your nodes working with IPv4. Or if it All Just Works.
I’ve going through this right now with SIP. Few if any SIP speaking nodes support IPv6, and the combination of SIP and IPv4 and NAT is an utter disaster. I’ve pretty much given up for the time being. I just can’t understand why the VoIP world hasn’t embraced IPv6 and made it their standard and made NAT just a distant, painful memory.
All my regular hosts support IPv6, so I use it regularly with 6to4 as a NAT penetration scheme. No port forwarding crap. And It All Just Works. These days it’s hard to find better praise for a network protocol than that.
IPv6 and 6to4 are among the Internet’s best kept secrets. A lot of people seem to believe that they can’t do anything with IPv6 because their ISP doesn’t support it. 6to4 tunneling almost completely moots ISP IPv6 support. In fact, I almost hope my ISP never implements IPv6. Right now my 6to4 tunnels operate in blissful transparency, with no ISP filtering of any kind to get in my way.
So forget about those huge numbers. They’re meaningless. What matters is that with IPv6 we can get rid of NATs RIGHT NOW and make the Internet work again the way it was originally supposed to work, with bidirectional, transparent, end-to-end and peer-to-peer connectivity. And that’s the reason to use it.
as big as the v6 address space is, your server doesn’t appear to be visible over v6 at the moment ;)
[email protected]:~$ ping weblog.chrisgrundemann.com
PING weblog.chrisgrundemann.com (18.104.22.168) 56(84) bytes of data.
64 bytes from 173-14-10-9-Colorado.hfc.comcastbusiness.net (22.214.171.124): icmp_seq=1 ttl=53 time=149 ms
64 bytes from 173-14-10-9-Colorado.hfc.comcastbusiness.net (126.96.36.199): icmp_seq=2 ttl=53 time=149 ms
64 bytes from 173-14-10-9-Colorado.hfc.comcastbusiness.net (188.8.131.52): icmp_seq=3 ttl=53 time=148 ms
[email protected]:~$ ping6 weblog.chrisgrundemann.com
PING weblog.chrisgrundemann.com(ChrisGrundemann-1-pt.tunnel.tserv8.dal1.ipv6.he.net) 56 data bytes
From gige-gbge0.tserv8.dal1.ipv6.he.net icmp_seq=1 Destination unreachable: Address unreachable
From gige-gbge0.tserv8.dal1.ipv6.he.net icmp_seq=2 Destination unreachable: Address unreachable
From gige-gbge0.tserv8.dal1.ipv6.he.net icmp_seq=3 Destination unreachable: Address unreachable
took me an age and a half to reach your site as a result, almost gave it up for dead til it retried over v4 instead :)
[…] brave new world of IPv6, things have changed. Since the IPv6 addressing space is effectively some 16 million to 17 billion times larger than IPv4; RIRs are handing out IPv6 in much larger blocks, allowing these very same organizations […]