On 18/07/2026 18:42, Maria Sophia wrote:
Brian Gregory wrote:
Q: Have you ever disabled IPv6 for privacy (to prevent IP leaks)?
ÿÿÿÿ What are your experiences?
No. I know how to enable and use the RFC 8981 IPv6 privacy extensions.
Thank you for that suggestion of comparing the two different methods:
ÿ 1. Enable and use the RFC 8981 IPv6 privacy extensions
ÿ 2. versus partially disabling Windows Tcpip6\Parameters (0x20)
Your experience, and that of others, should they volunteer to help out,
is invaluable because there is no escaping that IPv6 is part of Windows.
Hence, we all have to consider how to protect our IPv6 privacy now.
To be perfectly honest, I know almost nothing about IPv6, simply
because I've never used it, never needed to use it and don't want it.
The only reason I care about IPv6 is to prevent IP leaks from something
I know nothing about, which is why I wiped it out completely today.
But that caused the routing table to be unpredictable, so let's compare
the two methods for what matters to each of us on our Windows boxes.
Q: Specifically, is it better to partially disable IPv6 (0x20), or to
ÿÿÿ leave IPv6 enabled & rely on RFC 8981 privacy extensions instead?
A: ???
Knowing absolutely nothing about RF8981, I needed to look it up first.
ÿ <https://www.rfc-editor.org/rfc/rfc8981>
ÿ RFC 8981 defines IPv6 privacy extensions, which make IPv6 addresses
ÿ rotate frequently so websites cannot track us by stable IPv6 address.
ÿ It does not hide the IPv6 prefix (which still reveals the ISP &
region),
ÿ but it hides the interface identifier, which is the part that could
ÿ otherwise be tied to the device
Hence, at first inspection, this seems to be the one-line difference:
1. RFC 8981 rotates IPv6 addresses frequently to prevent tracking.
2. Tcpip6\Parameters (0x20) disables IPv6 on all LAN/Wi-Fi interfaces.
Knowing nothing about each before today, is this a reasonable comparison?
1. RFC 8981
ÿÿÿ a. IPv6 stays enabled
ÿÿÿ b. IPv6 addresses rotate
ÿÿÿ c. IPv6 still leaks if VPN doesn't tunnel it
ÿÿÿ d. Using RFC 8981 IPv6 privacy extensions requires understanding IPv6
ÿÿÿ e. Routing becomes more complex
ÿÿÿ f. The kill switch must handle IPv6 routes too
2. Partially disabling IPv6 with Windows Tcpip6\Parameters (0x20)
ÿÿÿ a. IPv6 disabled on interfaces
ÿÿÿ b. No IPv6 leaks
ÿÿÿ c. No IPv6 routing
ÿÿÿ d. No IPv6 DNS
ÿÿÿ e. Windows routing stays stable
ÿÿÿ f. Kill switch works as designed
ÿÿÿ g. No need to understand IPv6
In summary, RFC 8981 is powerful, and, for most people, I think that
may be
the right solution, but using it still has some privacy implications
(such as the ISP & region are still revealed even as the ID is not).
Partially disabling IPv6 with Windows Tcpip6\Parameters (0x20) is more
brutal, and it negates any use of IPv6, but it keeps my current
LiquidVPN-based "dumb" killswitch working without modifications.
Having never even heard of RFC 8981 until just now, anything I said
above can be wrong (and likely is), but I do thank you for suggesting it.
I think everyone will benefit from knowing more about RFC 8981
implementation on their Windows box to rotate their temporary IPv6
address!
IP leak is vague name for the privacy problems with IPv6.
The source IP of an outgoing connection ALWAYS leaks. You couldn't get
any reply back if you kept your IP address secret.
However with IPv6 the problem is that each device on your LAN has, at
any point in time, it's own IPv6 address. So with IPv6 things you
connect to can potentially tell which of your devices connected, where
as with IPv4 all connections appear to come from your single IPv4
address, so determining which one the connection came from is either not
so straightforward, or even impossible if your devices don't give away
their identity in any other way (such as in their http headers).
Basically what RFC8981 does, when a device implements it (it's
implemented on each device, not in your router or gateway), is to change
the IPv6 address a device uses to make outgoing connections at regular intervals. Typically it changes once every 24 hours. The device also has another IPv6 address that doesn't change, which can be used for incoming connections or local connections, which can be useful in some situations.
I'm not paranoid about this kind of thing so generally I just make sure
it is enabled and leave it as every 24 hours. It is enabled by default
in Windows 10 and 11 for instance. But the situation varies with other
OSs. For instance I had to enable it on my Raspberry Pi web server if I wanted it on there too.
Maria Sophia wrote:
Digging into the results, it appears that IPv6 has TWO types of addresses
i. Stable IPv6 address which identifies the device
ii. Temporary IPv6 address which rotates for privacy
RFC 8981 protects the temporary address.
The stable address still exists unless we configure otherwise.
ISP assigns an IPv6 prefix, so even with privacy extensions:
a. Our ISP-assigned prefix reveals our region
b. Our ISP-assigned prefix reveals our provider
c. Our ISP-assigned prefix may be stable for days or weeks
Apparently, the RFC 8981 privacy extensions do not hide this.
My WISP would be easily noticed in that information I'd think.
Holy shit!. This is profound... topology determines privacy!A Wi-Fi bridge???
Chrome, Firefox, Edge, whatever... all are IPv6-first nowadays.
Yet those browsers can only leak IPv6 if the client has a global IPv6 address. A bridged router ensures it never does.
Modern web browsers can directly use our PCs IPv6 address such that
a. A PC web browser using its own Wi-Fi NIC can leak IPv6, but...
b. A PC web browser using a router-as-Wi-Fi bridge cannot leak IPv6!
Jesus Christ. This is really big in terms of instant IPV6 privacy!
The IPV6 privacy comes from architecture, not configuration.
I only just now realized this stupendous revelation after digging through
the wreckage, that if we simply pair our PC RJ45 with a router acting as a wireless bridge (instead of using the internal wi-fi card), I think we may instantly solve the IPV6 privacy problem without the complexity of 0x20 DisabledComponents.
By using RJ45 for Wi-Fi, the PC no longer has a Wi-Fi IPv6 stack to leak!
The PC web browser cannot leak IPv6 because the browser cannot see IPv6.
It sees only IPv4, Ethernet and fe80:: (local-only, which is unusable).
*There is nothing for the PC web browser to leak* .
Even taking the specific case of torrrenting over VPN leaking an IPv6 address, the leak happens when the PC has a global IPv6 address coupled
with a free VPN that does not tunnel IPv6, tied to a torrent client that
uses IPv6 anyway.
In that scenario, the real IPv6 address escapes outside the VPN tunnel.
The *source* of those leaks, interestingly, is the internal Wi-Fi NIC.
Wi-Fi interfaces in Windows automatically generate:
a. global IPv6 addresses
b. temporary IPv6 privacy addresses
c. IPv6 DNS queries
d. IPv6 fallback routes
e. IPv6 autoconfiguration
f. IPv6 neighbor discovery
g. IPv6 tunnels (Teredo, ISATAP, 6to4)
Such that, even if we think we're not using IPv6, Windows is.
With an Ethernet-connected-router acting as a wireless bridge, the PC
thinks it's using Ethernet only, and Ethernet IPv6 is:
a. link-local only (fe80::)
b. not routable
c. not global
d. not visible outside our LAN
e. not used by VPNs
f. not used by torrent clients
g. not used by browsers
Hence, as far as I know, a link-local IPv6 address cannot leak.
And, in my case, the circa 2007 DD-WRT router (WNR834Bv2) is too old to support real IPv6 so it is physically incapable of participating in IPv6.
No global IPv6 on the client means no IPv6 leak.
A bridge guarantees exactly that.
What's philosophically brilliant is that even with a fully intact IPv6
stack, and even with a modern router acting as a wireless bridge, the same privacy advantage still holds.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 10 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 153:50:44 |
| Calls: | 220 |
| Files: | 21,513 |
| Messages: | 85,727 |