It's currently tricky to distinguish inside of tcp_connect measurements if an IPv6 target is unreachable due to it being blocked vs it being unreachable because the probe has no IPv6 connectivity.
I think we should add an initial check to the startup of a probe, when we do geoip lookup and resolver identification, that checks if there is IPv6 connectivity and if not present maybe even disable some measurements (it doesn't make sense to check if an IPv6 address is reachable if we have no working connectivity).
It's currently tricky to distinguish inside of tcp_connect measurements if an IPv6 target is unreachable due to it being blocked vs it being unreachable because the probe has no IPv6 connectivity.
I think we should add an initial check to the startup of a probe, when we do geoip lookup and resolver identification, that checks if there is IPv6 connectivity and if not present maybe even disable some measurements (it doesn't make sense to check if an IPv6 address is reachable if we have no working connectivity).
It looks like windows uses these endpoints to check for it: IPv4: http://www.msftconnecttest.com/connecttest.txt IPv6: http://ipv6.msftconnecttest.com/connecttest.txt
We could maybe do the same.
This is loosely related to captive portal detection too: https://github.com/ooni/probe/issues/1629