IPv6 test. Whether you have it, and whether your site does

An IPv6 test answers a question that sounds like one question and is two. Does your own connection speak IPv6, and does the site you are testing answer on it? They are independent, and a network can pass one and fail the other.

You can test both from five regions without an account. This is how to read what comes back.

Two questions, not one

The first question is about you. If your provider hands you an IPv6 address, the result shows that address and a round trip time for it. If it does not, the v6 row stays empty while the v4 row answers normally. That is not a fault in your computer and there is nothing to reinstall. It is your connection, and it is a more common result than you would expect.

The second question is about a hostname you type in. The tool looks for an AAAA record, which is the DNS record that publishes an IPv6 address, and then it tries to reach that address from each region. Those are two separate checks on purpose, because publishing an address and being reachable at it are not the same thing.

How to read an IPv6 test result

The verdict is about the shape of the result rather than a count. Four outcomes matter.

IPv6 means both families answered. That is a healthy dual stack, and the tool reports which of the two it would prefer. When both work, the faster median wins, which is the choice a modern browser makes for itself.

No IPv6 means the v4 side answered and the v6 side did not, from any region. Your provider is not offering IPv6 on this connection.

IPv6 only is the opposite and is the direction the internet is moving. The name resolves to a v6 address and not to a v4 one, so anything that cannot speak v6 cannot reach it at all.

Partial IPv6 is the interesting one. Some regions reach the v6 address and others do not. That usually means a routing or peering problem on one side rather than a missing record, and it is the fault that gets missed most often, because the site works perfectly from wherever the person testing it happens to sit.

The tool also reports the difference between the v4 and the v6 round trip. A v6 path that is meaningfully slower is worth knowing about, and a v6 path that is faster is what a correctly built dual stack usually looks like.

An AAAA record nobody can answer is worse than no record at all

Publishing an AAAA record tells every client that this name can be reached over IPv6. A client that believes it and gets no answer then has to wait for a timeout before it tries IPv4 instead.

So a site that adds an IPv6 address it has not tested is not making an improvement. It is adding a delay for every visitor whose device prefers the family that does not work, and the visitors least likely to have working IPv6 are also the ones most likely to notice. That failure mode is why the tool tests reachability rather than reading the DNS and stopping there. The server check tests the same thing from outside, over both address families.

Why this stopped being a technicality

IPv6 has been a published standard since December 1998, when RFC 2460 was released. Anyone born the month that document was published is now a qualified doctor a couple of years into practice. That is how long this migration has been running, and it is the slowest one the internet has attempted.

It is finally moving. Google has published the share of its traffic arriving over native IPv6 since 2012, with data going back to 2008, and on 28 March 2026 that line crossed 50 percent for the first time, at 50.10 percent. It had come within half a point of the mark a year earlier and then stalled for months. You can watch the number move yourself on Google's own IPv6 statistics page, and the Internet Society's write-up of the milestone explains the shape of the curve.

That headline figure hides an enormous spread. The same measurement puts a few countries far ahead of the average and others far behind it.

The pattern is not about wealth or technical skill. It is about whether the large access networks in a country turned IPv6 on, because that decision reaches millions of people at once and nothing else reaches them as quickly.

In Africa the pressure is sharper than anywhere else. AFRINIC entered its Soft Landing phase in 2020 with no more than a single /11 of unreserved IPv4 space left, and it has since recovered more than 3 million addresses from organizations that gave them back. Even so, its own policy documents put the available pool at 783,872 addresses, which at the current rate of delegation is about two years of requests. There is a further /12, roughly a million addresses, held back for future use, which is another three years at best. The proposal that recorded those figures, AFRINIC's Soft Landing, Recovered Space and Priority, was ratified on 25 September 2026.

A region with under 800,000 IPv4 addresses left cannot grow an internet on IPv4. It can only rearrange what it already has, and every rearrangement is a negotiation with whoever holds the space today.

Where the change has to come from

An individual cannot switch IPv6 on for their internet connection. That decision belongs to the access provider, and for most people the honest answer is that it is not theirs to make.

The same is true one layer down. A hosting provider can publish IPv6 for every site it runs, and it makes no difference if the visitor's provider does not carry it. This is why the migration has taken this long. It needs thousands of independent networks to make the same decision, and the benefit to any one of them arrives late and mostly to somebody else.

What an individual can do is smaller and still worth doing. You can find out whether your own connection has IPv6, which takes one test and is the first line in any conversation with a provider. You can check whether your own site publishes and answers on IPv6, and fix it if it publishes an address nobody can reach. And you can ask, because the networks that have not deployed it are usually the ones where nobody has asked.

Testing your own site

Run the tool with your own hostname in it. If the DNS section reports IPv4 records only, your site has no IPv6 presence at all and the fix is at your host or your CDN rather than in your code.

If it reports IPv6 published and a region fails to reach it, you have the partial case, and that one is worth chasing. It usually resolves to a peering problem or a firewall that was never opened to the v6 range, and it stays invisible to anyone testing from the wrong continent.

The other network tools cover the rest of the picture. A trace shows the path, and a server check tests the certificate and the port.