Yesterday, the IANA allocated two /8s to the Asia-Pacifc region (the blocks in question are 1/8 and 27/8). Now, only 24 /8s (9.3%) are available.
Last year, the "n=1" proposal was adopted. This proposal sets aside one /8 for each of the five Regional Internet Registries. If this proposal is taken into account, only 7.4% of the IPv4 free pool is available.
Welcome to 2010.
Python 2.7 alpha 1 was recently released. It contains a few bugfixes that I contributed to IPv6-enable imaplib and nntplib.
m0n0wall, a popular embedded firewall distro, now officially supports IPv6, after a lengthy beta. This is good to see. It's great to see more things support IPv6 out-of-the-box.
Two more IPv4 /8s were allocated this week (to the RIPE NCC).
Only 26 /8s remain in the IANA pool.
Our local area code (814) is running out of phone numbers. When discussing IPv6 with non-technical folks, I frequently use the hypothetical scenario of running out of phone numbers as an analogy for IPv4 address depletion. The conversation usually goes like this:
Imagine if we were running out of phone numbers. One way of solving that problem would be to make them bigger. Instead of ten digits, what if we made them thirty digits? If we did that, how many other things would we have to change? Some mundane things like business cards, letterhead, and phone books. But also more substantial things, like form processing software, backend provisioning software, and legal intercept software. All of that would take years to design, test, and deploy.
(By the way, we're not running out of phone numbers. The NANP projects that the US is fine through at least 2039.)
All analogies break down at a certain point. Technically, the phone number analogy isn't accurate, but it's a reasonable way to explain to my parents what I do at work. Technical details aside, there's (at least) one significant difference between running out of phone numbers and running out of IPv4 addresses: People don't deny that we'll run out of phone numbers.. As I said above, we're in no danger of doing so right now, but the day will come when our population will grow to a point that it will exhaust the telephone numbering plan. That day is far away, but when it comes, we'll have to start adding digits.
On the other hand, some people do deny that we're running out of IPv4 addresses. I don't understand this. The data is unequivocal: We are running out. Fortunately, over the past few years, the data became more clear, and most of the deniers have changed their opinions.
Still, we've never had people advocate for a telephone equivalent of NAT. We've never heard people claim that it's a security threat to have their phone "exposed to the public telephone network." When ten-digit-dialing was introduced years ago, some people complained about the hassle, but speed dial and phone address books solved that problem. When it's noticed at all, ten-digit-dialing is seen as a technological impact of population growth, whereas IPv6 is often seen as some sort of personal assault on the sysadmin asked to deploy it.
I am very concerned that the Internet community has waited too long to begin serious efforts for IPv6 deployment. Only 10% of the IPv4 address pool is left. It will probably be gone 2.5 years. Yet only 5% of the Internet supports IPv6 (as measured by BGP announcements). I just don't see a way to get from 5% to 100% before we run out of IPv4. The next few years will be interesting, to say the least.
Two more IPv4 address blocks have been allocated. Both went to the Asia-Pacific region, as did the two blocks that were allocated in April.
Only 10.9% of the IPv4 address space remains unallocated:
If you exclude the blocks reserved by the "n=1" proposal, only 8.9% of the IPv4 pool is left.
Folks, it's way past time for IPv6 trials. It's time to get serious. How much more grim do the data have to get before we start taking action?
(now that the headline has your attention...)
Not exactly. iPhone OS 3.0 still doesn't support IPv6, but the good folks at Hurricane Electric have added IPv6 information to their IPv4 countdown widget:

It's useful to have the latest info in my pocket.
A month ago, I noted some improvements in IPv6 management networks. I have some more positive news for ET's management network.
Our group is moving to a new office location this fall. We'll be out of the Computer Building, across campus from the machine room. So we wanted a small server to keep in the new office, so we ordered a Dell PowerEdge T610, a small tower. It turns out Dell's iDRAC6 remote management card supports IPv6:
If I'd been more up-to-date on DISA's IPv6 compliance list, I wouldn't have been surprised by this.
Sadly, the IPv6 stack is disabled by default. But at least it's there.
Two weeks ago, I noted that Netflix was accessible over IPv6. At the time, it was only their website, not their streaming service. Today, at NANOG 46, Netflix announced that their streaming service now supports IPv6.
Here's a screenshot of my Vista box running IPv6-only and streaming Serenity. Notice that there's no IPv4 address on the box.
There were several interesting bits in Netflix's slidedeck. Their Content Delivery Network, Limelight, announced IPv6 support today. This is huge, as they're the first CDN to announce production IPv6 support. Lack of IPv6 support in CDNs has been cited again and again as a primary factor in not deploying IPv6 on large content sites.
To my mind, there were two big points in Netflix's presentation:
- IPv6 is easy. On Netflix's end, the entire deployment, from idea to production service, took two months. Limelight only tasked two engineers to work on IPv6 support.
- "Load Balancers are easy." Alleged lack of IPv6 support in loadbalancers is a common canard that's totted out again and again when folks talk about production IPv6 deployments. I was so glad to see a large Internet content provider dispel this myth. Netflix even posted sample config for IPv6 on a Citrix Netscalar in their slidedeck.
Hats off to Netflix and Limelight for this.
Cell phone carriers have seen a huge growth in wireless data usage. The iPhone is selling like hotcakes, and its users generate large amounts of traffic. Not surprisingly, as cellular providers deploy faster network technologies, users generate even more data. Here's data from Verizon:
Customers' demand for more, faster connectivity is pressuring cell carriers to accelerate their timelines for deploying next generation cellular technologies (the so-called "4G" technologies). One of the most promising of these technologies is LTE, Long Term Evolution. LTE will provide much more bandwidth than current 3G cellular system.
Aside from speed, LTE makes a significant change to cellular networks: Voice is now an IP service. With LTE, your handset is a voice over IP (VoIP) device. This eliminates the distinction between the "phone part" of your smartphone (voice calls, SMS, voicemail), and the "Internet part" (email, web, games, etc). In other words, your phone will need an IP address all the time, even just to receive voice calls.
Independently, the number of cellular subscribers is increasing rapdily. According to the United Nations, more than 40% of the world population has a cell phone:
One research company predicts there will be 5.2 billion cellular subscribers, worldwide, by 2011. Another firm estimates 2 billion new cellular subscribers by 2013. If even a small fraction of these are using 4G, e.g. IP-based, communication, it will place substantial strain on IPv4 address reserves.
The problem, of course, is that we're running out of IPv4 addresses. The IANA pool will most likely be depleted by the end of 2010. This has led many people to wonder if LTE deployments will require IPv6. Now we have an answer: Yes.
Verizon has posted specs for any LTE device that will be permitted on its LTE network. IPv6 support is mandated. IPv4 is optional. That's quite a statement, since IPv4 traffic currently dominates the Internet.
A few relevant quotes from Verizon's spec:
"The device shall support IPv6. The device may support IPv4. IPv6 and IPv4 support shall be per the 3GPP Release 8 Specifications (March 2009)". (section 3.2.4.1)
and
"The device shall be assigned an IPv6 address whenever it attaches to the LTE network." (section 3.2.4.2)
IPv4 support appears optional: "If the device supports IPv4, then the device shall be able to support simultaneous IPv6 and IPv4 sessions." (section 3.2.4.4)
Verizon appears to be trying to conserve IPv4 addresses by disallowing long-term address leases: "If the device supports IPv4, the device shall request an IPv4 address if an application using the LTE bearer requests a data connection using an IPv4 address. Once the application is closed, the IPv4 address shall be released by the device". (section 3.2.4.3)
I'm curious how this will affect handset manufacturers. Windows Mobile and Symbian (used in Nokia phones) already support IPv6. Google is working on IPv6 support in Android. The iPhone and Blackberry don't currently support IPv6. I'm curious if version 3.0 of the iPhone OS will add IPv6 support.




