Many systems that purport to have connectivity to the IPv6 Internet, well, don't. According to measurements done by Google 18 months ago, about a third of a percent of all Web users' systems think they have IPv6, with huge regional differences. In reality, it doesn't work for 27 percent of those users. Last week at the IETF meeting in Anaheim, engineers from Yahoo proposed to solve this problem by only exposing a server's IPv6 addresses if a DNS query comes in over IPv6.Today, the 0.09 percent of Web users with broken IPv6 suffer significant timeouts if they, for instance, aim their Web browser at an IPv6-enabled site. The browser will first try to connect over IPv6 for upwards of a minute before giving up and retrying over IPv4. This is a big problem for important Web destinations such as Google and Yahoo, because they don't want to lose 0.09 percent (or more, as IPv6 use increases) of their visitors and therefore, revenue.
Google has "solved" this problem with its Google over IPv6 program which requires DNS server operators to get whitelisted. Users of whitelisted DNS servers subsequently receive google.com's and youtube.com's IPv6 addresses as well as the usual IPv4 addresses when they perform a DNS query for the addresses that go with those DNS names. Everyone else gets only the IPv4 addresses. Apparently, Google, Netflix, and Microsoft have been exploring the possibilities of a shared, industry-wide IPv6 whitelist.
However, Yahoo is taking a different approach. If a user is performing DNS queries over IPv6, then obviously his or her IPv6 connectivity works. So exposing IPv6 addresses to users sending DNS queries over IPv6 should be fairly risk-free. Everyone agrees that this solution, like the whitelist solution, is rather ugly. This means implementing "two-faced DNS": a DNS server that gives different answers to different people performing the same query. Obviously, such practice isn't particularly DNSSEC-friendly. (But that can be solved by also giving DNSSEC enabled users the IPv6 information.)
There are two problems with Yahoo's approach. First of all, mechanisms for computers to learn the IPv6 addresses of nameservers are lacking. Unlike IPv4, IPv6 often doesn't use DHCP (many systems, such as Windows XP and Mac OS X don't even support IPv6 DHCP). One alternative mechanism to learn IPv6 DNS server addresses, RFC 5006, is even less widely deployed. So most systems that have both IPv4 and IPv6 connectivity perform their DNS requests over IPv4.
The other issue is that there is at least one other server between a Yahoo user's computer and Yahoo's DNS servers. If that server is operated by people who are oblivious to IPv6, it's unlikely that they will configure it such that it only gives out Yahoo's IPv6 addresses to users who send queries over IPv6. So the whole thing hinges on the cooperation of those network operators who are breaking IPv6 connectivity in the first place.
If this is the only way that content networks such as Yahoo and Google are prepared to become IPv6-capable, it's still better than nothing. And perhaps this downside will be addressed when the Yahoo engineers work out the details of this proposal, which is so far just a set of presentation slides.
In the meantime, it would be nice if network operators wouldn't arbitrarily block IPv6 packets inside IPv4 packets, thereby disabling "IPv6 tunnels," and for people who enable IPv6 to make sure it keeps working after the initial excitement of running the new protocol wears off.
Source: Arstechnica.com
