To check the connectivity of an IPv6 device with RIPE Atlas, one typically asks N probes to ping the target and deduces the reachability of the target from the percentage of failures. But RIPE Atlas probes, like many IPv6 devices, often believe they are IPv6-connected while they are not.
Problem Statement
When you want to check the IPv6 connectivity of a device with RIPE Atlas, you typically request RIPE Atlas to send pings to your target from a given number of probes. The percentage of probes reporting a failure gives you a good idea of the reachability of your device. But IPv6 is not IPv4: it is quite common in the IPv6 world to have devices that believe they are connected to the IPv6 Internet while they are not. For instance, this problem can occur if a router on the local network advertises a global IPv6 prefix with Router Announcement (RA) packets while, in fact, the local network has no connection to the outside world.
Methodology
The methodology we used is as follows: we chose a few well-connected targets, devices that most certainly have a stable and working IPv6 connectivity (www.afnic.fr, www.ietf.org, www.icann.org, www.freebsd.org and www.wikipedia.org). We then requested one-off measurements for these targets, using the address family 6. The set of probes for the first target is choosen at random by the RIPE Atlas system, but only among those probes that claim IPv6 connectivity (typically because they received an RA announcement with a global IPv6 prefix). All the other targets then reused the same set of probes (thanks to the option "type": "msm" in the measurement creation API). We then counted only the probes that cannot get even one reply from any of the targets. These probes are regarded as "without a real IPv6 connectivity".
Results
With 1,000 probes worldwide, we see that 10% are "without a real IPv6 connectivity". Per target, we observed a percentage between 10 and 11. (See public measurements #1010569 to #1010579.) The practical consequence of this is that when you use RIPE Atlas to measure the connectivity of an IPv6 device, 90% success is the maximal reachability you'll get.
The results do not depend on the area (continent). For instance, in area West (North America in RIPE Atlas terminology) and in area North-Central (Europe), we observed the same (taking into account the confidence interval) ratio of 10%.
The problem is very specific to IPv6. When doing the tests with IPv4 on the same targets, only 0.4% of the 1,000 probes fail to ping any of the targets. (See public measurements #1010583 to #1010588.)
We also wanted to make a distinction between those probes that time-out and those that get an explicit error (typically "sendto failed: Network is unreachable", probably an explicit ICMP error received). We observed that around 2/3 of of the probes timed out which is unfortunately pretty annoying for actual users.
We might want to retry this study with longer measurements (instead of one-off measurements) to be sure we were not a victim of a general problem of the IPv6 Internet at the time of the measurement. But since these tests were repeated several times at different days, I believe they truly represent a permanent state of the network.
Conclusions & Solutions
A possible solution to this issue could be for the RIPE Atlas developers to do these tests periodically and to warn the owners of the probes. Or maybe to stop using these probes for IPv6 tests. The RIPE Atlas team confirmed that it is currently thinking about improving the probe selection process in this regard. For instance, RIPE Atlas could look at how successful the probes were in general doing IPv6 measurements, and exclude the ones that consistently fail. And perhaps later a knob could be added so that users can specify if they want this or not.
The source code to start the measurements that we used in this survey (and to analyse their results) is in the contrib repository under the name "survey-connectivity-v6.py").
As we see, the IPv6 Internet is still not on par with the IPv4 Internet. Please note that RIPE Atlas probes are typically installed by engineers on better-than-average local networks. The problem is probably worse for general devices, hence the "happy eyeballs" problem described in RFC 6556 .
Comments 12
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
ludovic •
why not send ipv6 measurement requests only ivre ipv6?
Hide replies
Stéphane Bortzmeyer •
I'm not sure of the internals of the Atlas system but, as far as I know, the probe establishes a secure channel (remember many probes cannot receive unsollicited connections from the outside, because NAT or firewall) with its master (either with IPv4 or IPv6) and then uses this channel for everything (reports, measurement requests, responses).
Hide replies
Robert Kisteleki •
The command channel can be on either v4 or v6. Regardless of this, if the probe indicates that it can do "the other" protocol too, we'll involve it in those measurements.
Val •
Hello, I checked all "pingable" addresses from route6 object from RIPE database, and 10 (from 48) don't answer on pings.
Sebastian Castro •
Thanks Stephane for this. My own experience shows similar perception of probes not being able to reach v6 destinations. We recently used ATLAS for testing reachability of a new DNS server and roughly 8% of the probes used couldn't reach it. In the process of finding out why, we ran a one-off traceroute measurement, and probes failed on the second hop.
Stéphane Bortzmeyer •
Note there is also a interesting discussion about this article on the mailing list of the RIPE IPv6 Working Group http://www.ripe.net/ripe/mail/archives/ipv6-wg/2013-June/002153.html
Phillip Remaker •
Is there any way to get the source IPv6 address of the failing probes? Or at least the prefix? I am especially interested to know if the failing devices posses 6to4 or Teredo addresses, or are otherwise behind a router serviced by a poorly maintained or unpredictable IPv6 tunnel. I would suggest that any probes reporting 6to4 or Teredo addresses be prohibited from participating in IPv6 test measurements. It would be useful to conduct further research on the failing probes and adjust the probe firmware accordingly.
Dan Wing •
I have a suspicion that many of these failures are IPv6 tunnels that have suffered bit rot. Could you analyze the IPv6 address that the Atlas probe thinks it has and split them into two categories: (a) known tunnels (e.g., Hurricane Electric, SixXS, 6to4, Teredo) versus (b) presumably "native" IPv6 addresses.
Hide replies
Stéphane Bortzmeyer •
I don't have time right now for analyzing the addresses (these are public measurements so someone else may do it). But I don't think it would be a good idea to exclude probes based on the type of address. Global and "normal" IPv6 addresse may have connectivity problems, too. Exclusion from measurements should be based on actual tests (probing the Anchors), not on guesses.
Stéphane Bortzmeyer •
I tried to answer your question but was not able to do so because, unfortunately, the JSON results do not contain the source IPv6 address of the probe when the ping failed. So, i cannot check it.
Behrooz Behzadfar •
contain the source IPv6 address of the probe when the ping failed.
Hide replies
Stéphane Bortzmeyer •
Isn't there something missing at the beginning of your message? What "contains the source IPv6 address"?