Do I Have IPv6? How to Check Your Connection

The IPv6 test doesn’t ask for a target. It checks the connection you’re already using to read this page, which is what people actually want when they search “do i have ipv6” or “is ipv6 enabled.” Run it and it tells you whether you’re dual stack, IPv4 only, or the rarer IPv6 only, and which one your browser actually picked when it had the choice.

Head to enterramon.com/ipv6-test and hit Run Test. Nothing to type. Behind the button it’s checking five regions from your browser, South Africa, Germany, the US, Singapore, Australia, and for each one it tries three hostnames: one only answers over IPv4, one only over IPv6, one takes both. Which of those respond is the actual signal.

What comes back

Verdict first. Dual stack means both protocols reached us, which is the normal state on most residential and mobile connections now. IPv4 only means your ISP, router, or OS isn’t giving you IPv6, and that alone doesn’t mean anything is broken, you’re just running on a protocol whose free global pool ran out back in February 2011 (regional registries kept handing out their own remaining stock for years after that, so this didn’t happen everywhere at once). IPv6 only shows up on a lab network or a mobile carrier translating your IPv4 traffic behind the scenes.

Below that, which family your browser actually chose. Browsers race IPv4 and IPv6 against each other under RFC 8305, Happy Eyeballs, and use whichever answers first. Having IPv6 and using it aren’t the same thing. If you’re dual stack but the browser keeps landing on IPv4, the IPv6 side is consistently losing that race, which usually means it’s slower on your specific path even though it technically works.

Here’s a real IPv4-only result, ASN redacted, everything else genuine. Verdict IPv4 only, browser preferred IPv4, no surprise there since IPv4 was the only option. What’s more useful is the detail underneath. This connection’s IPv6 attempt didn’t get refused, it timed out, 2502ms before giving up. That distinction is worth knowing, a refusal usually means IPv6 genuinely isn’t offered on the line, a timeout means something on the network is advertising IPv6 that it can’t actually route anywhere, most often a router with IPv6 switched on but no working prefix delegation from the ISP, or a tunnel that’s stopped passing traffic. Disabling IPv6 makes the symptom go away without touching the actual misconfiguration underneath it, and every AAAA-publishing site that connection visits pays the cost of that failed attempt first.

Then the regional table. Raw latency numbers here are mostly telling you how far away a server is, so the number that matters is the gap between IPv4 and IPv6 to the same region, not the absolute figure. We tested this ourselves from a home connection with no IPv6 at all and watched the failure label flip between “no route” and “timed out” for the same region across two runs a few minutes apart, on the same network. Both readings were real. Which one you get on a given run just depends on how fast your OS decides there’s nowhere to send the connection versus how long it sits waiting for an answer that isn’t coming, and that boundary isn’t perfectly consistent even on one connection.

Last, the network you’re testing from. ASN, network name, country, pulled from the same probes, useful for confirming you’re actually looking at your home line and not a VPN or a corporate proxy sitting in front of it.

Reading the regional pattern

IPv6 failing to every region points at your own connection. IPv6 working to some regions but not others is a different problem entirely, and it means your setup is fine, because you clearly have working IPv6 to reach the regions that did answer. IPv4 and IPv6 are routed and peered separately, so a path to one destination can be missing while IPv4 to that identical server works without issue.

Real example of that exact case. IPv6 working, reaching South Africa, the US, Singapore, and Australia without trouble, IPv4 working everywhere including Germany, IPv6 to Germany specifically timing out while IPv4 to that same server answered normally. The connection’s fine, the route to one particular region just isn’t there over IPv6 right now. Worth repeating the test before treating a single region’s gap as settled, since transit and peering arrangements do shift.

The same result also shows something worth calling out on its own, a region where both protocols reached the destination but took visibly different paths to get there. Singapore came back 326.5ms over IPv4 and 176.5ms over IPv6, a 150ms gap on the same test run to the same target. That’s not measurement noise, IPv4 and IPv6 are genuinely allowed to take different physical routes to the same destination, and when they diverge by that much, it usually means one of the two is going through extra hops, an indirect transit path, or a peering exchange the other protocol skips entirely. Neither protocol is broken here, they’re just not travelling the same way, and the traceroute tool is the way to actually see where the two paths split if you want to chase that further.

A penalty on every single region instead of just one points somewhere different again, usually a tunnelled IPv6 setup or your traffic exiting the network at a more distant border than IPv4 does. We root-caused exactly this kind of pattern once during testing, chased what looked like a broken region down to plain network congestion on the day, confirmed independently with a bare curl request from two separate machines. Not every anomalous reading is IPv6 being broken. Sometimes the network’s just slow that hour.

Disabling IPv6 tends to make the symptom go away without fixing anything, which is exactly why that advice keeps circulating. Whether your connection is refusing the attempt outright or sitting there timing out tells you where to actually look next, router settings or your ISP, rather than switching the whole protocol off and leaving the real fault in place.

What this isn’t

It’s a connectivity and latency check, not a throughput test. A real throughput comparison needs a multi second sustained transfer, and at that point you’re mostly measuring your last mile rather than IPv6 itself, so we didn’t build that in.

It also stops at your browser talking to our probes. Your router’s prefix delegation, your local DNS setup, a firewall quietly dropping specific ICMP types, none of that is in scope here. If you want to see adoption by country or network rather than your own connection, that’s the Global Analytics page. For why one particular site feels slow, the Ping Test shows whether the gap is steady or comes and goes, and Traceroute will actually show you where the two protocols’ paths split.