We know we are running out of IPv4 addresses, the prediction calculator (see my May posting) says July 19, 2011 as of this writing. It may have changed by the time you read this. We know we need to move to IPv6, but how will this happen?
When the IPv4 addresses run out, the next service provider that needs a block of addresses will have to use IPv6. One of the key sources of demand for new addresses is new Internet users. These new users will then be assigned IPv6 addresses instead of IPv4. If the service provider has IPv6 routing running, IPv6 addresses can be assigned and routed and off we go. Our PCs already know how to use an IPv6 address, and most of our home or CPE access routers do as well. Connections to IPv6 sites and IPv6 users will be via IPv6. Connections to IPv4 users and IPv4 sites will require translation through a protocol gateway. The service providers will have to deploy a lot of these in their networks before next year.
But most of our connections are to content providers. Will they support IPv6 native connections?
UPenn and Comcast are collaborating on a tool that is measuring both the adoption of IPv6 by the top content providers, and the performance of IPv6 connections, and it looks like we have a long way to go.
The software behind both tools (linked above) is the same, but they have different data sets as they are running in two different locations and have different network connectivity. The UPenn tool has been running longer, but the Comcast tool tests more often.
The tool gets the top 2+ Million Internet web sites as listed by Alexa. It then does a DNS lookup on each site, and finds those that return both an IPv4 address and an IPv6 address for the same DNS name.
Adoption
The first 3 figures on each site show information about adoption, meaning how many of the top 1M web sites are providing an IPv6 connection. Currently the percentage is about 0.15% (15 hundredths of 1%) or about 3,500 sites. This is a bit worrisome; it means that the vast majority of the Internet's content is not yet reachable via native IPv6. Figure 3 breaks it down for the top 10, top 100, etc. Even among the biggest sites the percentages are relatively low. Google is the only site among the top ten to have an IPv6 host.
Note that the tool is accommodating sites that have an IPv6 host even if that host does not have the same exact name. For instance, Google (the #1 rated site) is available via IPv6 but its name is ipv6.google.com, not just google.com. Other sites that have the same or a similar convention are considered IPv6 enabled even though the site names are not identical.
Performance
After finding the 3,500 sites that are accessible via both IPv4 and IPv6 addresses, the test tool downloads the base page from each site using both protocols. The performance of these two downloads is then compared to see if there is a performance difference between IPv4 and IPv6.
A performance difference between IPv4 and IPv6 is clearly visible. Variations occur, but IPv6 is notably slower than IPv4 (see Figure 4 on both the UPenn and Comcast sites). Dots appearing above the diagonal line represent sites where IPv6 performance is slower than IPv4 performance, and the predominance of dots are above the line.
Figure 5.1 is another look at performance, showing bytes/millisecond normalized to the size of the file loaded. Again we see a significant difference between IPv4 and IPv6 performance, especially in the top 1K content sites.
Why performance differences? A report from Cisco shows that their router performance is unlikely to be the issue; performance is nearly identical for running IPv4 and IPv6. A few issues may be in play:
1) Carriers may not be providing IPv6 connectivity end-to-end. If a network path flows through a carrier that is not supporting IPv6, then IPv6 is tunneled through IPv4. The tunnel encapsulation and de-encapsulation is probably being done in a router slow-path or in a separate piece of equipment, again through software. This may provide a performance degradation
2) Content Distribution Networks (CDNs) may be delivering IPv4 content from a much closer location, while IPv6 content has to go back to the source location. Content providers may not be funding IPv6-based CDN distribution yet since there is a relatively low demand for IPv6 today (or they have not figured this out yet!)
3) Just general network path tuning is not optimized for IPv6. Carriers have been tuning up their IPv4 connectivity for 20 years to get us the performance we see today on the Internet. The same efforts will have to be put in place for IPv6, and will happen over time as the traffic starts to move to the new protocol.
If we had another 20 years to phase in IPv6 all would be well and good. But The forced transition to IPv6 will make these issues much more apparent as we approach a rapid transition from our well known IPv4 world into the new networked world of IPv6.
