Troubleshooting is Faster with Real Visibility - OptiView XG v9 - (by Chris Greer)
Open Source Hardware Continues (by Dwayne Jones)

IPv6 Adoption Challenges (by Jim MacLeod)


So far there have been two World IPv6 Days, and two of the five Regional Internet Registries (NICs) have reached IPv4 exhaustion, so everyone has deployed IPv6. Wait, they haven’t? Here’s why.

IPv6 isn’t Compatible

IPv4 is the primary protocol of the Internet. The Internet changed the way we interact with data, with the world around us, and with each other. It is a primary utility as real as water and power.

The primary problem with IPv6 is that it is not directly compatible with IPv4. Transition mechanisms are required to enable IPv6-IPv4 communication, adding an additional level of complication over the protocol transition It is a similar problem to adopting hydrogen-powered cars: people won’t buy them until there are refueling stations, and the stations won’t get built until enough people buy them. However, the problem is more complicated with IPv6: imagine if hydrogen-powered cars couldn’t use the same roads as gas-powered cars. “Transition mechanisms” would consist of car-hauling trucks or changing cars partway through the trip. Even if such mechanisms were automated, there would still be hesitation about adoption.

IPv4 Exhaustion

Demand for IPv6 should be driven by a shortage of IPv4 addresses, but the “exhaustion” of IPv4 addresses has yet to affect most people for a few reasons. First, “exhaustion” is not full depletion: it means that APNIC and RIPE have both reached a point where they’re only giving out a maximum of about 1000 IPv4 addresses to any organization, and they still have almost 2 million IP addresses each (as of October 8 2012). Compare that to ARIN, which has almost 10 million addresses available.

Furthermore, these are “new” IP addresses. It’s comparable to studies that cite new home construction as an indicator of economic health. Organizations are not losing their Internet connectivity due to the IPv4 shortage. The limitation is on the expansion of number of hosts that weren’t previously online. In preparation for the IPv4 shortage, many organizations like ISPs “stockpiled” IP addresses, requesting more than they thought they’d need, so it’s still not that difficult for most users to find IPv4 addresses. In the APNIC region, there is also a 2nd tier of national registries that may still have available addresses.

Additionally, widespread use of client NAT has greatly reduced the need for routable or public IPv4 addresses. NAT allows consumers of information or clients to share IP addresses when connecting to servers, by using the Layer 4 address like the TCP port as a unique flow indicator. While there are limits to the scalability of each routable address, the technique is being industrialized through a technique called Carrier-Grade NAT, in which each end node’s address undergoes at least 2 layers of NAT for further address demand reduction.

NAT can also be applied in a more limited fashion for servers through the use of load balancers, which require only a single routable IP address for multiple internal IP addresses. More advanced server-side NAT can be accomplished by using Layer 7 information, like the host field in an HTTP request. While NAT has certain disadvantages, like complexity of configuration and management, it has kept the Internet working on IPv4 for the last several years.

Who Needs IPv6?

The question is, if there are still plenty of IPv4 addresses available, even in places where common knowledge holds that there are none left, does anyone actually need to use IPv6? The answer is still yes. Large-scale deployments that require more than 1000 addresses, even with NAT, are no longer possible with IPv4 in the APNIC and RIPE regions. ARIN has also implemented more stringent requirements for /16 and larger allocations (65,000+ addresses) for phase 2 of their IPv4 countdown.

Examples of these types of deployments come from recent IPv6 adopters: cable operators are using IPv6 to manage the set-top boxes. Smart grid deployments are also using IPv6.

Will Any Users Need IPv6?

The prediction still stands that India and China will see large-scale growth in Internet usage in the next 2-3 years, and their current IPv4 allocations simply aren’t large enough to support increased Internet-accessible services. The question is whether providers there will start rolling out IPv6 with NAT64 or similar combinations of gateways and DNS to provide transparent Internet access to the IPv4 Internet. Granted, many popular applications, like Skype, still don’t support IPv6, and are unlikely to work in that environment until demand warrants it.

What’s the Current Status of IPv6?

There’s a lot of uncertainty about adding IPv6 that won’t get resolved until it is more widely deployed, but it won’t get more widely deployed until the uncertainty is resolved. There was even an article in August 2012 cautioning against internal deployment of IPv6 due to security concerns.

However, it is important not to confuse end-user adoption with network adoption. There has been tremendous growth in IPv6 deployment when measured by advertised AS networks – potential sources and especially destinations for IPv6 traffic. RIPE measured a global increase of 5 percentage points in every region between 2009 and the first World IPv6 Day in June 2011. The perceived lack of end users in APNIC is in stark contrast to their lead in IPv6-advertised networks, at almost 20% of total networks. Even websites aren’t lagging: an ongoing study by Hurricane Electric shows over 45,000 of the Alexa top 1,000,000 websites are available via IPv6.

When Will IPv6 Get Here?

Market demand for IPv6 at this point shouldn’t be measured by user demand, since it’s likely that the only users that want IPv6 are the types that would read this blog post. However, I remain hopeful that we will soon reach a tipping point, driven by demand for other services that require IPv6.

Jimm Wp_logo Author Profile - Jim MacLeod is a Product Manager at WildPackets. He has been in the networking industry since 1994, and started doing protocol analysis in 1996. His experience includes positions in firewall and VPN setup and policy analysis, log management, Internet filtering, anti-spam, intrusion detection, network monitoring and control, and of course packet sniffing.