I met Geoff Huston at the ARIN conference in San Antonio the other week. Geoff Huston is an expert from APNIC, who has been researching the IPv4 depletion for a long time. We use a little bit different mathematics and his predictions are usually suggesting a depletion date a few months later than mine. Anyhow, I had an opportunity to discuss the IPv4 depletion with him for about an hour during the conference.
I told him about some issues that I found that he was unaware of with the 188/8 block (see previous post). It is nice to see that he implemented those issues in his latest report. The issue is that RIPE is claiming that 188/8 belongs to them, but the block is still marked as in the various pool at the IANA level. I have now implemented this as a selectable option so you can select if 188/8 belongs to RIPE or IANA. The default setting is that it belongs to RIPE.
Mr. Huston told me about some other issues that he found. First, he told me about some issues with how ARIN reports their IPv4 allocations. I fixed this issue with my tool about two weeks ago (see post from 05.01.2009). Secondly, he told me that the various pool was already divided so that each RIR would get a 1/5 of the pool. I have now implemented this in my tool as well. Now it is selectable if the various pool belongs to IANA or if it is distributed between the 5 RIRs.
One of the first things you should do when migrating to IPv6 is to set up a lab. This is an example on a simple lab to test your clients and how they handle IPv6 and see if any application breaks. The output of such test will be a laundry list with all the faulty client applications that needs to be fixed. The setup is great for testing clients. For example, when I tested my laptop I realized that my AVG antivirus client updater didn’t support IPv6. So I need to be on a IPv4 network to be able to download new definition files.
The basic idea is to create a fake IPv6 environment for the client but still provide access to all services. This can be done by translating all non IPv6 DNS responses to a “fake” internal IPv6 address. A router is running on this fake address. The router is smart enough to be able to translate the source and destination IPv6 addresses back to IPv4 and send them out on the regular Internet.
Sounds hard and expensive? It is not. There is free DNS daemon called totd that can do this for you. The translation between IPv4 and IPv6 can be done by any Cisco Router with support for NAT-PT. This method was first developed as a transition mechanism that could be used instead of dual stack, but has now been obsolete by newer standards. But the method is still an excellent tool for a lab environment to test clients IPv6 capabilities.
This is however not a bullet proof method. Remember that Windows XP doesn’t support IPv6 DNS servers so this setup must be tweaked a little bit if you are testing Windows XP clients. Also, NAT breaks a lot of things in IPv4 and even more things in IPv6. FTP, for example, will likely not work. And don’t try to verify any DNSSEC signatures on the client, they will be broken.
If you haven’t realized the severity of the IPv4 depletion yet and how fast we are burning the last block we have, read this!
Today, NorthStar China in Bejing allocated 2 million IPv4 addresses, bringing the burn rate of IPv4 addresses in the Asia/Pacific region to an insane level! This allocation comes just one day after 4 million addresses were allocated to China Mobile (see post below). 6 million addresses in just two days! China has Year To Date allocated 18,954,240 addresses. And that is just one country. You do the math! (Or just click on the report tab, I have already done the math for you).
Also, remember that the N=1 policy was implemented in the beginning of the year. This policy sets 5 blocks of addresses aside at the IANA level. Those blocks will not be available the conventional way. With this in mind, we actually only have 25 blocks unallocated. We are running out of addresses fast, start migrating to IPv6.
A final note, some people say that “Well your IPv4 address will still work, even after depletion of the IPv4 addresses” – Sure, you will be able to communicate with all other IPv4 hosts out there, but you will not be able to reach any IPv6 hosts, and there will be many of them once IPv4 gets depleted (if everybody could run IPv4 or Dual Stack, we didn’t have to migrate to IPv6 in the first place). It’s like buying a car and not being allowed to drive in ares with a zipcode starting at 6.
Yesterday, China mobile allocated the network 18.104.22.168/10 or about 4 million addresses. This allocation bumped my prediction with 17 days and the expected depletion date is now in October.
You can read on China mobiles website that they have over 240 million customers so it is not unreasonable that they need this many IPv4 addresses. China holds place 1,2,3 and 9 for the largest allocations being made the last 30 days. The Asia/Pacific region are still burning a lot of IPv4 addresses and holds 6 of the top 10 positions.
Top 10 allocations last 30 days
Algeria Telecom allocates about 1 million addresses from AfriNIC. This is the second allocation that AfriNIC has made lately that is larger than a million addresses. AfriNICs burnrate for the last 30 days is unusually high and almost as high as the burn rate in the RIPE NCC region (Europe, Middle East and Central Asia).
Comparing the Burn Rate for AfriNIC and RIPE NCC. The gauges are updated continuously
More information about the burn rate can be found in under the tab
As I wrote in my blog, China TieTong Telecommunications allocated a /11 (2 million addresses) about a month ago. Yesterday the same company allocated another /11. This brings the allocations for China TieTong Telecommunications up to a /10 or 4 million addresses in April.
During the same time, the combined size of ALL allocations made in Latin America and the Caribbean (LACNIC), Africa (AFRINIC) and Europe, Middle East and Central Asia (RIPE NCC) is 3.9 million addresses. So, one company in China allocated more addresses than three of the other regions! (if you are interested, ARIN allocated about 5 million addresses in the same period)
The global burn rate has been low for a while but is now back up to its normal pace. The IANA depletion date was pushed forward to 2010-11-13, one of the earliest dates we have seen in a while. Another interesting thing is that the projected first RIR depletion date now is less than 1000 days away for the first time.
I have also made some minor changes in the calculations for the burn rate in ARIN. It turns out that there is an error in how ARIN is reporting their allocations. I was expecting this to have a significant effect on my predictions, but it turned out to not affect the IANA depletion date and only affect the first and last depletion dates with a few weeks. Thanks Geoff Huston for pointing this out.