Why Your IPv6 Address Changes While the VPN Stays Up

Two screenshots an hour apart show different IPv6 source addresses, and the obvious reading is that the tunnel leaked or reconnected. Usually neither happened. The host is using temporary addresses, an operating system privacy feature that rotates the interface identifier on a timer. The comparison looked conclusive only because it assumed a field that was never stable.

What a temporary address actually rotates

A temporary address is built from the interface prefix plus an identifier the host changes, and it carries preferred and valid lifetimes. Before the valid lifetime runs out the host generates a replacement, so two connections can legitimately leave from different sources. The link-local address and the prefix itself stay put, which is how the network still recognises the machine.

Nothing in that rotation makes an account, a cookie or a browsing pattern anonymous. A site that wants to recognise you has cookies, logins and fingerprints, and a changing source address barely registers against those. Rotation changes one field in the packet header, and that field was never the only identifier on the path.

The website sees one address, the host holds several

A server records the source of the request it received, nothing more. The host may hold several addresses with different scopes and lifetimes, and which one wins depends on the address selection rules and on the destination. Reading the website value as the machine address is where this confusion starts. One host can look like two machines to two sites at the same moment, simply because each connection selected a different address.

Look at the interface during a test with ip -6 addr show dev eth0: several addresses with their lifetimes mean rotation is present by design. Then ask the kernel which route it would use with ip -6 route get 2001:db8:10::5, which prints the device and the preferred source for that destination.

Compare prefix, interface and route, not the string

For VPN testing the question is whether the packet left through the tunnel, which is a routing and policy question. The source address is a weak proxy for it: a rotating address on the tunnel interface is still on the tunnel. A tunnel that reconnects usually shifts the prefix or the device instead, and those changes are visible without reading the full address.

So compare the selected route, the interface the packet left by, and the prefix it carried. Those three stay stable enough between runs, and each one means something different when it changes.

A change matters when the prefix changes, when the interface changes, or when the route to the destination stops using the tunnel. A change only in the interface identifier, with the same prefix and the same device, is privacy behaviour working as intended. If only the identifier moved, the test measured the privacy timer rather than coverage. Write down which of the three moved before you blame the tunnel.

Do not disable IPv6 to make screenshots agree

Turning IPv6 off makes repeated tests match, and it also removes a whole address family from the network your tunnel is meant to cover. When the policy is to carry IPv6, disabling it hides a coverage gap instead of closing one.

If the policy is to block IPv6 until it is supported, block it deliberately and write the decision down. The next administrator needs to see the difference between a documented block and a disabled stack.

What to record, and what one test can prove

Record the prefix, the interface name, the selected route, the destination and the timestamp, with the full address beside them. The temporary address specification explains the lifetimes that drive rotation, which is why the full address is the least stable field in the note. Two of the three stable fields agreeing across runs is stronger evidence than any single address match.

A single test is one observation of one request. The note is what turns the next observation into a comparison. Keep both, and the next disagreement costs a glance instead of an afternoon.