Native IPv6 @ Home
During the holidays I did some ad-hoc tests on my home broadband connection from xs4all here in NL. As many of you know they ran a big native IPv6 pilot and now IPv6 is available as a production service. I left the FritzBox router running while the family was absent for almost 4 weeks. Connected to the router was a prototype of our small active probe. You can read about it here and see a photo of the set-up too.
Let me relate some of these "holiday" observations. As other holiday acitivities these are somewhat lighthearted and I do not claim that these are science or in any way representative. They are just some tests I ran while no-one was home.
The router was connected by adsl2 to the xs4all service. The probe was connected directly to the router and powered from the router's USB port. Every two minutes the probe did 10 ICMP(6) RTT (round trip time) measurements, vulgo: pings, to k.root-servers.net. It then recorded the results in flash memory. To give you an idea about the topology here are traceroutes showing the paths as they appear today:
traceroute to k.root-servers.net (220.127.116.11), 64 hops max, 52 byte packets
1 10.0.0.8 1.152 ms 0.857 ms 0.881 ms 2 18.104.22.168 9.540 ms 9.426 ms 9.273 ms 3 22.214.171.124 9.250 ms 9.125 ms 9.103 ms 4 126.96.36.199 9.685 ms 10.508 ms 9.290 ms 5 188.8.131.52 9.374 ms 9.318 ms 17.549 ms 6 184.108.40.206 9.746 ms 9.570 ms 220.127.116.11 9.985 ms 7 18.104.22.168 9.815 ms 10.219 ms 9.282 ms
traceroute6 to k.root-servers.net (2001:7fd::1) from 2001:980:3500:1:3615:9eff:fe0f:510c, 64 hops max, 12 byte packets 1 2001:980:3500:1:224:feff:fe19:b61c 0.766 ms 1.113 ms 0.918 ms 2 2001:888:0:4601::1 10.804 ms 9.770 ms 9.517 ms 3 2001:888:0:4603::2 10.337 ms 10.239 ms 8.934 ms 4 2001:888:2:2::1 15.707 ms 15.457 ms 10.422 ms 5 2001:7f8:1::a502:5152:1 10.498 ms 10.023 ms 9.863 ms 6 2001:7fd::1 10.293 ms 10.158 ms 9.991 ms
Here are simple plots of the observed mean RTTs. These are means of 10 consecutive measurements taken every 2 minutes.
No surprises in the IPv4 RTTs. They are very predictable with just a few outliers.
Besides being about 2ms larger the IPv6 RTTs show a little more spread and similar outliers.
I do not dare to speculate what causes the differences as there are so many components involved in the measurement. This may or may not be caused by the network. It also may very well be caused by different handling of IPv6 datagrams in the end-systems. Just as an example: I observe an average difference in RTTs of about 1.15ms between IPv4 and IPv6 when pinging the router from the prototype probe and only 0.12ms when doing the same from my macbook with OSX 10.6.
Never mind the structural small differences in RTT. It certainly appears that for practical purposes the IPv6 service is as good as the IPv4 service. We have come a long way from 6bone and such.
Packet Loss & Outages
I observed very little packet loss: outside of complete outages only 181 of 444560 packets were lost, that is 0.04%. The losses that did occur are in all combinations: only v4, only v6 and both at the same time. In general I cannot see a significant difference between IPv6 and IPv4 concerning packet loss.
There were only two outages. To my great surprise I found an outage of more than 100 minutes starting at 23:45 UTC on 3 August and that outage was on IPv4 while IPv6 kept working! Checking dnsmon for the time period does not reveal any server problem. So it looks like a genuine IPv4 network problem while IPv6 was just fine. A whole new level of redundancy!
I also found the opposite: a two hour outage of IPv6 while IPv4 kept running. It started at 20:13 UTC on 23 August. Marco Hogewoning tells me this was because they forgot to provision my connection in the production service when the pilot configuration was phased out. No complaints from this pilot user.
It is not really fair to generalise from such an ad-hoc experiment. Certainly the small probe prototype has proven its usefulness and capability to take long baseline measurements. And I was not worried about the electricity bill at all. I am also very happy to see that some broadband consumers can obtain a reliable IPv6 service where I live and that sometimes this service appears to work even when IPv4 does not.