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.
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.
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".
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 .