Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.microsoft.windows > #3439 > unrolled thread

Have you ever disabled IPv6 for privacy (to prevent IP leaks)?

Back to article view | Back to alt.comp.microsoft.windows

Contents

  Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-18 12:47 -0400
    Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2026-07-18 17:55 +0100
      Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-18 13:42 -0400
        Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-18 14:00 -0400
          Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Hank Rogers <Hank@nospam.invalid> - 2026-07-18 18:04 -0500
            Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-26 17:13 -0700
          Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Hank Rogers <Hank@nospam.invalid> - 2026-07-18 18:26 -0500
            Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-20 01:57 -0400
              Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2026-07-20 10:32 +0100
                Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 13:46 -0400
                  Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 13:52 -0400
          Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? "Carlos E. R." <robin_listas@es.invalid> - 2026-07-19 21:07 +0200
        Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2026-07-18 19:13 +0100
          Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Hank Rogers <Hank@nospam.invalid> - 2026-07-18 18:49 -0500
            Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-19 17:47 -0400
    Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Paul <nospam@needed.invalid> - 2026-07-18 15:26 -0400
      Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-20 01:15 -0400
        Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-20 01:18 -0400
          Re: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? Maria Sophia <mariasophia@comprehension.com> - 2026-07-26 16:56 -0700

#3439 — Have you ever disabled IPv6 for privacy (to prevent IP leaks)?

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?
-- 
Usenet allows people with shared interests to discuss topics of import.

[toc] | [next] | [standalone]

#3440

On 18/07/2026 17:47, Maria Sophia 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.

-- 
Brian Gregory (in England).

[toc] | [prev] | [next] | [standalone]

#3442

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!
-- 
Usenet allows purposefully helpful people to pool their experiences.

[toc] | [prev] | [next] | [standalone]

#3443

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?
-- 
Usenet is where you can often find people who know much more than you do.

[toc] | [prev] | [next] | [standalone]

#3447

Maria Sophia wrote on 7/18/2026 1:00 PM:
> 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?
> 

Thanks, Mary.  Now we all know how to disable ipv6 on our computers.  It 
is evil and spies on us.  I am real paranoid just like you. Many thanks

[toc] | [prev] | [next] | [standalone]

#3464

Maria Sophia wrote:
> These are the commands I add to every one of hundreds of free config files.
> Notice the DNS-related commands are brand new, to keep DNS inside the tunnel.

Here's a script that others can use that deletes the existing directives.

  :: vpnclean.bat
  ::  Cleans OpenVPN config files of all directives located after </key>.
  :: ---------------------------------------------------------------------
  :: v1p0 20260725
  :: ---------------------------------------------------------------------
  @echo off
  :: Point to the folder containing any number of openvpn config files 
  set "folder=C:\data\vpn\config"
  :: Remove all directives after </key> in every openvpn config file found
  for %%F in ("%folder%\*.ovpn") do (
      powershell -NoLogo -NoProfile -Command ^
          "$content = Get-Content '%%F';" ^
          "$idx = ($content | Select-String '</key>').LineNumber;" ^
          "if ($idx) { $new = $content[0..($idx-1)]; Set-Content -Path '%%F' -Value $new -Encoding UTF8; Write-Host 'Cleaned: %%~nxF' } else { Write-Host 'Skipped (no </key>): %%~nxF' }"
  )
  echo Done.
  :: end of vpnclean.bat

And then another script that adds the new directives to the existing files.

  :: vpnappend.bat
  :: -----------------------------------------------------------------
  :: v1p0 20260725
  ::  Appends OpenVPN config directies to any number of openvpn files.
  :: -----------------------------------------------------------------
  :: Point to the folder containing any number of openvpn config files 
  @echo off
  set "folder=C:\data\vpn\config"
  :: Point to the file containing the verbatim openvpn directives
  set "block=C:\data\vpn\config\added_options.txt"
  :: Append the file above to every openvpn config file in the folder above
  for %%F in ("%folder%\*.ovpn") do (
      powershell -NoLogo -NoProfile -Command ^
          "Add-Content -Path '%%F' -Value \"`r`n# --- Standard Options ---`r`n\";" ^
          "Add-Content -Path '%%F' -Value (Get-Content '%block%');" ^
          "Write-Host 'Appended options to: %%~nxF'"
  )
    echo Done.
   :: end of vpnappend.bat
-- 
It takes intelligence & effort to get what people pay for, for free.

[toc] | [prev] | [next] | [standalone]

#3448

Maria Sophia wrote on 7/18/2026 1:00 PM:
> 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?
> 

THANKS for teaching us Mary.  It must be hard since you yourself only 
learned this shit today.  It takes real balls to run with something you 
know so very little about.  Don Quixote would clap and cheer you on!

This is indeed more proof that you are a true genious as you have 
claimed here so often

I believe you are even smarter than Donald Trump!

[toc] | [prev] | [next] | [standalone]

#3458

Holy shit!. This is profound... topology determines privacy!

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.

This is a deep lesson to be learned when it comes to IPv6 Wi-Fi privacy.

Even if we use a modern router as a Wi-Fi bridge, our PC will not leak IPv6
(even if our PC's IPv6 stack is fully enabled and untouched) because the
router becomes the IPv6 endpoint, not the PC.

The PC instantly becomes an IPv4-only box behind the router's decisions.
This is the surprisingly elegant architectural magic of bridging.

We achieve privacy not by fighting complexity, but by employing simplicity.
-- 
Windows IPv6 leaks vanish when the PC stops participating in IPv6 routing.

[toc] | [prev] | [next] | [standalone]

#3459

On 20/07/2026 06:57, Maria Sophia wrote:
> Holy shit!. This is profound... topology determines privacy!
> 
> 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.
A Wi-Fi bridge???
This isn't one of that idiot Rob Braxman's brain farts is it?

If you don't have a global IPv6 YOU ARE NOT USING IPv6 TO ACCESS THE 
INTERNET. You have disabled IPv6.
THERE IS NO BRIDGE - whatever you think that is!?

-- 
Brian Gregory (in England).

[toc] | [prev] | [next] | [standalone]

#3460

Brian Gregory wrote:
>> 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.
> A Wi-Fi bridge???
> This isn't one of that idiot Rob Braxman's brain farts is it?
> 
> If you don't have a global IPv6 YOU ARE NOT USING IPv6 TO ACCESS THE 
> INTERNET. You have disabled IPv6.
> THERE IS NO BRIDGE - whatever you think that is!?

You are right. I am wrong. Sorry I didn't realize it sooner. 
Thank you for correcting my mistakes. I appreciate it.

I only want to help others, and to learn what to do (and what not to do).

I never disagree with anyone stating a logically defensible viewpoint, and 
I won't disagree with Brian Gregory in his statement because he's right 
that a bridge actually does not confer IPv6 protection on a computer. 

I was wrong about that.
I set up the bridge repeater to get Wi-Fi back (via Ethernet between
the PC and the spare router) so that I could get back onto the Internet.

The bridge is simply my workaround to having destroyed network Wi-Fi.

I found out, belatedly, that what actually killed my Wi-Fi network 
permanently was the *combination* of 0xFF and pnputil /force such that the 
only way to recover is to rebuild Windows (which I haven't done yet).

Looking back at my copypasta ad hoc logs, this is what killed me such 
that I will never be able to use Wi-Fi or VPN again without rebuilding.
 a. Because I have no network icon in the taskbar notification area, and, 
 b. ms-settings:network Network & Internet crashes within seconds every time.

So that others don't repeat my disaster, this is what *not* to do.

1. Wipe out IPv6 (I should have used either 0x20 or 0x01 but not FF).
   reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /t REG_DWORD /d 0xFF /f
2. Enumerate the Wi-Fi device 
    pnputil /enum-drivers
     Qualcomm Atheros 802.11 a|b|g|n Dualband Wireless Network Module  
     Driver Name: netathrx.inf  
     Instance ID:
     PCI\VEN_168C&DEV_002A&SUBSYS_1000168C&REV_01\4&1a388ce3&0&0038
3. Remove the Wi-Fi device (this, I never should have done!)
    pnputil /remove-device "PCI\VEN_168C&DEV_002A&SUBSYS_1000168C&REV_01\4&1a388ce3&0&0038"
4. Uninstall the driver package (the force is what did all the damage!)
    pnputil /delete-driver netathrx.inf /uninstall /force
5. IPv6 stack destruction (I should have used hex 20 or 01 instead!)
   reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /d 0xFF
6. Resetting both IPv4 and IPv6 stacks
    netsh int ip reset
    netsh int ipv6 reset
7. Rebooting with missing routing & missing Wi-Fi driver metadata
    That combination forced Windows to purge dependent networking components, 
    including:
     a. NetworkUX
     b. OOBENetwork packages
     c. NetworkConnectionFlow
     d. immersivecontrolpanel dependencies
     e. ShellExperienceHost networking hooks
     f. Edge legacy system package
     g. CBS servicing metadata
     h. RPC endpoint mapper entries
 Because a dir of dir C:\Windows\SystemApps\Microsoft.Wind*
 now shows multiple SystemApps folders vanished, not just NetworkUX.	 

Luckily, Ethernet still works, so a router connected to the PC RJ45
allows bridging to the SOHO router access point, so I'm on the net.

But ms-settings:network crashes within seconds every time it's run.
The fatal combined steps are documented so that others learn from my mistake.
-- 
Sometimes you learn what not to do only after having already done it.

[toc] | [prev] | [next] | [standalone]

#3461

Maria Sophia wrote:
> I never disagree with anyone stating a logically defensible viewpoint, and 
> I won't disagree with Brian Gregory in his statement because he's right 
> that a bridge actually does not confer IPv6 protection on a computer. 
> 
> I was wrong about that.
> I set up the bridge repeater to get Wi-Fi back (via Ethernet between
> the PC and the spare router) so that I could get back onto the Internet.

While I was wrong, I'm on the path to enlightenment, in terms of IPv6...

To reaffirm that Brian Gregory is right, I looked it up and found out that
it was a false negative that I *thought* the wireless bridge conferred
protection from IPv6 leaks. As Brian stated emphatically, it does not!

I accidentally inferred that it did because my IPv6 does not exist.
But, it turns out, my IPv6 likely has never existed on my current router).

Below are some IPv6 leak tests I think everyone should run at least once.

We're all working together as I'll wager many of us on these ngs were as
unaware as I was that IPv6 is, by design, a privacy hole par excellence.

Reaffirming that this whole IPv6 privacy thing is new to me and that it
floored me when I found out how different it is from IPv4, to test if the
Windows or Linux or Android methods are working, these commands may help.

 1. Test external visibility
    start firefox https://test-ipv6.com (Windows) 
    firefox https://test-ipv6.com (Linux)
    xdg-open https://test-ipv6.com (Android Termux)
 2. Check external reachability
    ping -6 google.com
 3. Identify the local interface configuration
    a. ipconfig (Windows)
    b. ifconfig / ip a (Linux)
    c. Termux > pkg install iproute2 > ip a (Android)
    d. Termux > pkg install net-tools > ifconfig (Android
 4. Test DNS resolution
    nslookup -type=AAAA google.com (Windows)
    dig AAAA google.com (Linux, Android Termux)
 5. Test IPv6 routing table
    route print -6 (Windows)
    ip -6 route (Linux/Android Termux)
 6. Test IPv6 WebRTC leaks
    firefox https://browserleaks.com/webrtc
    firefox https://ipleak.net	 
 7. Test IPv6 prefix delegation
    dhclient -6 -v (Linux/Android Termux)
 8. Test for VPN leaks
    firefox https://ipleak.net  
    firefox https://browserleaks.com/ip
 9. Router setup
    Netgear > Advanced > Advanced Setup > IPv6 > Internet Connection Type
     Disabled (IPv6 is completely off)
     Auto Detect (Router tries to detect IPv6 from your ISP)
     6to4 Tunnel (Legacy IPv6-over-IPv4 tunneling)
     Pass Through (Router passes IPv6 directly to LAN devices)
     Fixed (Manual IPv6 configuration)
     DHCP (Used when the ISP hands out IPv6 via DHCPv6)
     PPPoE (Used by DSL providers)
     Auto Config (Router uses SLAAC (stateless autoconfiguration)
     6rd Tunnel (An IPv6-over-IPv4 method used by some ISPs)
     Dual-Stack Lite (Used by ISPs that provide IPv6 but tunnel IPv4.\)
     v6plus (Japan-specific IPv6 service)
     
For example
 a. No IPv6 addresses were detected by https://test-ipv6.com
 b. ping -6 google.com fails 
 c. My Windows host only has link-local IPv6 (fe80::...)
 d. I have no global IPv6 (2000::/3)
 e. I have no IPv6 default gateway
 f. I have no IPv6 DNS
 g. All IPv6-only sites timed out

Specifically for  https://test-ipv6.com my IPv6 Firefox score was 0/10 
 Test with IPv4 DNS record = ok (2.421s) using ipv4
 Test with IPv6 DNS record = timeout (5.611s)
 Test with Dual Stack DNS record = ok (2.821s) using ipv4
 Test for Dual Stack DNS and large packet = ok (1.230s) using ipv4
 Test IPv6 large packet = bad (3.898s)
 Test if your ISP's DNS server uses IPv6 = ok (1.293) using ipv4
 Find IPv4 Service Provider = ok (2.300s) using ipv4 
 Find IPv6 Service Provider = bad (3.815s)	 

So, it turns out, I never had an IPv6 leak in the first place.
Because, if IPv6 doesn't exist past the router, it can't leak.

May I ask others out there what your IPv6 results were with Firefox?
-- 
What we can learn from everyone is more than we can learn ourselves.

[toc] | [prev] | [next] | [standalone]

#3450

On 2026-07-18 20:00, Maria Sophia wrote:
> 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.

The prefix identifies your router, and doesn't change ever. Unless you 
have an stupid ISP which rotates it. This is intentional so that 
everybody takes advantage of the features permitted by this.

In practice, this is irrelevant. With IPv4 you are also identified, even 
if the IP rotates frequently. Your ISP have a list of what IP is 
assigned to who during what interval, so if the police asks, they can 
locate you fast.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#3444

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.

-- 
Brian Gregory (in England).

[toc] | [prev] | [next] | [standalone]

#3449

Brian Gregory wrote on 7/18/2026 1:13 PM:
> 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.
> 

Thanks Brian.  Please help Maria.  She is VERY paranoid and slightly 
retarded, so look out for her if you can.

[toc] | [prev] | [next] | [standalone]

#3451

Brian Gregory wrote on 7/18/2026 1:13 PM:
> 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.


Hi Brian Gregory,

I think we're each discussing different aspects of "privacy", both of 
which are valid.

You bring up good points about rotation where I need to first explain I
never thought about IPv6 until I tried to plug leaks, if any, when
torrenting on VPN.

Specifically I thank you for introducing RFC 8981 to me (and others).
Given that, you clearly know far more than I do about IPV6 privacy.

My concern isn't IPv6 privacy in the general sense. My concern is mainly in
the specific case where a VPN tunnels only IPv4, but Windows still prefers
IPv6.

In that situation, a BitTorrent client (or any app) can make IPv6
connections outside the VPN tunnel, even if the user thinks they're
protected.

As far as I can tell, while RFC 8981 is great, RFC 8981 doesn't solve that
problem. It only rotates the IPv6 interface identifier; it does not prevent
IPv6 traffic from bypassing the VPN.

So the comparison in this case isn't so much IPv6 privacy extensions vs.
disabling IPv6 but more likely the question for all of us to ask:
 Q: Do we want IPv6 to exist at all if our VPN doesn't support it?
 A: ??? 

For example, I use thousands of free openvpn config files found on the net
(mostly for basic IP obfuscation, not so much for activity protection).

If the VPN is IPv4-only, my thought process was that the only reliable way
to prevent leaks is to disable IPv6 on the interfaces the VPN doesn't
tunnel.

I haven't posted in a day because I screwed up my network given Windows 10
is IPv6-first, so disabling IPv6 incorrectly can (and did!) break routing,
NCSI, and killswitch logic, even as using DisabledComponents = 0x20 is
intended to avoid those issues while still preventing IPv6 leaks.

So in this specific threat model (VPN + BitTorrent + IPv4-only tunnel), RFC
8981 is interesting, but not a solution. The solution I'm asking about here
is whether anyone has been successful in preventing IPv6 traffic from ever
leaving the machine outside the VPN.

Still, the RFC8981 information is news to me, and very interesting.
Thank you for your insight on how you protect yourself when using IPv6.
-- 
Usenet is where you can often find people who know much more than you do.
	.

[toc] | [prev] | [next] | [standalone]

#3445

On Sat, 7/18/2026 12:47 PM, Maria Sophia wrote:
> 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?
> 

For the average user in this group, doing this is just asking for trouble.

Make a backup first, OK ?

*******

There's no IPV6 in the room, and I didn't have to do a thing.
And it stays that way, as long as there is no Teredo Tunneling.

https://whatismyipaddress.com/

   My IP Address is:

   IPv4: ? 123.123.123.123       # It's some working value like that

   IPv6: ? Not detected	         # Strangely, this does not work <snicker>
                                 # OS is unmodified.

  Paul

[toc] | [prev] | [next] | [standalone]

#3456

Paul wrote:
>> Q: Have you ever disabled IPv6 for privacy (to prevent IP leaks)? 
>>    What are your experiences?
>> 
> 
> For the average user in this group, doing this is just asking for trouble.
> 
> Make a backup first, OK ?
> 
> *******
> 
> There's no IPV6 in the room, and I didn't have to do a thing.
> And it stays that way, as long as there is no Teredo Tunneling.
> 
> https://whatismyipaddress.com/
> 
>    My IP Address is:
> 
>    IPv4: ? 123.123.123.123       # It's some working value like that
> 
>    IPv6: ? Not detected	         # Strangely, this does not work <snicker>
>                                  # OS is unmodified.
> 
>   Paul


Thanks for the caution where you're absolutely right that disabling IPv6
like I did was just asking for trouble.

In my case, the problem wasn't IPv6 itself, but the way I disabled it. 

Using DisabledComponents = 0xFF completely removed IPv6 routing, IPv6 DNS,
IPv6 fallback paths, and all the internal IPv6 logic Windows relies on. 

But Windows is IPv6-first, even when IPv6 isn't used externally, so
removing it entirely caused NCSI to panic, my routing table to thrash, and
my killswitch toggle to break.

Your setup works because your system still has enough IPv6 internally to
keep Windows stable, even though your ISP doesn't provide IPv6 and your
external tests show "Not detected." 

The important lesson from my mistakes was that the safer method of removing
IPv6 on Windows is 0x20 instead of 0xFF. It keeps IPv6 available internally
for Windows, but disables it externally so privacy leaks aren't possible. 

It's not something most users need, but for people who do care about IPv6
leaks over VPN while torrenting, it's a way to avoid the trap I fell into.

And yes I absolutely agree with you that anyone experimenting with IPv6
settings should make a backup first, me included. I wish I had. 

But I was too confident when I ran these two seemingly simple commands:
 1. This was dangerous... 
    pnputil /remove-device "PCI\VEN_168C&DEV_002A..."
 2. But this was catastrophic... 
    pnputil /delete-driver netathrx.inf /uninstall /force

Thanks again for the sanity check!
Rufus and MCT are clearly the only solution left to fix it.
-- 
Understanding arrives long after the moment that needed it.

[toc] | [prev] | [next] | [standalone]

#3457

Maria Sophia wrote:
>  1. This was dangerous... 
>     pnputil /remove-device "PCI\VEN_168C&DEV_002A..."
>  2. But this was catastrophic... 
>     pnputil /delete-driver netathrx.inf /uninstall /force

When Wi-Fi networking failed, the one thing too simple to break didn't.
 *Ethernet*

I accidentally learned something from picking through the 0xFF IPv6 rubble.
I broke IPv6 so thoroughly that I accidentally resolved a privacy problem!
	.
Apparently my current setup (router as bridge) cannot leak IPv6.
Because the PC's Wi-Fi IPv6 stack is dead.

And because the bridge is acting as a firewall between the PC & IPv6.

The PC literally cannot form a usable IPv6 address on Wi-Fi anymore.
The PC is now using Ethernet where Ethernet IPv6 is simple.
 a. Ethernet has link-local only (fe80::)
 b. no global IPv6 and no SLAAC
 c. no DHCPv6 and no privacy extensions
 d. no tunnels and no fallback paths

When I destroyed IPv6 with 
 a. DisabledComponents = 0xFF 
 b. netsh int ipv6 reset 
and then when I removed the Wi-Fi driver with:
 c. pnputil /delete-driver netathrx.inf /uninstall /force

Windows lost:
 a. its IPv6 routing and IPv6 metadata
 b. its IPv6 fallback path and IPv6 NCSI logic
 c. its Wi-Fi IPv6 interface and its Wi-Fi IPv6 neighbor table
 d. its Wi-Fi IPv6 autoconfiguration and its Wi-Fi IPv6 DNS behavior
 e. its Wi-Fi IPv6 tunnels and its Wi-Fi IPv6 privacy extensions

But when I plugged in the router acting as a wireless repeater bridge, 
the router absorbs all the IPv6 complexity, and the router doesn't even
handle ipv6 being a circa 2007 wnr834bv2 ... running ddwrt as a bridge.

Ethernet survived because it depends on almost nothing.
Ethernet is essentially just a cable and a MAC address.

Two days ago, I had no idea I was walking into the maws of a lion when I
ran those innocent pnputil commands, but what's profoundly enlightening is
that Ethernet still works even when every Wi-Fi solution is now failing.

I had no idea I was stepping into the lion's den when I ran those two
innocent commands. However, what's strangely enlightening after I look at
the mess I made is that even after the wireless world completely collapsed,
the venerable old Ethernet whisked me to safety.

Plugging an old DDWRT router into the RJ45 worked, simply because
 a. Ehernet is primitive.
 b. Ethernet is simple.
 c. Ethernet is robust.
 d. Ethernet doesn't rely on NetworkUX

Ethernet is just a cable, a MAC address and a packet.
Funny thing, there are advantages to using the router as a Wi-Fi NIC.
 a. It offloads all wireless complexity and computation to the router  
 b. It doesn't need NetworkUX, Wi-Fi metadata, wireless autoconfiguration,
    radio drivers, routing tables, fallback paths, NCSI hooks,
    or any of the fragile components I accidentally broke	.
 c. Even an old router has better radios than any PC ever did
    i. lower latency
    ii.better signal handling
    iii. no driver issues

The PC doesn't have to think anymore.
It just sends and receives packets.

Sometimes the oldest path is the one that eventually carries us home when
everything modern collapses around us from the sheer complexity of it all.
-- 
When the modern Wi-Fi world collapsed, the simplicity of Ethernet survived.

[toc] | [prev] | [next] | [standalone]

#3463

Note that there is a directive for configs that blocks IPv6 altogether.
  block-ipv6 ; block IPv6 traffic to prevent IPv6 leaks
We have to worry about DNS leaks, but there are directives for that too.
 block-outside-dns ; force DNS queries to stay inside the VPN TAP interface 
Unfortunately, specifically stating the DNS server in the tunnel failed.
  ; dhcp-option DNS 1.1.1.1 ; set primary DNS to Cloudflare inside the tunnel
  ; dhcp-option DNS 9.9.9.9 ; set secondary DNS to Quad9 for secure fallback
The volunteer VPN servers I use don't seem to accept those DNS directives.

But those directives should work on more professional OpenVPN servers.
I only use the thousands of free openvpn servers from around the world.

These are the commands I add to every one of hundreds of free config files.
Notice the DNS-related commands are brand new, to keep DNS inside the tunnel.

  auth-nocache ; prevent caching of auth credentials in memory
  auth-retry nointeract ; retry silently using stored username/password
  auth-user-pass C:\\data\\vpn\\userpass.txt ; login file path
  block-ipv6 ; block IPv6 traffic to prevent IPv6 leaks
  block-outside-dns ; force DNS queries to stay inside the VPN TAP interface 
  ; NB block-outside-dns breaks OS DNS if the VPN's DNS server is dead
  ; dhcp-option DNS 1.1.1.1 ; set primary DNS to Cloudflare inside the tunnel
  ; dhcp-option DNS 9.9.9.9 ; set secondary DNS to Quad9 for secure fallback
  connect-retry-max 20 ; increase max reconnect attempts (default=8)
  connect-retry 5 ; shorten delay between reconnect attempts
  connect-timeout 30 ; time before initial connect attempt times out
  data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC ; required by vpngate.net
  explicit-exit-notify 2 ; send disconnect notice to UDP servers
  float ; accept server IP changes during session
  hand-window 180 ; extend TLS handshake window (default=60)
  inactive 3600 ; allow long idle periods before timeout (default=off)
  ip-win32 adaptive ; choose best Windows IP/DNS routing method
  keepalive 10 60 ; ping every 10s, restart after 60s silence
  mssfix 1400 ; adjust TCP MSS to reduce fragmentation
  tun-mtu 1400 ; set tunnel MTU to avoid packet fragmentation
  ; pull-filter ignore "redirect-gateway" ; prevent server from setting gateway
  pull-filter accept "redirect-gateway" ; accept the vpn server routing changes
  pull ; accept configuration pushed by the VPN server
  replay-window 128 ; enlarge replay protection packet window
  route-delay 10 ; delay route setup to avoid race conditions
  server-poll-timeout 120 ; wait longer for server PUSH reply (default=2)
  tls-timeout 180 ; extend TLS negotiation timeout (default=60)
  verb 4 ; moderate verbosity, show key events without packet spam

During testing, on Windows, I made use of the old curlit shortcut:
 Win+R > curlit
 Which calls curlit.exe which is defined only in the Windows Registry
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\curlit.exe
  Default=C:\path-to\curlit.lnk
 Where the TARGET of that curlit.lnk shortcut does the IP check.
  Target=%comspec% /k echo "C:\data\sys\pgm\lnk\curlit.lnk $MYIP" & %Windir%\System32\curl.exe icanhazip.com
 NB: There is no command called "curlit.exe"; that's a unique reg keyword.

I tried to make it fancier with curlvpn but that errored out on Windows:
 TARGET=%comspec% /k echo "curlvpn: forcing curl through VPN TAP adapter" & %Windir%\System32\curl.exe --interface Ethernet --dns-servers 1.1.1.1,9.9.9.9 icanhazip.com
I'm sure that curl syntax would work if curl were compiled differently.
 "curlvpn: forcing curl through VPN TAP adapter"
 curl: option --dns-servers: the installed libcurl version does not support this
 curl: try 'curl --help' for more information
 
But I like my commands to work universally so I changed it to 
 Win+R > curldns
 Which calls curldns.exe which is defined only in the Windows Registry
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\curldns.exe
  Default=C:\path-to\curldns.lnk
 Where the TARGET of that curldns.lnk shortcut does the IP check.
  %comspec% /k echo "C:\data\sys\pgm\lnk\curldns.lnk $MYIP" & echo curldns & nslookup icanhazip.com & powershell -Command "Resolve-DnsName icanhazip.com" & curl icanhazip.com
 NB: There is no command called "curldns.exe"; that's just a reg keyword.

I post it here so that others, at least on Windows, can instantly replicate
this shortcut efficiency to make sure their VPN DNS remains in the tunnel.
-- 
I strive to add technical value, if possible, with every post to Usenet.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.comp.microsoft.windows

csiph-web