Q: Have you ever disabled IPv6 for privacy (to prevent IP leaks)?
What are your experiences?
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!
Q: Have you ever disabled IPv6 for privacy (to prevent IP leaks)?
What are your experiences?
I disabled IPv6 too completely in an attempt to prevent privacy leaks.
My killswitch toggle broke as a result of the resulting unpredictable routing table.
Modern Windows is now IPv6-first, even if IPv6 is never used!
If IPv6 is completely disabled, Windows loses its fallback path and NCSI panics.
netsh interface ipv6 set teredo disabled
netsh interface ipv6 set 6to4 disabled (deprecated on my Windows 10 Pro box)
netsh interface ipv6 set isatap disabled (deprecated on my Windows 10 Pro box)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xFF /f
Disabling IPv6 caused my killswitch to stop working because after IPv6 was disabled:
a. Windows lost its fallback path
b. NCSI panics when the default route disappears
c. VPN routing becomes unstable
d. My killswitch toggle triggers route thrashing
Restoring IPv6 was a long sequence of steps because settings had changed
so I won't describe the restoral process unless someone wants to know it.
Apparently the correct way to disable IPv6, for privacy, is this sequence.
1. Modify the registry
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /t REG_DWORD /d 0x20 /f
2. Reset IPv4 and IPv6 stacks
netsh int ip reset
netsh int ipv6 reset
3. Reboot
shutdown /r /t 0
4. Verify
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents
Should show 0x20, which...
a. Disables IPv6 on all non-tunnel interfaces
b. Prevents IPv6 leaks
c. Prevents IPv6 DNS
d. Prevents IPv6 autoconfig
e. Prevents IPv6 routing
f. Keeps NCSI happy
g. Keeps Windows routing stable
h. And which keeps my recently modified killswitch toggle stable. :)
As far as I know, IPv6 leaks will not be possible after this because with 0x20:
a. IPv6 addresses will not be assigned
b. IPv6 DNS will not be used
c. IPv6 routes will not exist
d. IPv6 traffic cannot leak
e. IPv6 fallback remains internally available for NCSI
For privacy, I'm about to run that sequence above, but in case others
are ahead of me, I'd like to ask this question before I take the leap.
Q: Have you ever disabled IPv6 for privacy (to prevent IP leaks)?
What are your experiences?
Maria Sophia wrote:
I think everyone will benefit from knowing more about RFC 8981
implementation on their Windows box to rotate their temporary IPv6 address!
Digging more into what the heck RF8981 is and which is a better method
to protect privacy (rotate IPv6 temporary addresses or disable IPv6),
I think this is a fascinating subject that everyone needs to know about.
With regard to IPv6, I think it's a good idea if everyone runs this
while on VPN to ensure that the VPN is actually routing IPv6 correctly.
netsh interface ipv6 show route
Likewise for DNS verification
nslookup -type=AAAA google.com
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.
I may be wrong about this, but while most routers support IPv6, if the
router is old, apparently privacy extensions may apparently do nothing.
The big one is that I use free VPNs only, so the VPN must tunnel IPv6 for
RFC 8981 to work, I think. Otherwise, IPv6 traffic goes outside the VPN.
Unfortunately, I learned the hard way today that Windows prefers IPv6 over IPv4, so if IPv6 is enabled:
a. Windows will use IPv6 first
b. Which means web browsers will use IPv6 first
c. And that DNS will return IPv6 first
d. So our VPN must handle IPv6 correctly
Because, if it doesn't, we unknowingly leak like a sieve.
Again I must stress that I never even thought about IPv6
until today, and I never heard of RFC 8981 until just now.
So everything I say can be wrong (and likely is wrong).
However, it's a great discussion topic because all of us need
to be aware that Windows prefers IPv6 so it's here to stay.
Hence it behooves us all to learn more about how to protect
ourselves from privacy leaks due to IPv6 differences with IPv4.
Has anyone else used RFC8981 privacy extensions or disabled IPv6?
What is your experience?
Maria Sophia wrote:
I think everyone will benefit from knowing more about RFC 8981
implementation on their Windows box to rotate their temporary IPv6 address!
Digging more into what the heck RF8981 is and which is a better method
to protect privacy (rotate IPv6 temporary addresses or disable IPv6),
I think this is a fascinating subject that everyone needs to know about.
With regard to IPv6, I think it's a good idea if everyone runs this
while on VPN to ensure that the VPN is actually routing IPv6 correctly.
netsh interface ipv6 show route
Likewise for DNS verification
nslookup -type=AAAA google.com
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.
I may be wrong about this, but while most routers support IPv6, if the
router is old, apparently privacy extensions may apparently do nothing.
The big one is that I use free VPNs only, so the VPN must tunnel IPv6 for
RFC 8981 to work, I think. Otherwise, IPv6 traffic goes outside the VPN.
Unfortunately, I learned the hard way today that Windows prefers IPv6 over IPv4, so if IPv6 is enabled:
a. Windows will use IPv6 first
b. Which means web browsers will use IPv6 first
c. And that DNS will return IPv6 first
d. So our VPN must handle IPv6 correctly
Because, if it doesn't, we unknowingly leak like a sieve.
Again I must stress that I never even thought about IPv6
until today, and I never heard of RFC 8981 until just now.
So everything I say can be wrong (and likely is wrong).
However, it's a great discussion topic because all of us need
to be aware that Windows prefers IPv6 so it's here to stay.
Hence it behooves us all to learn more about how to protect
ourselves from privacy leaks due to IPv6 differences with IPv4.
Has anyone else used RFC8981 privacy extensions or disabled IPv6?
What is your experience?
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: | 12 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 129:57:38 |
| Calls: | 220 |
| Files: | 21,513 |
| Messages: | 83,383 |