IPv4 / IPv6 Dual-Stack Test
Find out whether your connection actually has IPv4, IPv6 or both — by contacting each protocol separately, instead of guessing.
This test is not configured on this deployment
A real dual-stack test needs two hostnames: one published with only an A record, one with only an AAAA record. Neither is configured here, so there is nothing to test against.
MyIPKit will not fake the result. Showing “no IPv6” because an endpoint does not exist would be reporting our own missing configuration as a fact about your connection.
In the meantime, the local checks page has a one-line command that answers the same question from your own machine.
Lookups are processed on request and are not stored. MyIPKit keeps no record of what you look up.
How this test works
DNS is what makes an honest test possible. One hostname is published with only an A record, so reaching it is only possible over IPv4. Another is published with only an AAAA record, so reaching it is only possible over IPv6. Your browser tries both. There is no inference and no guessing: if a reply comes back, that protocol works, and the address in the reply is the one your connection actually used.
This is the only correct way to learn both addresses, and it is why the home page shows just one. A single request cannot reveal both.
Reading the result
Both working — dual-stack
The modern configuration. Your browser will generally prefer IPv6 when a site offers it, and fall back to IPv4 otherwise.
IPv4 only
Still the most common situation worldwide, and nothing is broken. Effectively every public service publishes an IPv4 address, so you will not notice a difference day to day.
IPv6 only
Increasingly common on mobile networks. Reaching IPv4-only services then depends on your provider’s translation layer, usually NAT64 with DNS64.
Neither reached
This tells you nothing about your protocol support — you clearly have working connectivity, since this page loaded. Something is blocking the requests themselves.
Why “not reached” and not “unsupported”
A failed request has several possible causes that look identical from the browser: no support for that protocol, a firewall, a captive portal, a VPN that only carries one protocol, or the endpoint being down. Reporting one of those five as fact would be a guess dressed up as a measurement. The distinction matters most for exactly the people who use a tool like this.
Limitations
- This measures your browser’s connectivity, not your whole network. Another device, or the same device on another interface, can differ.
- A VPN changes the answer, sometimes to only one protocol. That is the VPN’s behaviour, not your provider’s.
- Your IPv6 address will usually differ between tests, because privacy extensions rotate the host portion by design.
Why can the home page not show both of my addresses?
One HTTP request travels over one protocol and reveals one address. Sites that display both are making a second, separate request to a differently-configured hostname — exactly what this tool does, openly. MyIPKit will not present that as if it came from your original connection.
Is IPv4-only a problem?
No. Most connections worldwide are still IPv4-only and everything works, because almost every service publishes an IPv4 address. IPv6 becomes relevant if you need to reach an IPv6-only service, or if your provider has moved you behind carrier-grade NAT and you want a directly reachable address.
My IPv6 test failed but I know I have IPv6. Why?
A failed request means the endpoint was not reached, which is not the same as having no IPv6. A firewall, a captive portal, a VPN that only tunnels IPv4, or the endpoint itself being down all produce an identical result. That is why this tool reports “not reached” rather than “no IPv6”.
Why does my IPv6 address look different each time?
Most operating systems use IPv6 privacy extensions, which rotate the host portion of your address periodically. The first half — the network prefix from your provider — stays stable, while the second half changes by design to make you harder to track.