Is IPv6 faster than IPv4? Exactly as fast as the road your ISP gave you

“IPv6 is faster than IPv4” appears in almost every networking article: there are enough addresses for everyone, so there is less address translation along the way, so the route is straighter. We believed it enough to write the reasoning into a comment in our own code and put IPv6 first in the connection queue. Then we actually measured it — and got different answers on different networks. Where the IPv6 road is well built, there is no difference between the protocols at all. Where it was laid later and out of leftovers, IPv6 is 72% behind. And on a mobile network it wins instead. Below: the measurements themselves, a comparison table, the cause we found, one elegant theory we had to throw out, and a plain answer to what you should do about it.

The short answer

IPv6 is exactly as fast as the road your ISP gave you. Not “faster”, not “slower” — it depends, and the spread between networks is wider than the difference between the protocols themselves. Here are two of our own points, taken the same way to the same target: 60 packets each, both protocols back to back from one machine.

The same pair of protocols, the same method — and completely different answers. In Amsterdam, where the target sits practically next door, the protocol means nothing: 0.78 vs 0.90 ms is noise. From Russia the very same IPv6 travels noticeably further. So it is not the protocol, not its header size and not the MTU — otherwise the gap would be the same in both cases.

And a third point, which we honestly label an observation rather than our own measurement. On the MTS mobile network in Blagoveshchensk IPv6 consistently beats IPv4 for us — by an estimated 20% and more. We have not put an instrument on it yet, so it does not go in the table. But the direction matters just as much: on that carrier the IPv6 road turned out to be better than the IPv4 one. The same cause as in the first two rows, with the sign reversed.

Hence a conclusion that survives all three points: “which is faster, IPv4 or IPv6” is not a question about protocols, it is a question about your ISP. The general rule “IPv6 is faster” is wrong; the opposite rule “IPv6 is slower” is wrong in exactly the same way. Testing it on your own link takes two minutes — see the end of the article.

Why IPv6 was created, what it solved, and where it stands today

IPv6 was not invented for speed. It was invented because IPv4 was running out of addresses, and that was arithmetic rather than a guess: an IPv4 address is thirty-two bits, which is 4.3 billion possible addresses for the entire planet. The protocol was designed in the early 1980s for a network of a few hundred organisations — back then four billion looked like a supply that would never end. A phone in every pocket, a watch with internet and a light bulb with Wi-Fi were not in the picture.

By the early 1990s it was clear the supply would run out, and the IETF started on a successor. The first edition shipped in December 1995 (RFC 1883), the main one in December 1998 (RFC 2460), and the standard in force today is RFC 8200, approved in July 2017. Its address is a hundred and twenty-eight bits. The number is too large to feel, so here is the conversion: IPv6 has roughly 6.7·10²³ addresses for every square metre of the Earth’s surface, oceans included. “Enough addresses” is not solved with room to spare; it is solved for good.

What it actually solved. Exactly one thing: giving every device an address of its own again. Everything else usually listed is a consequence. Your own address means you can be reached from outside: a home server, a camera, a console, a call or a game running directly between two people stop running into a middleman. The packet header was simplified along the way, and address configuration was made automatic, with no separate server needed.

What kept IPv4 alive until today. A workaround you use every day without knowing it — address translation. First at home (the whole flat behind the router’s one address), then at the carrier, CGNAT: one real address shared among hundreds of subscribers. The workaround worked so well that it postponed the migration by a quarter of a century — and it is also to blame for half of all “I cannot reach my own server from the internet” complaints.

And the addresses did run out, with dates attached. The global IANA pool was exhausted in 2011. In our region — RIPE NCC, which covers Europe, Russia, the Middle East and Central Asia — allocation moved to the last block of 16 million addresses on 15 September 2012, and on 25 November 2019 the free addresses ran out entirely. Since then a new IPv4 address can only be waited for in a queue or bought from someone who has one: addresses became a commodity with a price.

What IPv6 did not solve. It is not backwards compatible: a host that only has IPv6 cannot talk to a host that only has IPv4 on its own. So the world did not “migrate” — it lives on both protocols at once, and will for a long time yet. Which is where this whole article comes from: with two protocols in play, every connection starts with the question of which one to use.

Where IPv6 stands now. It is no longer the future, and no longer an experiment. APNIC continuously measures the share of users for whom IPv6 actually works — not “announced by the ISP”, but passing a live probe. The figures as of 30 August 2026:

The world figure grows smoothly, without jumps: 2.3% in 2014, 16.9% in 2018, 32.4% in 2022, 43.5% now. In a few years half the internet will speak IPv6 by default, and in France that is already the case.

The Russian row is a special case, and we are not going to pretend we understand it better than we do. The same instrument has given Russia both 9% and 2% over recent years: the series jumps between readings in a way the world curve never does. Today’s value is 2.3%, and over the past year it stayed between 2 and 4.5%. We do not know the reasons and will not speculate; one thing can be said reliably: in none of those readings did Russia come close to the world level.

IPv4 vs IPv6: the differences

First, the thing most people come for: how the two protocols differ in practice. Speed and round-trip get their own rows, and they are the only two rows we verified by measurement rather than repeated from somewhere else.

The rows about addresses and headers are common knowledge; you can read them anywhere. Look at the two rows in bold: the only honest answer this table can give about speed is “depends on the route”. What follows is the part that exists nowhere else: what happens when you run the same tunnel to the same server over each of them — and why on one route the gap is a third and on another there is none at all.

Throughput: one road, three interleaved pairs of runs

Ping shows how long the road is, but what people care about is throughput. We ran it on the very road where IPv6 lagged — from Russia into Europe. This measures one specific route, not a property of the protocol: on the Amsterdam point, where the round-trip is identical, there would be nothing for such a gap to come from.

What changed and what was held fixed. The same server, the same config, the same tunnel, the same payload downloaded through it — 50 MB over a single TCP connection. Exactly one thing differed: whether the tunnel’s outer transport ran over IPv4 or over IPv6. The tunnel MTU handed out was identical in both cases, 1397 bytes. Runs were interleaved (IPv4, IPv6, IPv4, IPv6…) so the difference could not be blamed on the link warming up.

The average is not the important part. This is: the two columns do not overlap. The slowest IPv4 run (145.0) beats the fastest IPv6 run (114.4). When the spread inside a column is smaller than the gap between columns, it is no longer noise.

This is the second such measurement, not the only one. Eight days earlier, by the same method on the same route, the link was three times slower in absolute terms — 63 vs 52 Mbit/s. Same sign: IPv6 lost then too, by 17%. In eight days the link got two and a half times faster, and the IPv6 deficit did not disappear — it grew.

The cause: what is longer is the route, not the protocol

The throughput of a single TCP connection is limited not only by bandwidth but by latency: the sender can keep only one window of data in flight and then has to wait for an acknowledgement. So doubling the ping roughly halves the throughput, all else being equal. We measured the round-trip time between our own hosts over both protocols — ten packets each, on the same day as the throughput test.

Three pairs out of three — IPv6 is longer. And these are the same three pairs measured eight days earlier, when the differences were +38, +21 and +34 ms. Neither the sign nor the order of magnitude moved in a week, so this is a stable property of the routes, not a one-off piece of bad luck.

The ratio lines up to within the right order of magnitude: the IPv6 round-trip is 1.65× longer, the throughput is 1.44× lower. It is not an exact match and we are not going to force one — throughput depends on more than latency. But the direction and the scale are fully explained by latency, and no second explanation was needed.

Why it works out that way: IPv6 networks at carriers and data centres were built later and separately, with their own peering arrangements. Two addresses on the very same box can lead to it by completely different paths — and the IPv6 path is often the one that still goes “via Frankfurt” when IPv4 stopped doing that years ago. That is not a flaw in the protocol; it is the age of its road map.

A separate word on packet loss — because this is where we nearly got it wrong ourselves. In this ten-packet run two packets were lost over IPv6: a resounding “20% loss”. But the measurement at the top of the article — the one with sixty packets — showed no loss at all, on either protocol. A loss rate has a minimum sample size: one missing packet out of ten turns into a loud figure that is not really there. We are putting it here so you do not fall for the same thing when measuring your own.

The “it is the MTU” theory, tested and rejected

The first thing that occurs to anyone who knows tunnels: an IPv6 header is 40 bytes against IPv4’s 20, so there is less payload per packet, so throughput is lower. It is an elegant theory, it takes one command to test — and it is wrong.

We sent maximum-size packets along the route with fragmentation forbidden (ping -M do): 1452 bytes of payload over IPv6 and 1472 over IPv4 — exactly the numbers that fill a 1500-byte frame once each header is accounted for. Both got through, in both directions. So the path carries a full-size frame, nothing is being fragmented either way, and the 20-byte header difference costs about one and a half per cent of the frame — nowhere near thirty.

Add to that the tunnel’s own MTU, which was identical in both measurements (1397): the client sliced the data into the same chunks regardless of transport. It is not the size of the packet. It is the length of the road.

Our own mistake

The unpleasant part of this story is that we did not read “IPv6 is faster: less NAT, a straighter route” somewhere and copy it — we wrote it ourselves. It sat as a comment in our code and served as the justification for trying IPv6 first. The wording looked like knowledge. It was in fact a guess nobody had checked; it simply agreed with what everybody knows.

Now the measurement exists, and it does not support the justification. We are leaving that sentence in the article exactly like this rather than quietly rewriting history, because that is the difference between a measurement and an opinion: an opinion can be edited in silence, a measurement has to be published together with whatever it refuted.

Here is what the measurement did not overturn: the decision to try IPv6 first is still right. It just rests on a different, checkable foundation now (see below) rather than on a rule that does not exist. A good decision with a bad justification is still a bad justification, and the justification is what needs fixing.

An address is not a route

The second practical conclusion is worth more than the first. A device having a global IPv6 address does not mean anything can be reached over IPv6. The address is handed out by the network; whether the path works depends on the whole chain beyond it — and that chain breaks noticeably more often than the IPv4 one.

We measured that gap on live connections. Over two days: 11 attempts to go over IPv6 from devices that did have an IPv6 address.

Notice how tightly the successes cluster: in every successful case the answer came back within a quarter of a second, with seventeen milliseconds of spread across the whole sample. That gives a rule you can use by hand: if IPv6 has not answered within the first half second, waiting longer is almost certainly pointless. A working path does not think that hard. Seconds of waiting are not a slow answer; they are the absence of one.

This also explains the most common complaint about IPv6 — the one where the system shows an address but nothing connects over it. The fault is not in your settings: the address and the route are handed out by different mechanisms, and the first can work perfectly well while the second is broken.

Why we put IPv6 first

Since there is no general rule, and the spread between networks is wider than the difference between the protocols, the only honest way to choose is not to choose in advance — but to ask the network itself. That is what we did: in the Mayak app IPv6 is the first rung of the connection. Every connection starts there, and if IPv6 does not answer, the app moves to the next route by itself, without asking anyone.

Why first, if IPv6 lagged by a third in one of our measurements? Because what lagged was the road, not the protocol — and the road is different for everyone, and we do not know it in advance. Where the carrier built IPv6 well (increasingly common on mobile networks — see the third point at the top), the very first attempt is also the best one.

And where they did not build it, the cost of being wrong is known to the millisecond, and it is small: by the measurement above a live IPv6 route answers within a quarter of a second, with seventeen milliseconds of spread across the whole sample. There is no reason to wait longer, and the app does not. That makes it an asymmetric bet: the upside is the whole benefit of a good road, the downside is a fraction of a second at the start of one connection. With that asymmetry, trying IPv6 first pays off even where it is slower on average.

IPv6 in a WireGuard or AmneziaWG config

If you are setting a tunnel up yourself, there are three things to know about IPv6, and all three are easy to miss.

1. The server address goes in square brackets. In an Endpoint line a colon separates the port, and an IPv6 address is full of colons — so the address goes in brackets and the port comes after:

Endpoint = [2001:db8::1234]:51820

Without the brackets the line is parsed wrongly, and the error you get is often not about the address at all.

2. The outer transport and what travels inside are different things. A tunnel can reach the server over IPv6 while carrying nothing but IPv4 traffic inside it, as in the measurement above. And the other way round. Do not confuse “I connect over IPv6” with “my websites load over IPv6” — those are two independent settings.

3. Without ::/0 in AllowedIPs, IPv6 traffic bypasses the tunnel. This is the real trap. The line AllowedIPs = 0.0.0.0/0 sends all IPv4 into the tunnel and none of IPv6. If your ISP gives you IPv6, sites with an IPv6 address will load around the tunnel, under your real address. From the outside everything looks connected, and a “what is my IP” check may well show the server’s address — because that check arrived over IPv4.

So do you need IPv6?

You do. None of the above adds up to “turn IPv6 off” — only to this: do not expect speed from the protocol by itself, because speed comes from the route. No measurement takes away the other advantages of IPv6, and they are real.

• Everyone gets an address. ISPs have long been handing one public IPv4 address to hundreds of subscribers; IPv6 gives the device an address of its own.
• Incoming connections work. Anything that needs to be reached from outside — a home server, a camera, a game that connects players directly — runs into address translation on a shared IPv4 address and simply works over IPv6.
• Some networks no longer hand out IPv4 at all — there the question does not arise.
• But IPv6 is not “safer” or “more anonymous”. If anything it is the reverse: a stable address of your own is easier to recognise than one shared with a hundred neighbours.

For a tunnel to a server the practical conclusion is this: keep both protocols available and do not crown a winner in advance. That is exactly what we ended up doing — we try IPv6 first and stay on whichever route answers, rather than on the one that ought to be faster according to the textbook.

How to check it yourself

The whole measurement in this article repeats with three commands — nearly identical on macOS, Linux and in PowerShell on Windows. Take any server that has both kinds of address and ask it twice.

Step 1. Compare the round-trip time — this is the number that matters, everything else follows from it:

• Over IPv4: ping -c 20 example.com (on Windows, ping -4 -n 20 example.com)
• Over IPv6: ping6 -c 20 example.com (on Windows, ping -6 -n 20 example.com)

Look at the average and at the losses. A 20–30 ms difference is already a visible chunk of throughput for a single download.

Step 2. Check that a full-size packet gets through (fragmentation forbidden, maximum size):

• Over IPv4: ping -c 3 -M do -s 1472 example.com
• Over IPv6: ping -6 -c 3 -M do -s 1452 example.com

It got through — the path carries a full frame and MTU is not your problem. It did not — reduce the size until it does, and you have found your limit; what to do with it next is in the MTU write-up.

Step 3. Measure throughput through the tunnel, not past it. This matters: your link’s advertised speed and the speed inside a tunnel are different numbers, and the second one depends on the route. Download the same file of a decent size (tens of megabytes) first while connected over one protocol, then the other — and interleave the runs rather than doing them back to back. Why speed tests lie so often and what they actually measure is covered separately: it feels like the VPN is slow.