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

Groups > alt.comp.software.firefox > #17819 > unrolled thread

PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix

Back to article view | Back to alt.comp.software.firefox

Contents

  PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-20 02:45 -0400
    Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix "Carlos E. R." <robin_listas@es.invalid> - 2026-07-20 14:03 +0200
      Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 02:43 -0400
        Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix "Carlos E. R." <robin_listas@es.invalid> - 2026-07-21 11:18 +0200
          Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 07:36 -0400
            Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix "Carlos E. R." <robin_listas@es.invalid> - 2026-07-21 19:28 +0200
              Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 14:32 -0400
                Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Hank Rogers <Hank@nospam.invalid> - 2026-07-21 18:31 -0500
                  Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-22 15:40 -0400
                    Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-22 18:53 -0400
      Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2026-07-28 00:36 +0100
    Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix David Higton <dave@davehigton.me.uk> - 2026-07-20 20:47 +0100
      Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix "Carlos E. R." <robin_listas@es.invalid> - 2026-07-20 21:59 +0200
        Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 02:04 -0400
          Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix "Adam H. Kerman" <ahk@chinet.com> - 2026-07-21 06:37 +0000
            Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 03:23 -0400
          Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-21 07:59 +0100
            Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 04:41 -0400
              Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix "Carlos E. R." <robin_listas@es.invalid> - 2026-07-21 11:03 +0200
                Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 05:47 -0400
                  Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix "Carlos E. R." <robin_listas@es.invalid> - 2026-07-21 12:27 +0200
                    Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 14:10 -0400
            Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix "Carlos E. R." <robin_listas@es.invalid> - 2026-07-21 10:53 +0200
              Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 05:19 -0400
                Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix "Carlos E. R." <robin_listas@es.invalid> - 2026-07-21 11:30 +0200
                  Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 06:10 -0400
                Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-22 19:13 -0400
              Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-22 09:47 +0100
                Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-22 16:30 -0400
        Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2026-07-22 21:35 +0100
          Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-22 16:46 -0400
            Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2026-07-23 04:33 +0100
              Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-23 08:12 +0100
                Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-23 16:23 -0400
      Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Oregonian Haruspex <no_email@invalid.invalid> - 2026-07-25 04:58 +0000
        Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-26 14:25 -0700
    Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 01:38 -0400
      Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-21 07:51 +0100
        Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-21 03:45 -0400
          Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-22 09:37 +0100
            Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-24 11:36 -0700
    Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2026-07-22 21:32 +0100
      Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-22 16:54 -0400
        Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix agris <agris@invalid.tld> - 2026-07-22 17:05 -0700
          Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-22 23:06 -0400
            Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2026-07-23 04:50 +0100
              Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix Maria Sophia <mariasophia@comprehension.com> - 2026-07-23 16:51 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#17851

On 2026-07-21 11:47, Maria Sophia wrote:
> Carlos E. R. wrote:
>>> With IPv4 + NAT, all devices share one public address, so the ISP can't
>>> tell which device is doing what. With IPv6, each device has its own
>>> globally routable address, so any IPv6 leak identifies both the activity
>>> and the specific device.
>>
>> Ah, no. This is precisely what the RFC 8981 IPv6 privacy extensions are
>> for. The second part of the address rotates, so that nobody outside can
>> track what machine inside of the router is talking.
>>
>> The router knows, but the router is yours and you can erase the logs.
> 
> Carlos brings up a good point about RFC 8981 IPv6 privacy extensions where
> we need to distinguish between tracking over time against identifying the
> device right now because there are two parts to an IPv6 address.
>   1. The prefix (this is fixed as it does not rotate under RFC 8981)
>   2. The interface identifier (this is the part RFC 8981 rotates)
> 
> Only recently did I learn about RFC 8981 in the Windows ng but from what
> I've researched, AFAIK, RFC 8981 does not hide the device from the ISP.
>   a. Therefore, AFAIK, RFC 8981 does not prevent device attribution.
>   b. RFC8981 privacy extensions do not prevent VPN bypass.
>   c. RFC8981 privacy extensions do not prevent IPv6 leaks.
> 
> Given the prefix remains fixed, RFC 8981 cannot hide the device from the
> ISP as RFC 8981 only rotates the interface identifier half of the address.
> 
> What remains of IPv6 reveals both the subscriber and the specific device.
> Short term or long term, RFC 8981 does nothing to prevent that prefix leak.
> 
> To be clear, RFC 8981 privacy extensions are likely great, but AFAIK, they
> only prevent long-term correlation of activity across different networks.

Long and short. They know what address is talking, but they do not know 
what machine inside the house is talking. It is machine XYZW, so what? 
That tells them nothing.

Only the router owner knows, if he wants.

On the other hand, the ISP can capture all the traffic from one machine 
(not knowing what machine it is actually), and do a traffic analysis on it.

> 
> Based on my research (which we discussed in the Windows 10 newsgroup prior)
> privacy extensions rotate only interface identifiers, not prefixes.
> 
> That means, if I'm correct, that even with RFC-8981 privacy extensions...
> a. Websites see our IPv6 prefix
> b. Websites know which household the traffic comes from
> c. Websites can correlate all our temporary IPv6 addresses to that prefix
> d. Websites can still identify your home even if the IID rotates
> 

Certainly, as this is intentional and an advantage of IPv6, for the 
original intentions of Internet design (ie, direct communication person 
to person anywhere in the world, without intermediaries). I could send 
an email to you without using a public mail server, and I could include 
links to files in my computer without hosting them anywhere. For 
instance. This is also privacy.

> When RFC 8981 was first suggested on the Windows ng, I thought that was the
> panacea but the prefix is the part that ties all our IPv6 activity to our
> home but RFC 8981 doesn't do anything (as far as I can tell) to the prefix.
> 
> As far as I can tell, RFC 8981 does not hide our household identity.
> It only hides our device identity, and even that, only over time.	.
> 
> Given the prefix remains fixed, even with RFC 8981 privacy extensions,
> the ISP and any IPv6-reachable website can still correlate all IPv6
> activity-short-term and long-term-to the subscriber's household.
> 
> Correct me if I'm wrong as I am here to learn so if I'm wrong, say so.


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

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

#17860

Carlos E. R. wrote:
>> To be clear, RFC 8981 privacy extensions are likely great, but AFAIK, they
>> only prevent long-term correlation of activity across different networks.
> 
> Long and short. They know what address is talking, but they do not know 
> what machine inside the house is talking. It is machine XYZW, so what? 
> That tells them nothing.
> 
> Only the router owner knows, if he wants.
> 
> On the other hand, the ISP can capture all the traffic from one machine 
> (not knowing what machine it is actually), and do a traffic analysis on it.

I agree with Carlos that RFC 8981 is decent, but it doesn't change the 
prefix, but I think, where the best privacy is to not have IPv6 at all.

In that regard, looking up the commands to disable IPv6, these may work.

Linux:
 sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
 sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
 sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1
Those are not permanent but puting this is /etc/sysctl.conf should be:
 net.ipv6.conf.all.disable_ipv6 = 1
 net.ipv6.conf.default.disable_ipv6 = 1
 net.ipv6.conf.lo.disable_ipv6 = 1
To apply:
 sudo sysctl -p
To verify:
 cat /proc/sys/net/ipv6/conf/all/disable_ipv6

Windows: disables IPv6 on all non-tunnel interfaces 
(i.e., Teredo, ISATAP, 6to4), but native IPv6 stays enabled.
 reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /t REG_DWORD /d 0x20 /f
 (This disables IPv6 tunnels but keeps native IPv6 and loopback intact.)
 0x20 disables the fake IPv6 Windows creates behind your back,
 but keeps the real IPv6 and all VPN and Wi-Fi still working.
Or,
 reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /t REG_DWORD /d 0x01 /f
 This disables all IPv6 except loopback (::1).
 (which keeps Wi-Fi stable & does not interfere with Tor or VPN) 
Or, 
 reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /t REG_DWORD /d 0xFF /f
 (this is the strongest IPv6-disable flag Microsoft exposes)
 (but it disables the loopback, which breaks many things)
To apply:
 shutdown /r /t 0
To verify:
 ipconfig /all

Note: 0x00 IPv6 fully enabled
      0x20 Disable IPv6 tunnels only (6to4, ISATAP, Teredo)
      0x01 Disable IPv6 except loopback (::1)
      0xFF Disable IPv6 everywhere including loopback (dangerous)
           (this is safe if you don't use pnputil /force afterward)
 If you get in trouble, you can revert with:
  reg delete HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /f

Android needs to be rooted (and in Termux) and is similar to Linux:
 su
 sysctl -w net.ipv6.conf.all.disable_ipv6=1
 sysctl -w net.ipv6.conf.default.disable_ipv6=1
 sysctl -w net.ipv6.conf.wlan0.disable_ipv6=1
 sysctl -w net.ipv6.conf.rmnet0.disable_ipv6=1	
 setprop persist.sys.net.ipv6.disable 1
Persistence, as with Linux, comes with /system/etc/sysctl.conf
 net.ipv6.conf.all.disable_ipv6 = 1
 net.ipv6.conf.default.disable_ipv6 = 1

>> Based on my research (which we discussed in the Windows 10 newsgroup prior)
>> privacy extensions rotate only interface identifiers, not prefixes.
>> 
>> That means, if I'm correct, that even with RFC-8981 privacy extensions...
>> a. Websites see our IPv6 prefix
>> b. Websites know which household the traffic comes from
>> c. Websites can correlate all our temporary IPv6 addresses to that prefix
>> d. Websites can still identify your home even if the IID rotates
>> 
> 
> Certainly, as this is intentional and an advantage of IPv6, for the 
> original intentions of Internet design (ie, direct communication person 
> to person anywhere in the world, without intermediaries). I could send 
> an email to you without using a public mail server, and I could include 
> links to files in my computer without hosting them anywhere. For 
> instance. This is also privacy.

I agree. If I can summarize how IPv6 changes things, IPv4 gave every house 
an IP address but every device in that house looked the same to a web site.

Then IPv6 made every device in the house look different to a web site.

The RFC 8981 "fix" is to rotate the second half of the IPV6 address.
That brought IPv6 back to what IPv4 gave us (kind of, sort of).

With RFC 8981, the IPv6 "house" is still identified permanently.
Just as it was with IPv4.
-- 
Sometimes I have to reassess as what I had "known" all along is wrong.

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

#17842

On 2026-07-21 08:59, Nuno Silva wrote:
> On 2026-07-21, Maria Sophia wrote:
> 
>> Carlos E. R. wrote:


> 
> Two things:
> 
> Yeah, if you want to remove IPv6 from the equation, if you have e.g. a
> "router" device with a wireless AP that can be configured to handle (and
> hand out) only IPv4, configuring it so and connecting through it would
> be a way to be more confident that the issue wouldn't arise.
> 
> Were this another network application and protocol, I'd wonder what's
> prompting the software to connect over IPv6, given the VPN should
> provide DNS with IPv4 only, but I'm guessing this is about IPv6
> addresses in bittorrent, either of peers or of trackers.

If the torrent application connects outside of the VPN, this is a bug 
that should be reported to the app developers. Or to the developers of 
the VPN software. I'm unsure which is at fault.

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

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

#17845

Carlos E. R. wrote:
>> Were this another network application and protocol, I'd wonder what's
>> prompting the software to connect over IPv6, given the VPN should
>> provide DNS with IPv4 only, but I'm guessing this is about IPv6
>> addresses in bittorrent, either of peers or of trackers.
> 
> If the torrent application connects outside of the VPN, this is a bug 
> that should be reported to the app developers. Or to the developers of 
> the VPN software. I'm unsure which is at fault.

Millions of us have been unknowingly leaking IPv6 for years. Me included.
IPv6 silently enabled, silently leaking, nobody told us. It just happened.

It's not a bug.
It's not a mistake.
It's not a misconfiguration.

It's just IPv6 doing what IPv6 does because IPv6 is nothing like IPv4 was.
Worse, most VPNs only protect IPv4 unless they have added support for IPv6.

Torrenting on VPN with a bittorrent client aside, IPv6 is more revealing in
the sense that it gives each device a unique, stable & too public identity
unless privacy extensions are used (and even those don't fully hide the
device). So it still behooves all of us to protect against IPv6 leaks.

Specifically discussing a specific free VPN service that I use, it does not
support IPv6, so *every* app used on that specific VPN service can leak.

It's not even a bug in the VPN software because they designed it for IPv4.
It's not a bug in the torrent client either. Nor in the Firefox browser.

These clients use the OS. Nobody is at fault. It's simply how IPv6 works.

Note that ProtonVPN's free tier supports IPv6 properly, so it's the only
reputable free VPN with real IPv6 support I'm aware of, but Proton VPN
requires registration (which has other privacy issues involved with that).

In a way, the real privacy "bug" is that IPv6 works the way that it does.
-- 	
IPv6 silently enabled, silently leaking, nobody told me. I'm telling you.

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

#17847

On 2026-07-21 11:19, Maria Sophia wrote:
> Carlos E. R. wrote:
>>> Were this another network application and protocol, I'd wonder what's
>>> prompting the software to connect over IPv6, given the VPN should
>>> provide DNS with IPv4 only, but I'm guessing this is about IPv6
>>> addresses in bittorrent, either of peers or of trackers.
>>
>> If the torrent application connects outside of the VPN, this is a bug
>> that should be reported to the app developers. Or to the developers of
>> the VPN software. I'm unsure which is at fault.
> 
> Millions of us have been unknowingly leaking IPv6 for years. Me included.
> IPv6 silently enabled, silently leaking, nobody told us. It just happened.
> 
> It's not a bug.
> It's not a mistake.
> It's not a misconfiguration.

Nono. It is a bug or an error somewhere.

When you use an VPN to channel all the application traffic through the 
VPN, and some goes outside, that is a bug somewhere.


I asked chatgpt about it.

Q: Curious situation. Somebody says he uses a windows computer with an 
VPN with the intent of torrenting trough it, but some traffic is 
bypassing the VPN and using the machine IPv6 connection outside of the 
VPN. I say this is a bug or a fault somewhere, he says it is not.

A:

Your suspicion is reasonable, but the answer depends on what the VPN is 
configured to do.

If the goal is **"all network traffic goes through the VPN"**, then 
**IPv6 traffic escaping over the normal Internet connection is indeed a 
configuration problem or a limitation of the VPN setup**. Many people 
refer to this as an **IPv6 leak**.

Here are the common scenarios:

1. **VPN supports IPv6 properly** ✔️

    * Both IPv4 and IPv6 traffic are routed through the VPN.
    * No leak.

2. **VPN only tunnels IPv4 but disables IPv6** ✔️

    * The operating system has no usable IPv6 connectivity.
    * IPv6 applications fail over to IPv4 through the VPN.
    * No leak.

3. **VPN only tunnels IPv4 and leaves IPv6 active** ❌

    * IPv4 goes through the VPN.
    * IPv6 goes directly to the ISP.
    * This is an IPv6 leak.

The third case is exactly why many VPN providers either:

* fully support IPv6 inside the tunnel, or
* automatically disable IPv6 while connected.

### Is it a bug?

 From the user's perspective, it's fair to call it a bug or 
misconfiguration if they expected the VPN to protect all traffic.

 From a networking perspective, it may not be a software bug at all. It 
could be that:

* the VPN software simply doesn't implement IPv6 tunneling,
* the VPN administrator didn't configure IPv6 routes,
* Windows is behaving according to the routing table it was given.

In other words, Windows isn't "ignoring" the VPN. It is following its 
routing rules.

### Why torrenting makes this more obvious

BitTorrent is unusual because:

* it happily uses IPv6 if available,
* peers can connect directly over IPv6,
* your client may announce both IPv4 and IPv6 addresses.

So if the VPN only covers IPv4, your real IPv6 address may be visible to 
peers, even though websites report your VPN's IPv4 address.

### So who is right?

You're both partly right:

* **You are right** that traffic bypassing the VPN defeats the intended 
privacy goal and is commonly called an IPv6 leak.
* **The other person is right** that this doesn't necessarily mean 
Windows or the VPN software has a coding defect. It can simply be how 
the VPN was designed or configured.

The important question is whether the VPN provider advertises "full IPv6 
protection." If it does, and IPv6 still escapes, then that's a fault 
relative to the product's expected behavior. If the provider explicitly 
says "we only tunnel IPv4" and leaves IPv6 enabled, then the behavior is 
expected, even if it's undesirable for someone who wants all traffic 
protected.


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

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

#17850

Carlos E. R. wrote:
> The important question is whether the VPN provider advertises "full IPv6 
> protection." If it does, and IPv6 still escapes, then that's a fault 
> relative to the product's expected behavior. If the provider explicitly 
> says "we only tunnel IPv4" and leaves IPv6 enabled, then the behavior is 
> expected, even if it's undesirable for someone who wants all traffic 
> protected.

I agree with Carlos, where I only care about the answer being right.
Not who provides that answer. 

The decades on Usenet show I never disagree with any logically sensible
viewpoint, so I agree that whether or not it's a bug depends on what the
VPN provider (or bittorrent client or browser client) "says" they do.

As far as I'm aware, of all the free VPNs I know of, only ProtonVPN says
they fully support IVp6 privacy (but ProtonVPN has registration issues).

I thank Carlos & others for bringing up issues involved, as I must stress I
never bothered to even "think about IPv6" until I wrote my own killswitch.
 Newsgroups: alt.comp.os.windows-10,alt.comp.os.windows-11,alt.comp.microsoft.windows
 Subject: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files
 Date: Thu, 16 Jul 2026 19:32:20 -0400
 Message-ID: <113bpm4$1s4r$1@nnrp.usenet.blueworldhosting.com>

When you write a killswitch, you have to think about how the network works,
so only just a few days ago, did I even bother to consider how IPv6 works.

What I found out about IPv6 floored me. 
I was flabbergasted.

I couldn't believe my eyes.

All these years of using browsers on VPN and my IP address was leaking?
WTF? I couldn't believe it. 

Then, when people suggested RFC 8981, I thought there may be the solution.
But that doesn't work either as it doesn't do a thing to the IPv6 prefix.

So I started asking about "breaking" IPv6, in effect, on a Windows PC.
 Newsgroups: alt.comp.os.windows-10,alt.comp.microsoft.windows,alt.comp.os.windows-11
 Subject: Have you ever disabled IPv6 for privacy (to prevent IP leaks)?
 Date: Sat, 18 Jul 2026 12:47:22 -0400
 Message-ID: <113gamq$ii0$1@nnrp.usenet.blueworldhosting.com>

It was on that thread that people helpfully kindly suggested RFC 8981, but,
when I looked into what RFC8981 does, I realized they were all bamboozled.

So, as is my wont, I started "breaking" IPv6 on my Windows PC, where,
unfortunately for me, my heavy-handed approach completely destroyed Wi-Fi.
 Newsgroups: alt.comp.os.windows-10
 Subject: Taskbar notification network symbol gone & Network & Internet crashes
 Date: Sun, 19 Jul 2026 22:48:18 -0400
 Message-ID: <113k29i$2n69$1@nnrp.usenet.blueworldhosting.com>

I solved the complete and total permanent loss of Wi-Fi by faking Ethernet
on the PC after connecting an old spare router using the a.i.w methodology.

While I was faking Ethernet, I realized that alone blocked IPv6 addresses.
Voila! Instant IPv6 privacy!

With that extremely painful experience in my pocket, I wrote this PSA.
So that others could easily protect themselves from IPv6 privacy leaks.

Without going through the extreme pain that I was forced to endure.
-- 
Sometimes, what we should have known all along is only learned later.

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

#17879

Nuno Silva wrote:
>> Torrenting on VPN with a bittorrent client aside, IPv6 is more revealing in
>> the sense that it gives each device a unique, stable & too public identity
>> unless privacy extensions are used (and even those don't fully hide the
>> device). So it still behooves all of us to protect against IPv6 leaks.
> 
> If what you're trying to avoid is legal action from the MAFIAA or
> actions from the ISP itself, then it really doesn't matter if it's the
> NATed IPv4 address which gets leaked or an IPv6 one. Both would point to
> your subscription with the ISP.

Hi Nuno Silva, 

Thanks for worrying about motives, where it's really a technical issue only
as privacy is like hygiene where it has to be constantly practiced daily.

There are a million things to do for privacy but most people only know 3.

But just to be clear, I'm not worried about "legal action", if for no other
reason that the knowledge that no litigant in the USA has ever been
successful in a court of law against an individual torrenting movies.

But that known fact is not the reason for practicing good privacy hygiene.
Privacy hygiene is a thousand things, which, on a computer, gets technical.

Most marketing organizations don't want us to have privacy, but as
individuals, privacy is what we need to think about when we're online.

What I have done as a matter of basic networking hygiene for decades is I
try to obfuscate my IP address when possible. VPN is just one factor.

Never registering for any product is yet another factor, just as never
paying for a product is another factor in the privacy hygiene equation.

As you may know, almost all my posts are about privacy in one form or
another, where in the case of IPv6 privacy, I didn't know how bad it was.

If we're oblivious to the issues, we're likely to befall them, so it
behooves us to, at the very least, UNDERSTAND how IPv6 leaks can occur.

If our ISP provides an IPv6 address, and if the router let's it pass, and
if the host doesn't stop it, and if we don't stop it at the application,
and if the VPN client doesn't stop it, then every device leaks our privacy.

Even with RFC 8981 privacy extensions.
-- 
Privacy is a million technical things, of which most people know about 3.

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

#17867

On 2026-07-21, Carlos E. R. wrote:

> On 2026-07-21 08:59, Nuno Silva wrote:
>>
>> Two things:
>>
>> Yeah, if you want to remove IPv6 from the equation, if you have e.g. a
>> "router" device with a wireless AP that can be configured to handle (and
>> hand out) only IPv4, configuring it so and connecting through it would
>> be a way to be more confident that the issue wouldn't arise.
>>
>> Were this another network application and protocol, I'd wonder what's
>> prompting the software to connect over IPv6, given the VPN should
>> provide DNS with IPv4 only, but I'm guessing this is about IPv6
>> addresses in bittorrent, either of peers or of trackers.
>
> If the torrent application connects outside of the VPN, this is a bug
> that should be reported to the app developers. Or to the developers of
> the VPN software. I'm unsure which is at fault.

If it's a VPN-specific software in a service promoting privacy or
anonimity, or if it's a non-provider-specific VPN software focusing on
that, then I'd say it's a fault in the VPN software. And, otherwise,
it'd be a feature request for the VPN software?

-- 
Nuno Silva

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

#17873

Nuno Silva wrote:
>> If the torrent application connects outside of the VPN, this is a bug
>> that should be reported to the app developers. Or to the developers of
>> the VPN software. I'm unsure which is at fault.
> 
> If it's a VPN-specific software in a service promoting privacy or
> anonimity, or if it's a non-provider-specific VPN software focusing on
> that, then I'd say it's a fault in the VPN software. And, otherwise,
> it'd be a feature request for the VPN software?

The lesson learned for VPN/IPv6 is to check with the VPN provider.

UPDATE:

Don't do this sequence (which I did when trying to rip IPv6 out of Windows)
 reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xFF /f
  pnputil /remove-device "PCI\VEN_168C&DEV_002A..." 
  pnputil /delete-driver netathrx.inf /uninstall /force

The result is a catastrophic loss of IPv4 routing on the Wi-Fi interface.
It resets the Wi-Fi stack and forces Windows to rebuild routing tables.

Specifically, by disabling IPv6 at the registry level and forcibly removing 
the Atheros Wi-Fi driver, the subsequent pnputil /force step permanently 
wiped out the Wi-Fi networking stack. 

When Windows attempted to rebuild routing tables, because the networking 
stack was completely gone, the OS could not restore IPv4 routing for Wi-Fi.

As a result both Wi-Fi and VPNs were completely & permanently dead.
Wi-Fi didn't work because it depends on a ton of things now removed!
     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
VPN didn't work because the connection depends on the OS routing table.

For a temporary workaround, I used a spare router as a wireless bridge, 
which only required Ethernet connectivity between the desktop & bridge.
 a. The PC connected via Ethernet to the bridge
 b. The bridge connected to my SOHO router Wi-Fi AP
 c. Psiphon provided the IP obfuscation while Wi-Fi routing was broken

Ethernet works because it's simple & Psiphon worked because it bypasses the 
OS routing table by creating its own tunnel & forwarding logic.
 netsh interface set interface "wlan0" admin=disabled
 netsh interface set interface "eth0" admin=enabled
 netsh interface ipv4 set address name="eth0" static 192.168.1.15 255.255.255.0 192.168.1.1
 netsh interface ipv4 set dns name="eth0" static 1.1.1.1
 netsh interface ipv4 add dns name="eth0" 1.0.0.1
 netsh interface ipv4 show dnsservers
 netsh interface ipv4 show config name="eth0"
 netsh interface ipv4 show config
 netsh interface ipv4 show dnsservers
 ping -n 1 192.168.1.1
 ping -n 1 1.1.1.1
 ping -n 1 www.google.com
 wmic nic where (NetEnabled=true) get Name, Speed
 curl -o NUL http://speedtest.tele2.net/1MB.zip
 curl -o NUL http://speedtest.tele2.net/10MB.zip
 curl -o NUL http://speedtest.tele2.net/100MB.zip
 speedtest.exe  (from <https://www.speedtest.net/apps/cli>)
 route print -4
 ipconfig /all 
 psiphon.bat
 
This kept me online long enough to perform recovery using the MCT Media 
Creation Tool & Rufus to create a MBR (BIOS + UEFI) recovery USB stick.

AFAIK, there are only two solutions since the stack cannot be re-installed.
 1. Revert to a previous known-good restore point
 2. Create a Windows recovery flash, boot & recover

Once I had the Wi-F back up, I could revert from Ethernet back to Wi-Fi.
 netsh interface set interface "eth0" admin=disabled
 netsh interface set interface "wlan0" admin=enabled
 netsh interface ipv4 set address name="wlan0" static 192.168.1.16 255.255.255.0 192.168.1.1
 netsh interface ipv4 set dns name="wlan0" static 1.1.1.1
 netsh interface ipv4 add dns name="wlan0" 1.0.0.1
 netsh wlan connect name="my.ssid_nomap"
 netsh interface ipv4 show dnsservers
 netsh interface ipv4 show config name="wlan0"
 netsh interface ipv4 show config
 netsh interface ipv4 show dnsservers
 ping -n 1 192.168.1.1
 ping -n 1 1.1.1.1
 ping -n 1 www.google.com
 wmic nic where (NetEnabled=true) get Name, Speed
 curl -o NUL http://speedtest.tele2.net/1MB.zip
 curl -o NUL http://speedtest.tele2.net/10MB.zip
 curl -o NUL http://speedtest.tele2.net/100MB.zip
 speedtest.exe  (from <https://www.speedtest.net/apps/cli>)
 route print -4
 ipconfig /all 
 vpn.bat

These steps are useful for anyone to save into their debugging checklist.
-- 
Sometimes, ripping the heart out of WIndows isn't always a good thing.

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

#17875

On 20/07/2026 20:59, Carlos E. R. wrote:
> Because he is torrenting via a tunnel to VPN servers. Apparently the 
> torrrent app bypasses the VPN and connects directly via IPv6, so his 
> identity becomes known.

So he should complain about his VPN client then. NOT ABOUT IPv6.
What a cry baby.

-- 
Brian Gregory (in England).

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

#17876

Brian Gregory wrote:
> On 20/07/2026 20:59, Carlos E. R. wrote:
>> Because he is torrenting via a tunnel to VPN servers. Apparently the 
>> torrrent app bypasses the VPN and connects directly via IPv6, so his 
>> identity becomes known.
> 
> So he should complain about his VPN client then. NOT ABOUT IPv6.
> What a cry baby.

Hi Brian Gregory,

The VPN issue is, fundamentally, a red herring since some VPNs block IPv6
leaks and some don't, so it's simply a matter of VPN functionality specs.

As for the bridge router being used to block IPv6 before it gets to the
host, you were right all along. I was wrong. Well, I was right about the
top level strategy, but I was wrong about the bridge solving the problem.

You want to block IPv6 either at the ISP, the router, or at the host.
If I knew then what I knew now, this PSA would have been very different.

It doesn't matter to me who "was" right or wrong though.
What matters is the correct understanding of the problem & solution now.

The problem, as I see it, wrt privacy, is while IPv4 (with NAT) gave every
home a unique IP address, IPv6 gives every device a unique IP address.

As you astutely and helpfully noted, we can ameliorate 'some' of that IPV6
privacy flaw by employing RFC 8981 privacy extensions, but they only rotate
the latter half of the IPv6 address & even so, only after a period of time.

Then IPv6 becomes only slightly worse than IPv4 with respect to IP privacy.
-- 
On Usenet, you can find people who know a lot more than you do about IPv6.

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

#17883

On 22/07/2026 21:46, Maria Sophia wrote:
> The problem, as I see it, wrt privacy, is while IPv4 (with NAT) gave every
> home a unique IP address, IPv6 gives every device a unique IP address.
> 
> As you astutely and helpfully noted, we can ameliorate 'some' of that IPV6
> privacy flaw by employing RFC 8981 privacy extensions, but they only rotate
> the latter half of the IPv6 address & even so, only after a period of time.

And, of course, for most people, with only one LAN, using only a single 
/64 the first half of the IPv6 address gives away no more than your IPv4 
address gives away -- that it's something of yours.

Although I always run dual stack when I can and tend to urge others to 
do so too, I do accept that running IPv4 only is a valid option if you 
have certain priorities, that differ from mine.

-- 
Brian Gregory (in England).

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

#17885

On 2026-07-23, Brian Gregory wrote:

> On 22/07/2026 21:46, Maria Sophia wrote:
>> The problem, as I see it, wrt privacy, is while IPv4 (with NAT) gave every
>> home a unique IP address, IPv6 gives every device a unique IP address.
>>
>> As you astutely and helpfully noted, we can ameliorate 'some' of that IPV6
>> privacy flaw by employing RFC 8981 privacy extensions, but they only rotate
>> the latter half of the IPv6 address & even so, only after a period of time.
>
> And, of course, for most people, with only one LAN, using only a
> single /64 the first half of the IPv6 address gives away no more than
> your IPv4 address gives away -- that it's something of yours.

Yeah, if you're in a context where IPv4 is NATed at your premises
because the ISP hands you one address, and you also get IPv6 prefix
delegation, then... it's the same thing, your IPv4 address identifies
the connection, as does the prefix present in the RAs.

The part that is "rotated" or otherwise randomized in such
privacy-centered SLAAC configurations is the one that'd allow tracking
the *device*, not the connection.

That's not meant to stop tracking your e.g. residential connection, it's
meant to stop tracking the device based on the device-specific portion
of the address, which without this may e.g. contain the MAC address.

<https://en.wikipedia.org/wiki/IPv6_address#Interface_identifier>


But for e.g. MAFIAA this only matters if you're not using your own
connection, because otherwise you've already been identified by the
delegated prefix, they'd pester you the same.

Do note: the prefix used in SLAAC isn't (or shouldn't be...) something a
residential ISP uses for several costumers, it's meant to be one prefix
for each contract/ISP connection/modem.

> Although I always run dual stack when I can and tend to urge others to
> do so too, I do accept that running IPv4 only is a valid option if you
> have certain priorities, that differ from mine.

-- 
Nuno Silva

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

#17894

Nuno Silva wrote:
>>> The problem, as I see it, wrt privacy, is while IPv4 (with NAT) gave every
>>> home a unique IP address, IPv6 gives every device a unique IP address.
>>>
>>> As you astutely and helpfully noted, we can ameliorate 'some' of that IPV6
>>> privacy flaw by employing RFC 8981 privacy extensions, but they only rotate
>>> the latter half of the IPv6 address & even so, only after a period of time.
>>
>> And, of course, for most people, with only one LAN, using only a
>> single /64 the first half of the IPv6 address gives away no more than
>> your IPv4 address gives away -- that it's something of yours.
>> Although I always run dual stack when I can and tend to urge others to 
>> do so too, I do accept that running IPv4 only is a valid option if you 
>> have certain priorities, that differ from mine.
> 
> Yeah, if you're in a context where IPv4 is NATed at your premises
> because the ISP hands you one address, and you also get IPv6 prefix
> delegation, then... it's the same thing, your IPv4 address identifies
> the connection, as does the prefix present in the RAs.
> 
> The part that is "rotated" or otherwise randomized in such
> privacy-centered SLAAC configurations is the one that'd allow tracking
> the *device*, not the connection.
> 
> That's not meant to stop tracking your e.g. residential connection, it's
> meant to stop tracking the device based on the device-specific portion
> of the address, which without this may e.g. contain the MAC address.
> 
> <https://en.wikipedia.org/wiki/IPv6_address#Interface_identifier>
> 
> But for e.g. MAFIAA this only matters if you're not using your own
> connection, because otherwise you've already been identified by the
> delegated prefix, they'd pester you the same.
> 
> Do note: the prefix used in SLAAC isn't (or shouldn't be...) something a
> residential ISP uses for several costumers, it's meant to be one prefix
> for each contract/ISP connection/modem.
> 
>> Although I always run dual stack when I can and tend to urge others to
>> do so too, I do accept that running IPv4 only is a valid option if you
>> have certain priorities, that differ from mine.

Thank you all for this very useful information about IPv6 privacy issues.

Since Usenet is for learning from people like Nuno Silva & Brian Gregory,
who know far more about this IPv6-privacy stuff than I will ever know...

Looking up the terms they're using is helpful to understand the network.

When Brian says "dual stack", he's meaning both the IPv4 & IPv6 stacks.
They're two parallel protocol stacks, where his devices can use either
protocol depending on what the remote service supports. If a site has IPv6,
his device may prefer it; if not, it falls back to IPv4, which provides
Brian benefit from IPv6's performance and routing improvements without
losing any IPv4 compatibility.	

When Nuno says SLAAC, he's using the acronym for Stateless Address
Autoconfiguration, which is the IPv6 mechanism that lets a device
automatically generate its own IPv6 address without needing a DHCP server.

The ISP gives us the network prefix (the first 64 bits) IPv6 address and
each device builds the second half (the Interface Identifier) IID address
on its own. It used to be derived from the MAC address, but not in modern
systems anymore, the point being if the IID half is stable, websites can
track specific devices across sessions. RFC 8981 destabilizes that, but
only after a set time period (generally defaulting to 24 hours).

An example is if you go to Starbucks in the morning and afternoon, and
visit the same web site in two different sessions, they know it's you in
both sessions.

Note that the web site knows it's starbucks too, which is why the first
half of IPV6 is no worse in terms of privacy than IPv4 is; but it's that
festugenah second half of the IPv5 prefix that we have to keep in mind.

His MAFIAA terminology is a play on the mafia-like behavior of copyright
trolls, combining RIAA (Recording Industry Association of America) with
MPAA (Motion Picture Association of America), where I would stress that
many people pay up but nobody who ever fought them in the USA ever lost.

With respect to VPN, I just found out that OpenVPN 2.5+ added a directive
specifically meant to prevent the very IPv6 leaks we've been discussing!
 block-ipv6 ; block IPv6 traffic by adding firewall rules to prevent leaks
Apparently it magically installs firewall rules on our devices that somehow
know to drop all IPv6 traffic unless it is going through the VPN tunnel.

It forces all IPv6 traffic to go through the VPN, or be blocked entirely.	.

If running older OpenVPN on linux, we can add firewall rules manually:
 ip6tables -P OUTPUT DROP
 ip6tables -P INPUT DROP

In short, I thank Nuno & Brian for bringing this up at a level far above my
pay grade since I just learned the simplest solution of all to the problem.

Apparently block-ivp6 blocks IPv6 only when the tunnel doesn't support it.
Which is perfect because understanding networking is what this is about.

BTW, while looking this up, I learned these potentially useful directives:
 block-outside-dns ; force DNS queries to stay inside the VPN interface 
This says, if a program tries to resolve DNS through wlan0, eth0, or
anything other than the TAP adapter, then block it (to prevent leaks).

Then, inside the VPN tunnel, we can explicitly set the DNS servers.
 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

I just tested them; now I see a full, healthy DNS stack inside the tunnel.
 NETSH: ... set dns 19 static 1.1.1.1
 NETSH: ... add dns 19 9.9.9.9
 NETSH: ... add dns 19 8.8.8.8

I knew absolutely nothing about IPv6 before this thread, so I thank
everyone for quickly correcting my newbie mistakes without pulling punches!

I still have work to do because apparently curl leaks outside of the VPN.
-- 
I learn best from helpful people who know a hellova lot more than I do.


































	.	 

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

#17908

David Higton <dave@davehigton.me.uk> wrote:
> In message <113kg6k$s72$1@nnrp.usenet.blueworldhosting.com>
>           Maria Sophia <mariasophia@comprehension.com> wrote:
> 
>> PSA: 
>> IPv6 browser privacy leaks are caused by the host, yet there's a fix.
>> ISP modem > IPv6-silent bridge > normal home router > Wi-Fi devices
>> 
>> On all platforms, web browsers can leak your globally-routable IPv6
>> address (even when you're using a VPN). This IPV6 privacy leak happens
>> because the browsers prefer IPv6 and the OS host itself participates in
>> IPv6 routing. 
> 
> I don't understand why you think there's a problem.  Very much the whole
> point of IPv6 is that all your globally routable IPv6 addresses are,
> well, globally routable.  I'd be happy for the whole world to know what
> mine are.
> 
> The only ports that are open on any of these addresses to incoming
> connections are as a result of my opening a pinhole in the firewall.
> 
> So, knowing your globally routable addresses is one thing.  Allowing
> connections in to any of them is entirely another matter.
> 
> David
> 

NSA-coded post right here lol.

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

#17933

Oregonian Haruspex wrote:
> NSA-coded post right here lol.

To ensure DNS is working right, I explicitly set it in the openvpn config.

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:\\tmp\\vpn\\0\\require\\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] | [next] | [standalone]

#17833

Richmond wrote:
>>> If a router is in bridge mode (no IPv6 delegation, no prefix
>>> assignment), all connected devices never receive a global IPv6
>>> address.  *No global IPv6 address = nothing for the browser to leak.*
>>
>> Doesn't this depend on whether the ISP supports IPV6? Why is it
>> necessary to use bridged mode to disable IPV6? my router can switch
>> off IPv6 without bridged mode? How do you make use of NAT in bridged
>> mode?  Does each device get its own IPV4 address from the ISP?
> 
> Furthermore, I don't think it is leaking an ipv6 address, that is what
> it is supposed to do, give every device its own public IP address.

Hi Richmond,

I only started delving into IPv6 two days ago when I was trying to identify
and resolve potential privacy leaks so I do agree with you that the common
vernacular of 'leaks' is basically how IP addressing is designed to work.

Hence, you're right the ISP must support IPv6 before any device can receive
a globally-routable IPv6 address. Therefore, you're quite right that many
ISPs do support IPv6 now, and most home routers will happily hand
out IPv6 addresses even if the user never touches the IPv6 settings.

Disabling IPv6 in the router UI should work, but you have to test it to be
sure because there are cases where on consumer routers the "disable IPv6"
toggle only disables the router's own IPv6 functions. Depending on the
router, that disable switch does not always stop prefix delegation or SLAAC
from reaching the LAN. In other words, the router's GUI may claim IPv6 is
off, while the LAN clients still receive IPv6 addresses anyway.

Those are the kinds of IPv6 leaks we all should be aware of if we care
about privacy but the beauty of this PSA is that a simple bridged
configuration avoids this ambiguity. 

That bridge can be a dumb switch. It doesn't need to be a router.
 modem <-> dumb bridge <-> router <-> any device <-> any browser

A bridge does not perform IPv6 delegation, does not advertise IPv6
prefixes, and does not participate in IPv6 routing. Because of that, no
device behind the bridge ever receives a global IPv6 address. 

With no IPv6 address on the host, the browser has nothing to leak.

NAT is handled by the actual router behind the bridge. The bridge
is only passing IPv4. The ISP modem stays in bridge mode, and the
normal home router continues to do IPv4 NAT exactly as it always did.
Devices do not get public IPv4 addresses from the ISP. They get
private IPv4 addresses from the home router, same as before.

Regarding "leaking" IPv6, as you noted, the leak is not a malfunction. 
It is simply how IPv6 works. But it's something to be aware of.

With IPv6, every device gets its own globally-routable address,
and browsers prefer IPv6 when it is available. Windows also prefers
IPv6 over IPv5. So, if the host has a global IPv6 address, a browser can
expose it even if the VPN is tunneling IPv4 traffic. The leak is a
side-effect of normal IPv6 behavior.

I agree there are many ways to handle this IPv6 leak issue, where the whole
point of the PSA is that there is a simple effective solution available.

The host-level IPv6 participation is the root cause of IPv6 privacy
exposure. If the host never receives an IPv6 address, the browser cannot
reveal one. 

I was seeking the *simplest* solution, where it turns out a silent bridge
is the simplest way to guarantee that outcome on any OS and any browser.
-- 	 
In computers, a good philosophy is just as important as good technology.

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

#17837

On 2026-07-21, Maria Sophia wrote:

> The host-level IPv6 participation is the root cause of IPv6 privacy
> exposure. If the host never receives an IPv6 address, the browser cannot
> reveal one.

Regarding wording: wouldn't the root cause be the VPN only providing
IPv4 and no IPv6? If you're using a VPN for privacy, then I'd chalk that
down as a flaw with the VPN, not with the rest of the system and network
working as expected.

I guess you'd have the same issue if you were on IPv4 with no NAT and
the VPN only offered IPv6.

-- 
Nuno Silva

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

#17840

Nuno Silva wrote:
>> The host-level IPv6 participation is the root cause of IPv6 privacy
>> exposure. If the host never receives an IPv6 address, the browser cannot
>> reveal one.
> 
> Regarding wording: wouldn't the root cause be the VPN only providing
> IPv4 and no IPv6? If you're using a VPN for privacy, then I'd chalk that
> down as a flaw with the VPN, not with the rest of the system and network
> working as expected.
> 
> I guess you'd have the same issue if you were on IPv4 with no NAT and
> the VPN only offered IPv6.

It's a good point Nuno Silva brings up, where I think the VPN is not the
root cause because it happens all the time, so the root cause is higher.

As noted by Nuno, the VPN offering only IPv4 is part of the symptom, but
it's not the root cause because the problem exists with any browser too.

The underlying issue is whether the host participates in IPv6 at all. 

While the issue happens with or without VPN in the mix, the underlying
presumption when using VPN is that it's more critical not to be identified.

But once any host has a globally routable IPv6 address, any application can
expose that address directly to the ISP, whether or not you want it to. 

That's the privacy leak.

Given modern Mozilla/Chromium browsers prioritize IPv6 over IPv4, 
the practical privacy issue discussed in this PSA isn't limited to VPNs.	 
	
The privacy leak occurs because the host has a IPv6 identity available.

Hence, this PSA suggests the *simplest* effective privacy solution is...
 modem <--> silent bridge <--> router <--> any device <--> any application
 
Although, there are other solutions, all of which are more complex (IMHO).

Aside from the cost of the hardware, the main downside of the silent bridge
approach offered in this PSA is that it disables IPv6 entirely. 

Anyone who actually relies on IPv6-only services would lose the capability.
Would full loss of IPv6 be acceptable for most users on these newsgroups?

Who here is actually using IPv6 for anything that would be impacted?
-- 
Usenet allows people with shared interests to discuss topics of import.

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

#17866

On 2026-07-21, Maria Sophia wrote:

> Nuno Silva wrote:
>>> The host-level IPv6 participation is the root cause of IPv6 privacy
>>> exposure. If the host never receives an IPv6 address, the browser cannot
>>> reveal one.
>> 
>> Regarding wording: wouldn't the root cause be the VPN only providing
>> IPv4 and no IPv6? If you're using a VPN for privacy, then I'd chalk that
>> down as a flaw with the VPN, not with the rest of the system and network
>> working as expected.
>> 
>> I guess you'd have the same issue if you were on IPv4 with no NAT and
>> the VPN only offered IPv6.
>
> It's a good point Nuno Silva brings up, where I think the VPN is not the
> root cause because it happens all the time, so the root cause is higher.
>
> As noted by Nuno, the VPN offering only IPv4 is part of the symptom, but
> it's not the root cause because the problem exists with any browser too.
>
> The underlying issue is whether the host participates in IPv6 at all. 
>
> While the issue happens with or without VPN in the mix, the underlying
> presumption when using VPN is that it's more critical not to be identified.
>
> But once any host has a globally routable IPv6 address, any application can
> expose that address directly to the ISP, whether or not you want it to. 
>
> That's the privacy leak.
>
> Given modern Mozilla/Chromium browsers prioritize IPv6 over IPv4, 
> the practical privacy issue discussed in this PSA isn't limited to VPNs.	 
> 	
> The privacy leak occurs because the host has a IPv6 identity
> available.

I still stand by the point that the leak occurs because the VPN system
somehow does not preclude usage of non-VPN routes. Now this might be
okay for some uses of VPNs, where the goal is to access internal
services (corporate, school), but not for others, where the goal is to
have a separate "environment" for network access.

> Hence, this PSA suggests the *simplest* effective privacy solution is...
>  modem <--> silent bridge <--> router <--> any device <--> any application
>  
> Although, there are other solutions, all of which are more complex (IMHO).
>
> Aside from the cost of the hardware, the main downside of the silent bridge
> approach offered in this PSA is that it disables IPv6 entirely. 
>
> Anyone who actually relies on IPv6-only services would lose the capability.
> Would full loss of IPv6 be acceptable for most users on these
> newsgroups?
>
> Who here is actually using IPv6 for anything that would be impacted?

Probably a few people who are behind NAT, or worse, CGNAT, but do get
IPv6 prefixes might have interest in retaining that connectivity.

Completely axing IPv6 also gets rid of link-local addresses, that can be
useful for internal networking.

Not that I'm taking advantage of that on Android. (Yet. :-P)

-- 
Nuno Silva

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | alt.comp.software.firefox

csiph-web