test.ipv6s.com FAQ

No, I can not fix your VPN.

The test is entirely client-side javascript. To determine reachability, a series of ajax requests are made from the web server, using various DNS names that force the use of IPv6 only, or dual stack, or other such scenarios. The pass/fail of such fetches, as well as how long they take, are taken into account.

You're right, there are no AAAA records, intentionally. A percentage of users are unable to browse sites that are dual-stack. If the users can't connect, then they can't be told they have a problem. This is a big problem facing content providers today; of which, I work at one for my $dayjob. As such, the main test page requires IPv4 (either native or translated).

At some point, when the percentage of "broken" users has gone significantly down, I'll consider making test.ipv6s.com dual-stack. At last check, March 2017, we still see 0.2% broken visiting test.ipv6s.com. And we still want them to understand their situation.

Send email to jfesler@test.ipv6s.com. If your IPv6-only network has dedicated name servers, or a dedicated BGP ASN, jfesler will enable AAAA records for test.ipv6s.com for you.

If you don't meet the above requirements, you can visit http://ipv6.test.ipv6s.com (IPv6-only) or http://ds.test.ipv6s.com (IPv4+IPv6).

A percentage of users today have IPv6 enabled, but are either using a public tunnel that is currently giving poor performance; or otherwise have a route that is installed but broken or suboptimal. However, because they have a route at all, in many cases the address selection algorithm of RFC3484 will pick using it, and trying to use this broken route. It can take towards 75+ seconds before the browser gives up!

From the perspective of a user with these conditions, a web site offering both A and AAAA DNS records (ie, "dual stack") will appear to time out; and the user will move on to another site that offers a similar product. This is the quandary content providers have.

If we detect that you will have problems reaching dual-stack web sites, we recommend you see the Broken User FAQ. It provides several steps to try and identify your root cause for being broken; and barring that, what you can do to disable IPv6 until your ISP offers native IPv6 connectivity.

They went to http://ipv6.test.ipv6s.com .

They do not represent the average web consumer. Visitors to this site are self-selecting. The intent of this site is to not provide stats, but instead to inform the user the level of readiness for the world to move to IPv6 (with or without'em!). As such, stats found here will be completely different from an average content provider.

Content providers are gathering metrics of broken vs non-broken users, in an aggregate form. They are not at this time actually giving the user feedback as to the user's current state. Those metrics will principally drive the business decision of when to start publishing sites over IPv6, versus remaining IPv4 only. IPv4 only for some content sites really is an option; it has a handful of downsides, but the expectation is that everyone will always be able to reach IPv4, in some fashion.

This site, on the other hand, is intended to help the user understand their current state, and what that state possibly means to them.

The following data sources are checked daily, and are used to convert IP addresses into Internet Service Provider names.

• University of Oregon Route Views Archive Project provides hourly views of the Internet routing tables.
• http://bgp.potaroo.net/asn.txt is a curated list of ASNs to internet service provider names. This is provided by Geoff Huston, a well respected researcher from APNIC.

Yes, I do. Thank you! Note that I can only follow up with you if you do leave contact information. While I am still grateful for feedback without contact information, I will be unable to reply with any answers if you asked for them.

Yes. See the source page for details.