Most connections now carry two addresses at once. Here is why a VPN that only covers IPv4 can leave your IPv6 exposed, and how to check yours.
On this page
Your connection carries two addresses, not one.
Most people think of their connection as having a single address. In practice, a growing share of connections have two, running side by side. That arrangement is called dual stack, and it exists because the world ran out of IPv4 addresses years ago and has been migrating to a much larger pool, IPv6, ever since. The two protocols were designed to coexist during the transition. For privacy, that coexistence creates a specific and underappreciated problem.
Start by seeing your own situation. The IPv6 test shows whether you have IPv6 connectivity at all, and if so, what address it hands out.
Why you have two addresses
IPv4 uses 32-bit addresses, which yields a few billion in total. That was generous in the 1980s and hopelessly short by the 2010s. IPv6 uses 128 bits, a number large enough that running out is not a realistic concern.
| IPv4 | IPv6 |
|---|---|
| 32-bit addresses | 128-bit addresses |
| A few billion in total | Not a realistic concern to exhaust |
| The space the world ran out of | The larger pool networks are moving to |
Because the two do not interoperate directly, network operators run both at once during the transition. Your device is likely to hold an IPv4 address and an IPv6 address, and it will prefer whichever the destination supports.
For a website, that means there are two ways to reach you, and it will see whichever one it happens to ask for. For a VPN, it means there are two paths to protect, and protecting only one leaves the other open.
Why covering one is not covering both
Here is the practical failure. Suppose your VPN tunnels IPv4 but not IPv6, a common enough configuration. Ordinary browsing goes through the tunnel. But when your device looks up a site that has an IPv6 address, it may try the IPv6 path directly, outside the tunnel, and reach the site from your real provider’s address.
The site then sees two visitors: one from the VPN’s network and one from your own. If your browser falls back to IPv6 for some requests and IPv4 for others, the same session can arrive under both identities at once.
That is why an IPv6 leak is often worse than a plain IPv4 leak. It does not merely unmask you. It hands over a matching pair that makes the connection obvious, because the two addresses appear together in the same logs.
| Situation | What the site sees | Risk | The fix |
|---|---|---|---|
| IPv4 only, no IPv6 available | VPN address only | Low | None needed |
| VPN tunnels both protocols | VPN addresses on both | Low | None needed |
| VPN tunnels IPv4 only | Your real IPv6 address | High | A client with explicit IPv6 leak protection |
| IPv6 disabled on the device | VPN address only | Low | Costs nothing on most networks today |
When the two addresses disagree
There is a second consequence, subtler than a leak. Your IPv4 and IPv6 addresses are allocated separately, and the registration data behind them can point to different places. One may reflect the city your provider routes through; the other may be registered to a different region, or to a different provider entirely.
A site that receives both addresses learns two possibly contradictory location signals. The mismatch is not proof of a VPN, but it is a data point, and the kind of thing that feeds a site’s own inference. More broadly, the pair is one more linkable attribute, on top of the ones described in what is browser fingerprinting.
What to check
Run the IPv6 test twice: once with your VPN off and once with it on. The pattern tells you what you are dealing with.
- No IPv6 at all, in either state. There is nothing to leak — the simplest position, though it depends on the transition continuing to spare you.
- IPv6 present when off, absent when on. Your VPN handles it properly.
- IPv6 present in both cases, with different addresses. The one that persists is your real one — that is a leak.
- IPv6 present and identical with the VPN on. Also a leak, unless the address genuinely belongs to the VPN.
What to do about a leak
If you find one, the fixes are the usual ones, in rough order of reliability. Choose a client with explicit IPv6 leak protection. If that is not available, disable IPv6 on the device entirely, which costs you nothing on most networks today. Failing that, use a browser or extension that restricts the discovery paths a page can use, which also helps with the channel covered in WebRTC leaks explained.
Cross-check afterwards with the WebRTC leak test, since the same discovery process can expose addresses over either protocol, and the address you see there may be the IPv6 one your tunnel missed.
The direction of travel
IPv6 adoption keeps growing, and networks that once ran IPv4 alone are switching on dual stack by default. That means the leak described here will become more common, not less, as more connections gain a second address. A VPN that ignores IPv6 is not one that half works. It is one with a hole in it, and the hole widens over time.
Where this fits
The address is only the network half of the story. Even with both protocols sealed, your device still announces a great deal about itself, which is why what is browser fingerprinting is the natural next read. The what is my IP address check remains a starting point rather than a complete answer.