Yahoo wants two-faced DNS to aid IPv6 deployment

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

As much as one percent of the Internet is now using IPv6

This week, the IETF is holding its 77th meeting in Anaheim, California. Last year around this time, the IETF met in San Francisco, and the Internet Society took advantage of this large gathering of Internet engineers to promote IPv6 and tell us that that it's high time to trade in the dusty 1980s Internet Protocol for the shiny 1995 version. Tuesday, the news was that people are actually starting to heed the advice.

Geoff Huston of APNIC, the registry that gives out IP addresses in the Asia-Pacific region, looked at various numbers that could tell us how much traction IPv6 is gaining. One metric that's easy to observe is the global routing table. After all, if you want people to reach your IP addresses, you'll have to tell them what those addresses are so packets can be routed in the right direction. This is done with the BGP routing protocol.

Currently, there are more than 322,500 IPv4 address ranges announced in BGP, and 2,770 IPv6 address ranges. However, because of the need to conserve IPv4 addresses, ISPs get small IPv4 blocks and frequently have to come back for more. Meanwhile, they can get a single, huge IPv6 block all at once, making this an apples-to-oranges comparison.

The number of BGP-capable networks that are sending out an IPv6 announcement is a more useful measure, and this totals 34,214 for IPv4 and 2,090 for IPv6. So 6.1 percent of all networks have IPv6 enabled in their routers. This metric is expected to reach 80 percent by 2017 if current trends continue.

Transit networks—ISPs that in turn have ISPs or other BGP-capable networks as their customers—have relatively high IPv6 deployment: 22 percent.

Huston also looked at the ratio between the number of distinct IPv4 and IPv6 addresses seen by the Web servers of APNIC and its European counterpart RIPE. This ratio is now slightly over one percent. Caveats apply, however. Multiple IPv4 users may share an address through Network Address Translation while a single IPv6 user may be using different addresses over time due to address privacy mechanisms. Also, the Regional Internet Registries aren't exactly mainstream Web destinations; their visitors are very likely more IPv6-capable than average.

Comcast's Jason Livingood had some information to share about the IPv6 trial the cable giant recently initiated. More than 5,400 people volunteered, with some even changing ISPs to be able to do so. Comcast already has a number of systems running native IPv6: the backbone network, peering points (where traffic is exchanged with other ISPs and content networks), "converged regional area networks (CRANs)," DNS servers (authoritative and resolvers), DHCP servers, and the provisioning system. Next are the Cable Modem Termination Systems (CMTSs), CPEs (Customer Premise Equipment), and home gateways.

Comcast has its own IPv6 monitor, which shows that IPv6 reachability for the top 1 million websites is only about a sixth of a percent. Another IPv6 deployment monitor shows 2.4 percent of the Alexa Worldwide Top 500 Web Sites have IPv6 addresses in the DNS, and several country top 500 lists have percentages ranging from 0.8 (US and UK) to 2 (China).

Yet another metric is provided by the Amsterdam Internet Exchange. Its IPv6 traffic has been hovering around the 0.2 percent mark for the past year. This is traffic exchanged by some 200 large and small ISPs and content networks present in Amsterdam, reaching almost a terabit at peak times, with about 1.5 gigabits of IPv6 traffic. Actually, 0.2 percent is higher than expected: if one percent of all users have IPv6, and one percent of all servers have IPv6, that would make one percent of one percent of all traffic IPv6 traffic.

Some of this maddening inconsistency can be blamed on Google, which has two IPv6-capable destinations in the Web top 10: google.com itself and youtube.com, which gained IPv6 recently. However, most people with IPv6 connectivity will reach these over IPv4, because Google only discloses its IPv6 addresses to DNS servers that have been accepted into the Google over IPv6 program. Jason Livingood explains that Comcast saw a large spike in IPv6-reachable Web destinations "due partly to content owners adding Comcast DNS servers to their authoritative server whitelist."

Don't forget: we've used 3,026 million IPv4 addresses and have just 680 million to go, with 203 million used up in 2009. Time is running out.

Source: Arstechnica.com

Comcast running out of IPv4 addresses, beginning IPv6 trial

Comcast is asking for volunteers to participate in its upcoming IPv6 trials. The cable ISP has been participating in IPv6 circles for a long time and with its huge subscriber base, it is experiencing the IPv4 address scarcity first-hand. So far, it has been able to get addresses for its customers—but not for those customers' cable modems and set-top-boxes. These also need addresses to function or to be managed. No problem, right? Just use private IPv4 addresses, such as the 10 network, which holds 16.8 million addresses. But with 25 million TV, 15 million ISP, and 6 million Comcast Digital Voice subscribers, 16.8 million private addresses isn't enough for a regular management system in which a management station can directly connect to each managed device. So Comcast needs IPv6 just to run its internal network effectively now.

We're also running out of IPv4 addresses, so at some point in the future, Comcast will be unable to obtain additional addresses to connect new customers. So Comcast also needs to provide IPv6 service to its customers at some point and is looking for willing subjects to give it a try.

Comcast plans four trials. The first one will use a transition technique that is still under development, called 6RD. 6RD is similar to the 6to4 automatic tunneling mechanism that is available in Windows (it's enabled automatically when the system has a public IPv4 address under Windows 7 and Vista). The difference is that 6RD only tunnels IPv6 packets across an IPv4-only part of the service provider's network, while 6to4 can tunnel across large parts of the Internet, possibly incurring slowdowns.

The second trial will be with native IPv6. Here, IPv6 packets are transmitted across the infrastructure without encapsulating them in IPv4 packets. IPv4 remains available, creating a "dual stack" deployment. "Native, dual-stack is central to our IPv6 strategy and we expect that the native dual-stack solution will be a significant part of the IPv6 transition, enabling IPv6 technology to evolve globally while still being able to provide seamless services to the traditional IPv4 Internet," says Comcast.

The third trial will basically be the opposite of the first: rather than encapsulate IPv6 packets in IPv4 packets in order to traverse IPv4-only network sections, IPv4 is now encapsulated in IPv6 to get across IPv6-only parts of the service provider network. The technique for this will be "Dual Stack Lite," a protocol that is being developed in the IETF Softwires working group, which is co-chaired by Comcast's Alain Durand. In Dual Stack Lite, the IPv4 hosts use private IPv4 addresses. A home router encapsulates those in IPv6 packets, and a "carrier grade NAT" both decapsulates the packets and performs Network Address Translation so that a lot of DS-Lite clients can share a single IPv4 address.

The fourth trial will evaluate how to provide IPv6 to business class customers. The first two trials are scheduled for the second quarter of 2010, the other two for the third quarter. At this time the details on what participating in each trial will encompass are unclear, and signing up doesn't necessarily guarantee participation.

Source: Arstechnica.com