Feature Request: Native IPv6 support (no NAT)

[Divinity3372 0]

AirVPN has decent IPv6 support (certainly the best I've seen from VPN providers).

However, they still use NAT66 on the server side, and configure tunnels with a single Unique Local Address (ULA) [fd00::/128]. This results in some weird behavior over native IPv6 (with Global Unicast Addresses (GUAs) [2000::/128] in the tunnel):

- Clients don't know their real v6 address.
- Most software prefers IPv6 GUA over IPv4 over IPv6 ULA, causing IPv4 to be used even if IPv6 is available.
- NAT66 can cause some weird behavior as well.

My question is why this design was chosen, other than that it mirrors the v4 side 1:1.

Given that IPv6 isn't in short supply and it appears that most servers are given at least a /64 from their respective hoster (e. g. M247 and Netrouting B. V.), it should be possible to configure each tunnel with its own global address and skip NAT66.

This would make v6 a proper first class citizen, and make the setup way more similar to a non-VPN IPv6 setup, which also uses GUAs everywhere.

I can think of a couple of challenges implementing this, but nothing impossible to solve:
- Deanonymizing users is potentially easier if they have their own distinct addresses (correlating traffic). But I think this should be easily solvable with OpenVPN by assigning a new v6 on each reconnect.
- Wireguard is a bit more difficult as the tunnel IP is baked into the config: Sharing configs across servers wouldn't be possible, and the address would be static. However, Eddie could just regularly rotate addresses and reconfigure them for the proper server.

[Staff 10652]

20 hours ago, Divinity3372 said:

why this design was chosen

Hello!

Thank you for the detailed suggestion. The main reason for this design is privacy. Sharing public exit IP addresses among many customers is one of AirVPN's foundational privacy features, and we deliberately preserve that property for IPv6 as well.

Assigning a unique public IPv6 address to each customer or tunnel would make that tunnel's traffic distinguishable by its source address. Websites and other observers able to see multiple connections could use that address to correlate activity belonging to the same tunnel, even without knowing the customer's real identity. With a shared exit address, the address alone does not provide that distinction between customers.

Changing the address on each OpenVPN reconnect, or rotating it periodically through Eddie, would reduce the time window for this correlation. However, throughout each address lifetime it would still identify one tunnel rather than be shared by many customers. Rotation therefore does not preserve the same privacy property.

We understand the appeal of globally routable tunnel addresses and the compatibility concerns you raise. However, the availability of IPv6 addresses does not resolve this privacy tradeoff: assigning an exclusive public address to each customer would remove a fundamental characteristic of our service.

If you have a specific application or reproducible IPv6 issue with the current setup, please share the details so we can examine that separately.

Kind regards