The Teredo auto-tunnelling protocol allows IPv6 hosts behind IPv4 NATs to communicate with other IPv6 hosts. It is enabled by default on Windows Vista and Windows 7. But Windows clients are self-constrained: if their only IPv6 access is Teredo, they are unable to resolve host names to IPv6 addresses. We use web-based measurements to investigate the (latent) Teredo capability of Internet clients, and the delay introduced by Teredo. We compare this with native IPv6 and 6to4 tunnelling capability and delay. We find that only 6--7% of connections are from fully IPv6-capable clients, but an additional 15--16% of connections are from clients that would be IPv6-capable if Windows Teredo was not constrained. However, Teredo increases the median latency to fetch objects by 1--1.5 seconds compared to IPv4 or native IPv6, even with an optimally located Teredo relay. Furthermore, in many cases Teredo fails to establish a tunnel.
The IPv6 capability on today’s Internet has been a well established topic over the past years. There have been extensive attentions, discussions, and activities at IETF and NANOG as well as proposals published in research literatures. This paper provided a nice addition to the existing work by studying the IPv6 Teredo tunneling capability and performance of Internet clients. Teredo is a Windows based tunneling of IPv6 over IPv4-only networks and is enabled by default in Windows Vista and Windows 7. The paper focused on examining two aspects of Teredo tunnel performance: success rate (i.e., client capability) and latency. In order to measure the Teredo performance, authors instrumented several Web sites by embedding a small test script which performs the measurement when downloaded by a client Web browser. Authors also used Google’s AdSense platform to distribute their script as an advertisement. There were several interesting observations based on their experiments that covered a time period of several months. First, while only 6–7% of connections were from fully IPv6-capable clients, more than twice as many connections (15–16%) were from Windows clients that could have used IPv6 if Windows Teredo was fully enabled by default. Second, over 80% of Windows Vista and 66% of Windows 7 connections Teredo failed to establish a tunnel. Third, Teredo significantly increases the median delay to fetch objects by 1–1.5 seconds compared to IPv4 or native IPv6. These observations indicated that both client capability and delay are major issues of Teredo. Though some of these observations are not completely surprising (e.g., applications experience more latencies), the paper provided quantitative measurement of the client capability and performance impact of Teredo tunneling which can be useful to researchers who looks for such numbers. I think it could be even more useful and perhaps would make the paper stronger if authors could generalize their study to a wider range of Web sites and even other applications. In addition, it would be interesting to see a more thorough comparison of Teredo with other IPv6 tunneling techniques. I would also like to see efforts that could further improve Teredo in terms of capability and latency. Having said this, I feel that this paper is an interesting piece of measurement work on IPv6 Teredo tunneling.