IANA, ARIN, and the IPv4 run-out (Series - Part IV of IV)

Posted by Michael H. Warfield on December 10, 2010 at 11:24 AM EST.

Where Fore Art Thou IPv6

There are several "Doomsday Clocks" on the Internet counting down the IPv4 rundown. One such clock at the Internet service provider and tunnel broker, Hurricane Electric, also knows as TunnelBroker.net, is currently estimating the run-out to occur in another 115 days with only 11 /8s left as of this writing. This puts them firmly in the February 2011 time frame for their prediction. But, of course, we are now well outside the range of any realistic prognostication at this late date in the end game. Five more blocks and we are down to the final 6. The efforts to extend IPv4 have proven somewhat productive but those fruits have grown increasingly bitter by aggravating routing, operational, and security problems. Deployment of the real solution, IPv6, appears to have been largely lethargic. Where is IPv6 now? Why has it been so slow in appearing?

Since the time IPv6 was proposed, developed, and initial deployment began, we've seen digital cell phones appear in the market and the complete mandatory shutdown of the entire analog cellphone infrastructure. Since that time, we've seen high definition television take the stage and all older analog television broadcast in the United States completely dismantled. Why has this not happened with IPv6 and IPv4? Some would argue that it's a demand issue but is it really? Some would argue it's because those were highly regulated industries and the Internet is largely unregulated, but is that all of it? Maybe it's because it's not a demand issue. Maybe it's because it's really a pain issue. Maybe it's because the groups regulating the Internet have done their jobs a little bit too well.

Of the things we may have done too well, these extension techniques are probably the worst in the long run. By stretching out the crisis and by pushing back the day of reckoning on IPv4 we've softened the blow at the end and reduced the pain, taking the pressure off to train and test and deploy. As that's been delayed, the IETF has come under further pressures to come up with more extreme measures, such as CGN, to push the date back even further but that has just given sites more excuse to ignore it and push back their own deployment.

One of the objectives of IPv6 was that there would be no "flag day" as had occurred in the early days of the arpa-net and early Internet. A flag day is a deadline date where they turn everything off to change all the wheels on the car and then turn everything back on and pick up where they left off. This would be massively disruptive on today's Internet and in today's world of e-commerce. Businesses, users, and consumers would be outraged. So IPv6 was designed to avoid this with coexistence and transition firmly in the design plans to avoid this unacceptable pain.

This leaves businesses owning web sites arguing that there is no need for them to incur the expense, that there is no demand for them to adopted IPv6 and arguing that they have no customers on IPv6. Of course, not being on IPv6, they cannot see what customers are on IPv6 or not, since IPv6 and IPv4 can coexist. They certainly can't go IPv6 alone as this would cut off their vast markets of IPv4 only customers.

This leaves ISPs in the middle arguing they have no demand from their customers and there's little or no resources on IPv6 that are not equally available on IPv4. Many on their staff are not trained in IPv6 and will requiring training to come up to speed on it.  Many think that the adoption of IPv6 will be difficult and expensive, requiring extensive hardware upgrades. All are strapped for time and budget and IPv6 support seems like an easy thing to put off and worry about tomorrow.

The customers and end users don't run into things they want to get at now that they can not get at except through IPv6. So they don't notice the problem. The pain, for them, is not there yet, resulting in a chicken or egg situation as far as demand goes. With no resources, you get no demand. With no demand, you get no resources.

Along with a requirement for no "flag day" there was a requirement that IPv6 be largely transparent to the end users. The end users don't see any red flags go up indicating they are on IPv6. They only see a problem if they try and get to IPv6 resources and they are not on IPv6. Even then, they might not see a problem. Transition protocols such as 6to4 and Teredo were designed not only to transport IPv6 over an IPv4 infrastructure, they were also designed to automatically and transparently provide IPv6 access to end consumers who could not get IPv6 support from their providers. Windows XP SP1 and later flavors of Windows desktops and servers have all supported both 6to4 and Teredo with the later versions even having them enabled by default. Versions of Mac OS X, Linux, various BSDs, Solaris, and other flavors of Unix have supported these transition tools for ages. The end users have little incentive to demand something from their providers when they don't know they need it and appear to already have it. Once again, no pain. The ISPs see no demand, and the sites don't know what their customers can or cannot use.

Many years ago, we crossed a threshold in the core gateway routing protocol, BGP or Border Gateway Protocol. It's relatively easy to add up the total number of routable IPv4 addresses that advertised in the core gateways. And, of course, behind each of those IPv4 addresses could be an IPv4 NAT device, so it could be a network but that certainly is not the case for many of these addresses, if not most of these addresses. Of course, too, not all of those addresses are actually in use.  It's impossible to count up the number of IPv4 networks because the routing boundaries and subnetting are so disorganized and the number of NAT devices are so indeterminate.

On the IPv6 side of the house, individual routable addresses are mind numbingly huge just on a single /64 subnet. Counting individual addresses is meaningless. But we can count networks and subnetworks on various boundaries from a single /64 subnet up to the full sized standard /48 network which contains 65,536 subnets. The threshold which was reached several years ago was when the total number of routable advertised /48 networks on IPv6 exceeded the total number of routable advertised IPv4 addresses. We could assign each and every routable IPv4 address its very own /48 IPv6 network and still have room for more. What's even more amazing is in the number of routes. IPv4 requires over 330,000 routes to route those address blocks. According to the monthly CIDR report from APNIC, IPv6 does this with as little as 3,000 routes, an improvement of better than 2 orders of magnitude. So the deployed capacity is there, and it's efficient.

Some time ago, Google conducted some very interesting experiments. First, they deployed and enabled IPv6. They found that it was not difficult and was not expensive. Most modern equipment already supports IPv6. Then they set up a test where a select number of visitors to their sites would be offered both IPv4 and IPv6 addresses in DNS. By standard, IPv6 should be preferred if offered and available. They found a small, but significant, number of clients would preferentially connect to IPv6 if offered and ranked the United States as 5th in the world and some Eastern European countries and Russia in the top 5, which was quite a surprise. The reason for the US standing was attributed to the popularity of Mac laptops with OS X and Airport Express WiFi access points, both of which support IPv6 transition protocols and have them enabled and active by default. With the appearance of Windows 7 in the market, this number is expected to grow significantly. But this is all transparent to the users who don't even realize they can now reach some sites which were previously unavailable to them.

Comcast deployed IPv6 internally and even gave a presentation on that deployment at a NANOG conference years ago. They needed it for all their devices. It was not an option for them. Some time ago, they started a beta deployment of IPv6 delivery to the home for their customers. People quickly signed up for it where it became available and they closed the beta to new participants, they had more than enough takers. So, even with no pain and with transparent operation to the end users, there certainly seems to be the demand when it's made available. The demand is there.

In the end, IPv4 is going to run out and the stopgap measures will continue to plague us for a long time to come. The real solution, IPv6, is really there and ready to go, right now. Finally, the end is near. For some of us, it's about time. It's a shame that some people still act surprised and are still putting off deployment. When it becomes a crisis in their laps, they will be the ones who will complain about the short time frame and no warnings and expensive training an lack of manpower, but it will be there own faults.

This finishes our focus series on IANA, ARIN, and the IPv4 run-out and we include important links below where you can read more on this subject.

http://www.iana.net
http://www.arin.net
http://www.apnic.net
http://www.naong.org
http://www.tunnelbroker.net
http://www.cider-report.org