The IPv4 Depletion site

Both T-mobile and Orange in the United Kingdom got one /11 or 2 million addresses each by the end of this week. This moved the IANA depletion date even earlier.

UPDATE: A reader told me that Orange UK actually purchased T-mobiles UK operation a while ago.

Written by Stephan Lagerholm (c) 2010 /S

As you can see in my predictions, it is pretty clear that the IANA pool of IPv4 addresses will be depleted in next quarter. The figure below illustrates the endgame in details.

But then what? An interesting exercise is to look at the deficit of IPv4 addresses each region will encounter as time goes by. Assume that half of the deficit will be controlled by using multiple layers of NAT and that the other half of the deficit would be IPv6 only hosts. How big would then the IPv6 only Internet be at different future times?
If you rely on the Internet to do business you cannot ignore the growing population of IPv6 only hosts that aren’t able to communicate with you. You must start to deploy IPv6 even if you have plenty of IPv4 addresses available. Here is a likely scenario:

1 year from now – APNIC will run their IPv4 pool dry. After that, APNIC must rely on IPv6 for any network growth.

2 years from now – RIPE will get depleted. By that time there are already a deficit of around 8 x /8 worth of addresses in APNIC. Around 2% of the internet would be IPv6 only.

2.5 years from now – ARIN will run out of IPv4 addresses. The total deficit from RIPE and APNIC will now be around 16 x /8 with. Around 4% of the Internet will be IPv6 only.

4 to 5 years from now – Over 10% of the Internet will be IPv6 only.

Written by Stephan Lagerholm © 2010

The 45/8 block from Interop is no longer showing up as delegated in the ARIN statistics. This adds 1 block to the ARIN free pool and will push the estimated ARIN allocation to Feb next year.

All three large RIRs (ARIN, APNIC, RIPE) will ask for an additional two blocks each in February next year. This will deplete the IANA pool.

Ladies and Gentlemen, history in the making…

Today AfriNIC got the 105/8 block allocated from IANA. This is surprisingly early, I was expecting AfriNIC to request more space in April of next year. This is moving the IANA depletion date much earlier (February of next year instead of April).

ARIN will soon get two blocks from IANA too. I asked John Curran about it at the recent Gogo6live Ipv6 conference and he vaguely admitted that ARIN will request space soon. It wouldn’t surprise me if that would be this week.

This leaves us with 4 x /8 left. Most likely, two for APNIC and two for RIPE. APNIC has around 4 x /8 in its pool which should be sufficient for them until early February of next week. By that time they will only have around 2 x /8 left and they will refill with another 2 x /8. RIPE currently have 2.88 x /8 in their pool. RIPE is currently allocating in a quite slow pace and the 0.88 x /8 will most likely last until late February of next year. They will then have 2 x /8 in the pool and will be able to justify another allocation of 2 x /8. After that there will be no more IPv4 addresses in the central pool.

It is really time to start implementing IPv6…

ARIN announced a few days ago that the upper half of 50/8 now is delegated to Comcast. That is about 8 million addresses and is the largest delegation we have ever seen from a RIR.

It is unclear if this block will be used for customer equipment or just for internal devices. Comcast has previously announced that they are running out of the RFC1918 space and that they are using real IPv4 addresses for internal network devices.

ARIN announced a few days ago that Interop will return most of their Class-A Legacy IPv4 network. This is of course great news but will not extend the IPv4 lifetime that much. We are currently burning about 1.5 /8 per month so don’t expect more than a few weeks of extended lifetime.

The IANA IPv4 address space registry now shows 36/8 and 42/8 being allocated to APNIC

I have to admit that my webmaster skills suck. Some stuff doesn’t work after I moved this site to an IPv6 enabled host. I will try to resolve it as soon as possible. In the mean time, enjoy the rest.

There have been a lot of discussions lately on the Internet about Carrier Grade NAT. I hope the Internet community implements IPv6 instead of doing NAT444 or any other crazy Carrier Grade NAT scheme that is proposed. There are many reasons why we should avoid those schemes; however port starvation is not one of them. I’m not a fan of CGN but I want to set the record straight as the technology has been bullied for quite a while now.
One of the criticism against Carrier Grade NAT is that it there are only about 65,000 outgoing source ports that can be used. Web applications, in particular those that are using the framework AJAX are allegedly very port hungry. According to the critics of CGN the limited number of ports available could potentially put a limit on how many devices you can have behind each NAT gateway. Numbers around 8000 users per NAT device has been mentioned.
However this is not true. Most modern NAT devices are not using ONLY the source port in the state table.  Instead a combination of Source Port, destination IP and destination Port is used. This way, it is actually possible have more than one device using the same outgoing port. The only minor problem occurs when two packets to the same destination IP and destination port happens to arrive from clients using the same source port. (For example two users happened to go to www.google.com at the same time and both of their browsers happens to use port 1234 as the source port) The NAT device must in this (hopefully pretty rare) case translate the Source Port as well as the IP address. Most application protocols (HTTP for example) do not really care about the source port so they survive this translation. Other applications such as DNS do not really care about the source port either, as long as the outgoing port is randomized.
When you think about it you will realize that this works just fine and that reuse of source port is widespread already. A good example is a web-server. For example, a webserver is not locked up and unable to respond to any additional requests just because somebody is downloading a 2 Gig file from it. The webserver is still able to handle multiple clients and all packets are leaving from port 80.
But again, there are many other good reasons why we shouldn’t use Carrier Grade NAT. Timeouts, end-to-end connectivity, abuse handling are just a few examples.

I recently wrote a guest blog about IPv6 and DNS at Steve Goodbarn’s site. Steve is the CEO of Secure64, the company I work for.

DNS and IPv6: Is your service provider ready?