IPv4 and IPv6 Are Two Networks, and Only One Was Slow

Research· 6 min read· By EnterraHost Network Operations Team

Published 31 October 2026

IPv6 reached Singapore 51 milliseconds faster than IPv4, a fifth of the total, measured from the same machine to the same cities in the same minute. Nine minutes later IPv6 to Frankfurt stopped working entirely while IPv4 to the same host carried on untouched.

Both results came from one test run on 31 October 2026, and together they make the case for checking both address families rather than one. IPv4 and IPv6 are not one network with two address formats. They are two networks that happen to end at the same server, and they can disagree about distance, about speed, and about whether a destination answers at all.

IPv6 and IPv4 across five regions, in one minute

Every figure below is a browser-measured round trip. One request travels on an already warm connection, so the number is a single trip across the network plus the endpoint's own processing of about 15 to 30 milliseconds. Nothing here is modeled or estimated.

IPv6 won in four of five regions, and by a fifth of the round trip to Singapore. The differences of 1, 9 and 12 milliseconds sit inside the noise of a home or office connection. The 51 milliseconds does not, and it held across repeated runs.

Independent ICMP round trips to the same regions in the same window were 153 ms to Frankfurt, 234 ms to St Louis, 273 ms to Singapore and 383 ms to Sydney. Those numbers are what make the table credible rather than merely precise. The browser figures sit a few milliseconds above ICMP because a small PHP endpoint answers in between.

Why the two families disagree about the same two cities

IPv4 and IPv6 are routed separately, often by different teams, and often bought from different providers. A network can have excellent IPv4 transit and a badly tunneled IPv6 path, or peer IPv6 locally in one city and hand it off far away in another. The result is not slower internet in general. It is one pair of endpoints taking a different route in each family, which is what a 51 millisecond gap to Singapore looks like from a distance.

The failure that hides is partial

Nine minutes after the table above was taken, IPv6 to the Frankfurt probe stopped working. Requests failed with Destination unreachable, returned by a router in a different address block from the destination. IPv4 to the same host was unaffected throughout. A packet capture on the destination showed the host receiving the IPv6 requests and sending replies, so the packets were lost on the way back. Ten minutes later it recovered on its own. Nothing had been reconfigured, because nothing had been wrong at either end.

Ask one question from one place and the answer is working, broken, or slow. The fourth case is working on one family and broken on the other, from part of the world, and it looks like success from the wrong vantage point. No uptime monitor pages anyone, because the check it ran passed. Visitors on the broken path cannot reach the site at all, and they do not file a ticket. They leave.

A partial failure is a routing question, and the only way to see it is to ask several regions, over both families, at the same time.

How this was measured, including what we got wrong

The method is simple in principle and easy to get wrong in practice, which is worth describing because the wrong version produced numbers about four times too large and looked entirely plausible.

Each region has two hostnames, one with only an IPv4 address and one with only an IPv6 address, so the hostname decides the family and the code cannot drift away from the DNS. Each probe is requested twice. The first request opens the connection, and the second one is the one measured, on a path that is already established.

Three faults had to be fixed before the numbers were true.

• The request was opaque. A cross-origin no-cors fetch exposes no timing phases at all, and every field reads zero. The measurement silently fell back to start-to-finish, which includes DNS, TCP, TLS and the response, roughly four round trips, and called that latency.
• The probe did not allow the origin. Even a request for readable timings would have failed, because the endpoint's CORS list named only the other site.
• The clock started too early. After the switch to a readable request with a warm-up, the timer still began before the warm-up, so both connections' handshakes were counted. That made the numbers worse. Singapore reported 1,201 ms against an ICMP round trip of 273 ms.

The lesson is not that timing is hard. It is that a plausible number needs an independent check, which here was ICMP. Without it, 1,201 ms to Singapore looks like a slow region rather than a broken stopwatch, and every conclusion drawn from it would have been wrong.

What to do with this

If you run a site or a monitoring setup, three things follow.

Test both families. A site that answers over IPv4 is not necessarily reachable over IPv6, and a large share of visitors now arrive over IPv6 where it is offered. Checking one family checks half your visitors.

Test from more than one place. A partial route failure is invisible from a single vantage point by construction, because the whole point is that it works where you are standing.

Do not trust a latency figure without a second opinion. A tool's number is only as good as its measurement, and the failure mode is not an error message but a number that looks reasonable.

The test used here is free and needs no account. It reports your own connection first, then measures the same five regions over both families and names the one that failed. Run the IPv6 test.

Method, in full

• Five regions, Cape Town, Frankfurt, St Louis, Singapore and Sydney.
• Two hostnames per region, one per family, DNS only, so the connection is direct rather than proxied.
• Two requests per probe, with the second measured on a warm connection, so the result excludes DNS and TLS.
• Cross-checked against ICMP round trips to the same regions in the same window.
• Measurements taken on 31 October 2026 at about 11.52 SAST. The rows ship as a CSV.

One caveat. This measures the path from one host in Cape Town. A different vantage point would produce different numbers, which is the argument for testing from several rather than against the result.