test-ipv6.com FAQ
Q: Can you fix my VPN?
No, I can not fix your VPN.
Q: How does this test work?
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.
Q: Why is this web site reachable via IPv4 only?
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-ipv6.com dual-stack. At last check, March 2017, we still see 0.2% broken visiting test-ipv6.com. And we still want them to understand their situation.
Q: I run a production IPv6-only network. Without IPv4. My users can't reach test-ipv6.com.
Send email to jfesler@test-ipv6.com. If your IPv6-only network has dedicated name servers, or a dedicated BGP ASN, jfesler will enable AAAA records for test-ipv6.com for you.
If you don't meet the above requirements, you can visit http://ipv6.test-ipv6.com (IPv6-only) or http://ds.test-ipv6.com (IPv4+IPv6).
Q: What do you mean by broken?
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.
Q: Why did your stats say you already have IPv6-only users?
They went to http://ipv6.test-ipv6.com .
Q: How valid are the stats?
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.
Q: How does your test differ, from what the content providers are doing?
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.
Q: What are your data sources?
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.
Q: What features have been added/removed?
- 2017: Added TLS (https) support
- 2022: Removed links to swap http/https. Browsers are starting to forcefully upgrade to https.
- 2022: Removed tunnel detection by comparing ASN numbers. More service providers are using a different entity for IPv4 vs IPv6.
- 2022: Removed direct IP checks, NAT64 detection, Teredo detection. This is for support cost reasons; too many people complain about the tests that are skipped in https mode, and we're seeing browsers forcefully upgrade to https.
Q: Do you actually read the feedback?
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.
Q: Is this open source?
Yes. See the source page for details.