IPv6 Addresses Don't Replace Your VPN: Walk the Original Job

Open the client's status page, see a global IPv6 address, and the temptation is to conclude the tunnel has become optional. That page shows an address, not an encryption boundary, not a private routing table and not an access decision. A VPN usually carries three jobs at once, and IPv6 touches only the one about sharing scarce addresses. Walking a single service from the client to the listener is the only way to see which job survives the change.

Name the job before you remove the tool

People say "the VPN" when they mean one of three arrangements, and the three fail for different reasons. Reaching one application published by one team is an application-access problem. Joining a defined set of private networks so that several sites can reach each other is a routing relationship. Keeping a stable administrative overlay over infrastructure you do not fully control is an operations arrangement with its own address plan.

IPv6 removes an address-sharing obstacle for the first arrangement, and there it does real work, because a direct address can replace a translator. For the other two it changes nothing, since the requirement was never address scarcity. Write down which of the three you are actually running before you touch a configuration.

A public address is not encryption

A globally scoped address tells you where a host can be reached; it says nothing about whether the traffic arriving there is encrypted or authenticated. RFC 8504's security discussion separates IPsec implementation support from the wider choice among IPsec, TLS, SSH and other approaches, which is precisely the distinction that disappears when addressability is read as protection. A stack that supports a mechanism has proved only that the mechanism is available, never that this flow went through it. For IPsec specifically, the negotiated association and the traffic it selects decide what is protected, and an address family is a property of the packet rather than a policy for it.

Reachability is a separate question again. A public address does not make unsolicited traffic arrive, because the route, the firewall and the listener each get a vote, and removing NAT removes one filter rather than all of them. Decide which of those three the tunnel was standing in for, if any.

What the overlay still supplies

An overlay keeps earning its place in three situations. Remote users may need a specific set of routes rather than one application, two sites may need a private reachability agreement, and operators may want addressing that does not change when the access provider does. None of the three is about the shortage of IPv4 addresses.

Global addresses do not make that maintenance-free. A tidy inner plan does not keep the outer endpoint answering after the provider changes it, and authentication, reconnection and name updates still need an owner. Decide how those recover before anything is switched off.

Walk the service that becomes public

Start at the host and list what is actually listening, because the application you approved is rarely the only thing on the box. ss -lntup prints every TCP and UDP listener with its bind address and adds the owning process where your privileges allow it, which shows at a glance whether a management interface sits on a wildcard address or on loopback only. Repeat it as ss -6 -lntup if your stack keeps IPv6 sockets separate.

Then classify each line by audience. An application port carrying its own authentication and transport security may be fine on a public address, while an administrative interface, a metrics endpoint and a database port usually are not. One approved application is a judgement about that application alone, never permission to expose every service sharing the host. The bind address on each line tells you whether the exposure already exists or would be created by the change you are planning.

Two tests, then decide what to switch off

Before removing a layer, answer two questions on paper. First, does the requirement need private routing, meaning reachability that a public address does not imply and the access provider does not offer? Second, does it need a protection boundary, meaning encryption and authentication on a flow that would otherwise cross an untrusted path in the clear? If both answers are no for that service, the tunnel is a candidate for removal; if either is yes, it stays.

Run the same test over IPv4 and IPv6 separately on a dual-stack client, because protected IPv4 traffic describes nothing about the IPv6 path. A global IPv6 address in a status page is not evidence of a leak, and a missing one is not evidence of protection. Switch off only the services where both answers were written down and are still no, and note in the change record which question decided it.