This graph shows IPv6 performance as measured to www.ripe.net. These measurements show performance of native IPv6 on average being very close to IPv4.
The data for this graph shows the difference between fetching an HTTP object over IPv4 and IPv6 to the same server by web-clients visiting www.ripe.net . I measured the time between receiving a DNS request and the corresponding HTTP request for both IPv4 and IPv6. The various types of IPv6 connectivity of web-clients show different performance characteristics. On average unicast IPv6 (native, green) is only 35 ms slower than IPv4, whereas brokered IPv6 (cyan) is 121 ms slower [1]. The autotunnel technologies perform a bit worse with 6to4 (blue) having an average extra delay of 259 ms and Teredo IPv6 (purple) takes on average 744 ms more than an IPv4 request from the same web-client [2].
This performance data and other information for a couple of sites that we monitor is available at http://albatross.ripe.net/v6-clientresolver/ (updated daily).
So in the near-future, when IPv6 content starts to become more commonplace, it's way better to have native IPv6 access to IPv6-only content. If you depend on 6to4 or Teredo for End Users to access IPv6-only content, expect noticeable difference in network performance.
This is joint work with Geoff Huston and George Michaelson of APNIC R&D, also see their presentation at APNIC30.
Footnotes:
[1] Brokered IPv6 is IPv6-tunneling through a tunnel-broker. We distinguish this from unicast/native IPv6 by labeling connections coming from IPv6 prefixes of well-known IPv6 tunnel-brokers as brokered . The large spike at the end of the graph is likely due to a problem at one of the IPv6 prefixes of one of the tunnel-brokers.
[2] We don't have Teredo or 6to4 relays in our network close to the measurement point. With local relays the extra delay for autotunneled IPv6 will probably be a bit less.
Comments 2
The comments section is closed for articles published more than a year ago. If you'd like to inform us of any issues, please contact us.
Anonymous •
I noticed the big spike in the brokered delay one day. It occurs to me that this may be one broker that is experiencing a lot of delay, and making the overall results look bad.<br /><br />My point is that IPv6 problems may be related to the small amount of traffic, and that specific bad cases may change the overall picture.<br /><br />There are lots of ways to try to figure this out. Maybe converting IPv6 origin address to AS number and then plotting the chart might be interesting. Or maybe just removing duplicate addresses (although this is always tricky with IPv6 of course, since the meaningful part of an address might be /128, /64, /48, /19, or... well, anything!
Anonymous •
It was indeed a single location of a single broker, ie. a single /40 in this case, that made that result for that day look bad, which proves your point.