Here I don't have native IPv6, but rather than constantly tell people this as though I was proud of it, I enabled a tunnel a long time ago.
64 bytes from 2a00:1450:8006::63: icmp_seq=1 ttl=56 time=121 ms
For comparison Google via IPv4 gives results like:
64 bytes from 209.85.229.99: icmp_req=1 ttl=57 time=42.5 ms
Almost the entire 80 millisecond difference is tunnel time, as my packet travels via whichever is the closest organisation to provide IPv6 connectivity to refugees like me - my ISP could decide tomorrow that this wasn't acceptable, deploy their own endpoint as per the RFC and that number would be substantially reduced without me (or any other customer) changing a thing. But that would cost money.
Posted Feb 7, 2011 15:42 UTC (Mon) by rleigh (subscriber, #14622)
[Link]
Just for comparison, this is from a machine with native IPv6:
% ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8006::63) 56 data bytes
64 bytes from 2a00:1450:8006::63: icmp_seq=1 ttl=56 time=14.0 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=2 ttl=56 time=13.7 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=3 ttl=56 time=13.7 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=4 ttl=56 time=13.8 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=5 ttl=56 time=13.6 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=6 ttl=56 time=13.6 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=7 ttl=56 time=13.8 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=8 ttl=56 time=13.6 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=9 ttl=56 time=13.7 ms
^C
--- ipv6.google.com ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8071ms
rtt min/avg/max/mdev = 13.604/13.768/14.053/0.184 ms