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

Groups > alt.comp.os.windows-10 > #194621 > 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.os.windows-10

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

Page 1 of 3  [1] 2 3  Next page →

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

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. 

Basically, if the host has a global IPv6 address, a browser can expose it.
  Browsers leak IPv6... but bridges stop it cold!

Specifically, a silent bridge is a bridge that passes IPv4 but never hands
out or forwards IPv6, so no device behind it ever gets a global IPv6
address. If the host never receives IPv6, the browser cannot leak IPv6.  

Long story short, recently I delved into the *simplest* way to completely 
protect us (on any OS) from any web browser (Mozilla or Chromium) leaking 
IPV6 privacy (after recovering from a dreadful Windows IPV6 0xFF disaster).
 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>

There are lots of tricks, such as RFC 8981 IPV6 rotation privacy, but 
here's the important part I learned when I fully disabled IPv6 (0xFF)
instead of only partially disabling it (0x20) as most people would do.

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.*

This protects IPV6 privacy on all operating systems and all web browsers.
 a. It doesn't matter which browser you use (Chromium, Firefox, etc.).
 b. It doesn't matter which OS you use.
 c. If the host never receives an IPv6 address, the leak cannot occur.

IMHO, this is the simplest way to eliminate IPv6 browser leaks:
Disable IPv6 at the router level by using a bridged configuration.

Host-level IPv6 participation is the root cause of IPV6 leaks.
Hence, if we remove the host from IPv6 routing, that IPV6 leak disappears!

In summary, the topic of this PSA is likely not discussed anywhere else on
this planet, but what I just learned was this simple IPv6 privacy epiphany.
 1. Browsers leak IPv6 because they prefer IPv6 when available. 
 2. If the host receives a global IPv6 address (via SLAAC or DHCPv6), 
    the browser may expose it even if IPv4 traffic is tunneled thru VPN.
 3. However, bridge mode prevents prefix delegation, so hosts never 
    obtain global IPv6 addresses.

No IPv6 address = no IPv6 leak!
Who knew! Not me. Now I do!

As always, if you have a simpler solution, let's discuss it as the whole
point of this thread is to ensure we can protect from IPv6 privacy leaks.
-- 
IPv6 leaks begin at the host; an IPv6‑silent bridge ends them.

[toc] | [next] | [standalone]

#194636

On 2026-07-20 08:45, Maria Sophia 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.*

Look up Teredo, in Windows.

In Linux, disabling Ipv6 is feasible.

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

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

#194676

Carlos E. R. 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.*
> 
> Look up Teredo, in Windows.
> 
> In Linux, disabling Ipv6 is feasible.

Linux does allow complete IPv6 disablement because the kernel can be told
not to accept IPv6 router advertisements or to generate IPv6 addresses.

So Carlos is correct! Linux can truly disable IPv6 at the kernel level.

Funny he mentions "taredo" because in the OP of Usenet thread discussing
how to disable IPv6, the very first step performed was disabling Taredo!

 netsh interface ipv6 set teredo disabled
 netsh interface ipv6 set 6to4 disabled (deprecated on my Win10 Pro box)
 netsh interface ipv6 set isatap disabled (deprecated on my Win10 Pro box)
 reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v
DisabledComponents /t REG_DWORD /d 0xFF /f

WARNING! Do not set Tcpip6 DisabledComponents to hex FF like I did.
All hell will break loose the instant you do that (ask me how I know that).
Instead, set Tcpip6 DisabledComponents to hex 20 like everyone else does.

To Carlos' astutely helpful accurate technical point, on Windows, Teredo is
an IPv6-over-IPv4 tunneling mechanism that can, in and of itself, create
IPv6 connectivity (literally behind your back unless you disable it).

Teredo works by encapsulating IPv6 packets inside IPv4 UDP packets to give
a PC IPv6 connectivity even when you think IPv6 doesn't exist or is off.

It's named for Teredo navalis, a shipworm that burrows through wood.
 a. IPv6 === the ship
 b. IPv4 NAT === the wood
 c. Taredo === the worm that tunnels through NAT to create deliver IPv6

Teredo can be disabled, but it requires:
 a. disabling the Teredo interface
 b. disabling IPv6 transition technologies
 c. ensuring no partial IPv6 configuration exists
 d. ensuring the router does not advertise IPv6 at all

Those steps are why this PSA focuses on removing IPv6 at the router level.
   modem <-> dumb bridge <-> router <-> any OS <-> any browser

If the LAN never provides IPv6, Teredo has nothing to tunnel	.

BTW, in the thread below where disabling Taredo was the first step, the
setup that caused the epiphany had the wireless bridge later on the LAN 
 modem <-> router <-> Wireless bridge <-> Windows OS <-> Firefox browser 

The distinction being that everything *after* the bridge is protected.
	 
REFERENCE:
 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>
-- 
Teredo navalis is a type of shipworm that burrows through wood.

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

#194684

On 2026-07-21 08:43, Maria Sophia wrote:
> Carlos E. R. 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.*
>>
>> Look up Teredo, in Windows.
>>
>> In Linux, disabling Ipv6 is feasible.
> 
> Linux does allow complete IPv6 disablement because the kernel can be told
> not to accept IPv6 router advertisements or to generate IPv6 addresses.
> 
> So Carlos is correct! Linux can truly disable IPv6 at the kernel level.

There are several methods. I did it years ago because my machine 
thought, wrongly, that my ISP provided IPv6 when it doesn't, and I got 
no connectivity. I only needed that temporarily.

I asked ChatGpt for the methods (google is not working now for me, no 
answer at all), so here they go, without verification. Just for 
curiosity sake:

There are several ways to disable IPv6 on Linux, depending on whether 
you want the change to be temporary or permanent.

### Temporary (until reboot)

This disables IPv6 immediately:

```bash
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
```

To also disable it on the loopback interface:

```bash
sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1
```

Verify:

```bash
cat /proc/sys/net/ipv6/conf/all/disable_ipv6
```

A value of `1` means IPv6 is disabled.

---

### Permanent using `sysctl`

Create a configuration file:

```bash
sudo nano /etc/sysctl.d/99-disable-ipv6.conf
```

Add:

```text
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
```

Apply it immediately:

```bash
sudo sysctl --system
```

Or reboot.

---

### Disable via the kernel boot parameter

This is the most complete method because it prevents the IPv6 module 
from initializing.

For systems using GRUB:

1. Edit:

```bash
sudo nano /etc/default/grub
```

2. Add `ipv6.disable=1` to `GRUB_CMDLINE_LINUX_DEFAULT`, for example:

```text
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ipv6.disable=1"
```

3. Update GRUB:

* Debian/Ubuntu:

```bash
sudo update-grub
```

* RHEL/Fedora:

```bash
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
```

(On UEFI systems, the output path may instead be 
`/boot/efi/EFI/<distro>/grub.cfg`.)

4. Reboot.

---

### Disable IPv6 in NetworkManager (per connection)

If you only want to disable IPv6 for one network connection:

```bash
nmcli connection modify "<connection-name>" ipv6.method disabled
nmcli connection up "<connection-name>"
```

List connections:

```bash
nmcli connection show
```

---

### Check whether it's disabled

```bash
ip -6 addr
```

or

```bash
cat /proc/cmdline
```

If you used the kernel parameter, you should see:

```text
ipv6.disable=1
```

### Which method should you use?

* **Only for testing or troubleshooting:** Use the `sysctl` method.
* **For one specific network connection:** Use `nmcli`.
* **To completely disable IPv6 system-wide:** Use the kernel boot 
parameter (`ipv6.disable=1`), as it's the most thorough approach.



> 
> Funny he mentions "taredo" because in the OP of Usenet thread discussing
> how to disable IPv6, the very first step performed was disabling Taredo!
> 
>   netsh interface ipv6 set teredo disabled
>   netsh interface ipv6 set 6to4 disabled (deprecated on my Win10 Pro box)
>   netsh interface ipv6 set isatap disabled (deprecated on my Win10 Pro box)
>   reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v
> DisabledComponents /t REG_DWORD /d 0xFF /f
> 
> WARNING! Do not set Tcpip6 DisabledComponents to hex FF like I did.
> All hell will break loose the instant you do that (ask me how I know that).
> Instead, set Tcpip6 DisabledComponents to hex 20 like everyone else does.
> 
> To Carlos' astutely helpful accurate technical point, on Windows, Teredo is
> an IPv6-over-IPv4 tunneling mechanism that can, in and of itself, create
> IPv6 connectivity (literally behind your back unless you disable it).
> 
> Teredo works by encapsulating IPv6 packets inside IPv4 UDP packets to give
> a PC IPv6 connectivity even when you think IPv6 doesn't exist or is off.
> 
> It's named for Teredo navalis, a shipworm that burrows through wood.
>   a. IPv6 === the ship
>   b. IPv4 NAT === the wood
>   c. Taredo === the worm that tunnels through NAT to create deliver IPv6
> 
> Teredo can be disabled, but it requires:
>   a. disabling the Teredo interface
>   b. disabling IPv6 transition technologies
>   c. ensuring no partial IPv6 configuration exists
>   d. ensuring the router does not advertise IPv6 at all
> 
> Those steps are why this PSA focuses on removing IPv6 at the router level.
>     modem <-> dumb bridge <-> router <-> any OS <-> any browser
> 
> If the LAN never provides IPv6, Teredo has nothing to tunnel	.

Eum... no, Teredo function works on an IPv4 only LAN and WAN. It is a 
tunnel. It punches a hole using IPv4.

What I don't remember is where is the outside hole of that tunnel, and 
what apps inside Windows can use that tunnel. Not general traffic, I 
believe.


> BTW, in the thread below where disabling Taredo was the first step, the
> setup that caused the epiphany had the wireless bridge later on the LAN
>   modem <-> router <-> Wireless bridge <-> Windows OS <-> Firefox browser
> 
> The distinction being that everything *after* the bridge is protected.
> 	
> REFERENCE:
>   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>


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

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

#194690

Carlos E. R. wrote:
> There are several ways to disable IPv6 on Linux, depending on whether 
> you want the change to be temporary or permanent.

I agree with everything Carlos suggested, where I ran a few searches to 
help everyone on these newsgroups test, right now, their IPv6 protection.

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)	 

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]

#194697

On 2026-07-21 13:36, Maria Sophia wrote:
> Carlos E. R. wrote:
>> There are several ways to disable IPv6 on Linux, depending on whether
>> you want the change to be temporary or permanent.
> 
> I agree with everything Carlos suggested, where I ran a few searches to
> help everyone on these newsgroups test, right now, their IPv6 protection.
> 

There is another trick in Linux to make the system prefer IPv4 over IPv6 
if both exist. Idon't remember what it was, so again I asked ChatGPT, 
and yes, that was it:

Yes. You're probably thinking of **changing the address selection 
policy** so that applications **prefer IPv4 over IPv6** rather than 
disabling IPv6 entirely.

On systems using the GNU C Library (`glibc`), this is controlled by 
`/etc/gai.conf`.

Edit:

```bash
sudo nano /etc/gai.conf
```

Find this line:

```text
#precedence ::ffff:0:0/96  100
```

Uncomment it:

```text
precedence ::ffff:0:0/96  100
```

This gives IPv4-mapped addresses a higher precedence, causing 
`getaddrinfo()` to return IPv4 addresses before IPv6 ones in most cases.

### What this does

Suppose a host has both:

```
example.com
├── A     203.0.113.5
└── AAAA  2001:db8::5
```

Normally, many Linux systems will try the IPv6 address first.

With the `gai.conf` change, most applications will instead connect to 
the IPv4 address first.

### What it does *not* do

* It **does not disable IPv6**.
* Applications that explicitly request IPv6 can still use it.
* Programs that don't use `getaddrinfo()` or implement their own address 
selection may ignore this preference.

### Why it exists

This mechanism follows the address selection rules defined in RFC 6724. 
The default policy prefers IPv6, but `gai.conf` allows administrators to 
override the precedence.

### Is this useful for avoiding VPN leaks?

Not really. It reduces the chance that applications will choose IPv6, 
but it doesn't eliminate it. If your concern is privacy or ensuring that 
**all** traffic goes through a VPN, the correct solution is one of:

* use a VPN that tunnels both IPv4 and IPv6,
* configure the VPN to disable IPv6 while connected, or
* disable IPv6 system-wide.

Changing `gai.conf` is more appropriate when you have a network where 
IPv6 technically works but performs poorly or is unreliable, and you 
want applications to favor IPv4 without removing IPv6 support altogether.



> 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)	
> 
> May I ask others out there what your IPv6 results were with Firefox?

My ISP does not provide IPv6 at all to homes. There was a Beta testing 
of IPv6, and for two months I had it.

However, it does on mobile phones. On my phone I get an IPv6, and also 
an IPv4 on the 10.*.*.* range, thus using GNAT.

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

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

#194703

Carlos E. R. wrote:
>> May I ask others out there what your IPv6 results were with Firefox?
> 
> My ISP does not provide IPv6 at all to homes. There was a Beta testing 
> of IPv6, and for two months I had it.
> 
> However, it does on mobile phones. On my phone I get an IPv6, and also 
> an IPv4 on the 10.*.*.* range, thus using GNAT.

Thanks Carlos for your information, as this entire endeavor was costly in
terms of mistakes made and in the miserable investment in recovery efforts.

1. I permanently lost all Wi-Fi & VPN (due to pnputil /delete /force)
2. So I'm temporarily on a wireless bridge set up over Ethernet to the PC
3. Such that I have to rebuild Windows 10 using a MCT recovery method

While I learned a lot about IPv6, I found out it was all for naught!

I contacted my WISP this morning, and he confirmed he doesn't serve IPv6.
So the entire sordid sorry affair, for me, was a red herring after all.

I did learn a lot about IPv6 though, and how to block it, so it wasn't a
total waste of effort, as everyone else can benefit from what we discussed.

The net summary in this PSA is still valid, which is that the way to
prevent IPv6 leaks is to not have IPv6 on your network in the first place.

1. Either we kill IPv6 at the ISP (by them not serving it)
2. Or, we kill IPv6 at the router (by blocking it entirely)
3. Or, we kill IPv6 at the host device 
   (but simply adding a bridge does NOT kill IPv6).
   I had surmised that wrongly, because I couldn't find it after that.
   But I had never looked before. Now I know it was never there.
4. Or, we can kill IPV6 at the application, such as about:config
5. Or, we can kill IPv6 using a VPN that "says" it kills IPv6!

In addition, if we don't kill IPv6, we can neuter it a bit.
6. We can "rotate" the sinister half of IPv6 with RFC 8981 extensions.

So, in this thread, I learned a lot because I never even thought about IPv6
until I tried to block it, and when it was gone, I "thought" the bridge
killed it, but it turns out, embarrassingly, my WISP never provided it.

So, just as Carlos' situation showed him, IPv6 was never there.
Sigh.

Lesson(s) learned.
At least now we're all more familiar with what IPv6 is and what it does.
-- 
I broke the OS chasing IPv6, but I gained understanding worth the cost.

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

#194708

Maria Sophia wrote on 7/21/2026 1:32 PM:
> Carlos E. R. wrote:
>>> May I ask others out there what your IPv6 results were with Firefox?
>>
>> My ISP does not provide IPv6 at all to homes. There was a Beta testing
>> of IPv6, and for two months I had it.
>>
>> However, it does on mobile phones. On my phone I get an IPv6, and also
>> an IPv4 on the 10.*.*.* range, thus using GNAT.
> 
> Thanks Carlos for your information, as this entire endeavor was costly in
> terms of mistakes made and in the miserable investment in recovery efforts.
> 
> 1. I permanently lost all Wi-Fi & VPN (due to pnputil /delete /force)
> 2. So I'm temporarily on a wireless bridge set up over Ethernet to the PC
> 3. Such that I have to rebuild Windows 10 using a MCT recovery method
> 
> While I learned a lot about IPv6, I found out it was all for naught!
> 
> I contacted my WISP this morning, and he confirmed he doesn't serve IPv6.
> So the entire sordid sorry affair, for me, was a red herring after all.
> 
> I did learn a lot about IPv6 though, and how to block it, so it wasn't a
> total waste of effort, as everyone else can benefit from what we discussed.
> 
> The net summary in this PSA is still valid, which is that the way to
> prevent IPv6 leaks is to not have IPv6 on your network in the first place.
> 
> 1. Either we kill IPv6 at the ISP (by them not serving it)
> 2. Or, we kill IPv6 at the router (by blocking it entirely)
> 3. Or, we kill IPv6 at the host device
>     (but simply adding a bridge does NOT kill IPv6).
>     I had surmised that wrongly, because I couldn't find it after that.
>     But I had never looked before. Now I know it was never there.
> 4. Or, we can kill IPV6 at the application, such as about:config
> 5. Or, we can kill IPv6 using a VPN that "says" it kills IPv6!
> 
> In addition, if we don't kill IPv6, we can neuter it a bit.
> 6. We can "rotate" the sinister half of IPv6 with RFC 8981 extensions.
> 
> So, in this thread, I learned a lot because I never even thought about IPv6
> until I tried to block it, and when it was gone, I "thought" the bridge
> killed it, but it turns out, embarrassingly, my WISP never provided it.
> 
> So, just as Carlos' situation showed him, IPv6 was never there.
> Sigh.
> 
> Lesson(s) learned.
> At least now we're all more familiar with what IPv6 is and what it does.
> 

And onward to the next windmill

Chaaaarge !!!!!!!!!!!!!!

Get off your ass, Sancho, and follow me into battle!

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

#194716

Nuno Silva wrote:
>> 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.

Hi Nuno Silva,

My "goal" on VPN is simply to obfuscate my IP address, whether that is IPv6 
or IPv4, and, it turns out after all, that I've accomplished that goal.

At least on Windows I have. (Linux even more so had I been booting to it.)
For Android, it's more complicated.

Some things I'm an expert on, and other things I'm just ignorant about.
I was right about a few things in this PSA, but I was wrong about some.

So if I were to write this thread now, instead of a couple of days ago, it 
would be very different because the problem is the same, but the solution 
is different. 

As for the 'problem', the problem remains that IPv6 is very different from 
IPv4 in terms of device privacy, but the solutions I first proposed was 
correct strategically, but I would change it greatly tactically today.

Now I know that the only free VPN that I know of that "says" it protects 
against IPv6 leaks, for example, is ProtonVPN (which has other issues).

The free VPN from whom I get thousands of config files and which I've been 
using since 2013 for free apparently does not say either way or the other.

So it probably does not. So, we "could" call that a bug, but I won't.
It's just how it works. It's like me asking an MUA to filter out spam.

The real PSA is to learn how to identify how IPv6 privacy leaks can occur.

So, the good news in this PSA is that people on these newsgroups are now 
aware to L@@K for IPv6 privacy leaks when they're on "their VPN" of choice.

>> 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)

I must be clear here that I was dead wrong that the bridge solves anything. 

What I've learned in the past couple of days is that almost nobody is 
"using" IPv6 (and, in fact, it turns out, my own WISP doesn't even do it).

But other ISP's likely do hand out routable IPv6 addresses, so the privacy 
issue is real, and much worse (in many ways) than it ever was with IPv4.

With NAT, every house had a unique IPv4 address, but with IPv6, every 
single device has a unique IPv6 address, whether it's rotated or not.

And, that RFC 8981 rotation only rotates the unique-to-the-device half
of the IPv6 address. RFC 8981 does nothing for the home-identifier part.

If we don't want to worry about IPv6 privacy issues, we have to either stop 
it at the router (which my router apparently has the option to do), or, we 
have to stop it at the device (which Windows & Linux devices can do).

Both Carlos and I have been describing ways to stop IPv6 at the device.
But, my original suggestion to stop IPv6 with a bridge was pure hogwash.

I was deluded by the fact that my most comprehensive checks were done only 
*after* I was forced to add a wireless bridge repeater to replace the fact 
that my Wi-Fi (and VPN tunnels) were destroyed by the use of this sequence
  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

That was catastrophic because it doesn't destroy just a driver.
It permanently wipes out the entire networking subsystem on Windows!

Luckily, I learned a lot recovering from that networking faux pas, 
so I'm not only back online, but I'm testing Wi-Fi speeds with and 
without the wireless bridge, finding out very interesting things.

In summary, the *first* thing any of us should do if we care to think about 
IPv6 privacy is to check with our ISP to find out whether they serve it.

If not, the next thing we need to learn is how to check for whether or not 
they serve it, and then whether or not our router is set up to stop it.

If they serve it and if our router can't stop it, then (and only then), 
should we think about stopping it at the host level, where the solution for 
Windows is different than Linux or Android but fundamentally the same.

Note that RFC 8981 is "partial privacy" (IMHO), because it only rotates the 
second half of the IPv6 identifier, which, for some people may be enough.

Fundamentally, RFC 8981 turns IPv6 issues back into IPv4 privacy issues.
Kind of sort of but not exactly.
-- 
Sometimes you learn everything only after you started out knowing nothing.

 

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

#194723

Richmond wrote:
>> Fundamentally, RFC 8981 turns IPv6 issues back into IPv4 privacy
>> issues.  Kind of sort of but not exactly.
> 
> My ISP provides IPV6. I switched on ProtonVPN on Android and visited
> ip.wtf and test-ipv6.com and they say there is no ipv6 address. (Brave
> browser). But without the VPN switched on there is an ipv6 address which
> I recognise as on my own network.
> 
> Quick update, I got connected to Norway and got an IPv6 address, but it
> is not one of mine, it is different at the top level. It must be
> Proton's. Same results with Firefox.
> 
> I am not sure what PSA is about, but if you are using VPN then it should
> hide your IPv6 address and either not provide one or provide one of its
> own, and that is what ProtonVPN is doing for me on Android. If it is
> letting your own IPv6 address through then it is broken. But as your ISP
> doesn't provide IPv6 I think something else must be going on.

Hi Richmond,

Thanks for that useful information about your ISP providing you IPv6
addresses where, from looking it up, it seems that the router assigns each
device a unique globally routable IP address.

As noted, there are web sites to check this, on and off VPN, where you
confirmed what I had found out independently that of all the free VPNs out
there, one that advertises IPv6 privacy is ProtonVPN (which I don't use). 

As for my situation, my free VPN which I've been using since 2013 doesn't
stop IPv6 but in my case, it turns out the WISP doesn't provide it anyway.

If the ISP did provide IPv6, then we could block it at the router.
And if we wanted to, we could block it at the device (Windows or Linux).
And, if we cared to, we could block it at the application, e.g., 
 Firefox also prefer IPv6 over IPv4 unless configured otherwise:
 about:config > network.dns.disableIPv6	> change from false to true 
Optionally, to prevent WebRTC IPv6 leaks in Mozilla-based web browsers:
 media.peerconnection.ice.no_ipv6 > change from false to true 	
 media.peerconnection.ice.default_address_only > change from false to true

Worst case, we can implement RFC 8981 privacy extensions, but they only
rotate the latter half of the IPv6 address, and even then, after time.
 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.
-- 
The journey on Usenet taught me more than the destination ever could.

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

#194816

On 20/07/2026 13:03, Carlos E. R. wrote:
> On 2026-07-20 08:45, Maria Sophia 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.*
> 
> Look up Teredo, in Windows.
> 
> In Linux, disabling Ipv6 is feasible.
> 

It's 100% feasible in Windows if you look it up or ask an AI instead of 
just guessing.

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v 
"DisabledComponents" /t REG_DWORD /d 1 /f

then reboot.

-- 
Brian Gregory (in England).

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

#194667

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

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

#194669

On 2026-07-20 21:47, David Higton 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.

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.

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

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

#194674

Carlos E. R. wrote:
>> 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.
> 
> 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.

While IPv6 privacy applies to all devices, all OSes & all browsers alike,
as Carlos noted, the specific issue this PSA is designed to uncover is not
incoming connections. The issue is (likely accidental) identity exposure.

The new issue is a globally routable IPv6 address is unique to the device. 

IPv6 removes the "all devices look the same" protection that NAT
provided. With IPv6, if an application bypasses the VPN and leaks IPv6,
the ISP sees the real IPv6 address of the device doing the torrenting

Hence, the privacy issue is not that someone can connect to you. 
As David noted, firewalls stop that. 

The issue is that the address itself is a stable identifier to a specific
device, where the key issue is identity exposure, not a firewall failure.

If an application uses IPv6 while the VPN only tunnels IPv4, the
application announces the device's real IPv6 address to the outside world. 

In terms of mainstream movie torrenting, it's of academic importance only
because nobody in the United States has ever been successfully prosecuted
for torrenting mainstream movies if they fought the charges, but nobody
wants their ISP to be getting & forwarding those DMCA letters nonetheless.

If the host never receives a global IPv6 address, there is nothing for the
browser or any application to expose. That is why the PSA focused on
removing IPv6 from the host rather than trying to block it after the fact	.

Modern browsers prefer IPv6 when it is available, and many applications
will use IPv6 even when the user believes all traffic is going through a
VPN. As Carlos pointed out, if the VPN does not tunnel IPv6, the IPv6
traffic goes out natively and carries the device's actual real identity.

A firewall can block IPv6 packets, but it cannot remove the IPv6 identity
from the host. The host still has a global IPv6 address, the browser still
prefers IPv6, the torrent client still binds to IPv6 and the OS still
advertises IPv6 capability. The application can expose the IPv6 address
before the firewall ever drops the packet. That is attribution.

Once the host has a global IPv6 address, the identity exists. 
Blocking traffic does not prevent the identity from being announced.

This is why the PSA focused only on the *simplest* way to prevent the host
from receiving an IPv6 address at all, because no IPv6 address means:
 a. nothing for the browser to expose
 b. nothing for applications to bind to
 c. nothing for the OS to advertise
 d. nothing for the VPN to bypass

I only started investigating this privacy problem a couple of days ago, so
everything I say can be wrong (and much of what I say likely is wrong), but
the epiphany that I wished to let everyone know about is that a simple
bridge (even a dumb switch) instantly stops this problem at its roots.
 modem <-> dumb bridge <-> router <-> any device <-> any browser

Even as my original goal was torrenting on VPN, everything about IPv6
equally well applies to doing anything on any OS & on any web browser.
-- 
IPv6 privacy applies to all devices, all OSes, and all browsers alike.

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

#194675

Maria Sophia  <pusvul@getTjewytR4so+mqe2.invalid> wrote:
>Carlos E. R. wrote:
>>> 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.
>> 
>> 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.
>
>While IPv6 privacy applies to all devices, all OSes & all browsers alike,
>as Carlos noted, the specific issue this PSA is designed to uncover is not
>incoming connections. The issue is (likely accidental) identity exposure.
>
>The new issue is a globally routable IPv6 address is unique to the device. 
>
>IPv6 removes the "all devices look the same" protection that NAT
>provided. With IPv6, if an application bypasses the VPN and leaks IPv6,
>the ISP sees the real IPv6 address of the device doing the torrenting
>
>Hence, the privacy issue is not that someone can connect to you. 
>As David noted, firewalls stop that. 
>
>The issue is that the address itself is a stable identifier to a specific
>device, where the key issue is identity exposure, not a firewall failure.

Don't use it as a stable identifier. Make every connection a virtual
session, assigning a different IPv6 to each dynamically to defeat
fingerprinting. This model is used by a certain server farm.

>. . . 

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

#194679

Adam H. Kerman wrote:
>>IPv6 removes the "all devices look the same" protection that NAT
>>provided. With IPv6, if an application bypasses the VPN and leaks IPv6,
>>the ISP sees the real IPv6 address of the device doing the torrenting
>>
>>Hence, the privacy issue is not that someone can connect to you. 
>>As David noted, firewalls stop that. 
>>
>>The issue is that the address itself is a stable identifier to a specific
>>device, where the key issue is identity exposure, not a firewall failure.
> 
> Don't use it as a stable identifier. Make every connection a virtual
> session, assigning a different IPv6 to each dynamically to defeat
> fingerprinting. This model is used by a certain server farm.

It took me a while to figure out the good advice being given above, where I
think the "certain server farm" may allude to large-scale cloud providers
(perhaps AWS, Google Cloud, Azure, Akamai, Cloudflare) that have the
ability to assign per-connection IPv6 addresses with dynamically rotated
IPv6 prefixes to hide internal topology behind virtualized networking.

While this is an important cloud-scale anti-fingerprinting strategy, it's
not directly relevant to the average home user who is trying to replicate
that on his own devices on his own LAN (using RFC 8981 rotation perhaps?).

The privacy issue described in this PSA for the *simplest* solution isn't
inbound exposure. Firewalls already prevent unsolicited connections. 

The privacy problem being discussed here is IPv6 outbound attribution. 

If a torrent client bypasses the VPN and uses native IPv6, the ISP sees the
device's real globally routable IPv6 address. That address uniquely
identifies one device on the LAN at that moment, which is the issue.

Dynamic per-flow IPv6 assignment is a data-center technique requiring
control over prefix delegation. Home routers and consumer ISPs do not
provide that capability, so it doesn't address the privacy leak described
in this PSA.

Carlos and others pointed out there are many possible solutions, 
where Carlos mentioned Linux offers a cleaner solution than Windows does.

Luckily, the *simplest* solution I can think of, works for all operating
systems, and for all devices on our LAN and for all applications.

  modem <-> silent bridge <-> router <-> any device <-> any browser

Where, in my specific situation, that ephiphany was accidentally learned
when I set the Windows Tcpip6 DisabledComponents to hex FF instead of 20.

Unfortunately, I learned this the hard way when I ran this step:
 reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xFF /f
When I should have run this instead (which is what everyone else does):
 reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0x20 /f

WARNING: Setting Tcpip6 DisabledComponents to hex FF permanently wipes
out the possibility of using wireless networking on a Windows computer.

Having done that, I had to switch to "wired Ethernet" by setting up a
spare wi-fi router as a bridge, which is how I learned it stops IPv6 leaks.
 modem <-> router <-> wireless bridge <-> Windows OS <-> Firefox browser 

The epiphany came out of the rubble of the mess that resulted.
-- 
Sometimes you learn what not to do only after having already done it.

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

#194678

On 2026-07-21, Maria Sophia wrote:

> Carlos E. R. wrote:
>>> 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.
>> 
>> 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.
>
> While IPv6 privacy applies to all devices, all OSes & all browsers alike,
> as Carlos noted, the specific issue this PSA is designed to uncover is not
> incoming connections. The issue is (likely accidental) identity exposure.
>
> The new issue is a globally routable IPv6 address is unique to the device. 
>
> IPv6 removes the "all devices look the same" protection that NAT
> provided. With IPv6, if an application bypasses the VPN and leaks IPv6,
> the ISP sees the real IPv6 address of the device doing the torrenting

(Or rather, the ISP sees you're torrenting. With the VPN, I gather a
side goal is also that the ISP isn't aware of that.)

[...]
> A firewall can block IPv6 packets, but it cannot remove the IPv6 identity
> from the host. The host still has a global IPv6 address, the browser still
> prefers IPv6, the torrent client still binds to IPv6 and the OS still
> advertises IPv6 capability. The application can expose the IPv6 address
> before the firewall ever drops the packet. That is attribution.

Can a firewall block the RAs themselves?

> Once the host has a global IPv6 address, the identity exists. 
> Blocking traffic does not prevent the identity from being announced.
>
> This is why the PSA focused only on the *simplest* way to prevent the host
> from receiving an IPv6 address at all, because no IPv6 address means:
>  a. nothing for the browser to expose
>  b. nothing for applications to bind to
>  c. nothing for the OS to advertise
>  d. nothing for the VPN to bypass
>
> I only started investigating this privacy problem a couple of days ago, so
> everything I say can be wrong (and much of what I say likely is wrong), but
> the epiphany that I wished to let everyone know about is that a simple
> bridge (even a dumb switch) instantly stops this problem at its roots.
>  modem <-> dumb bridge <-> router <-> any device <-> any browser
>
> Even as my original goal was torrenting on VPN, everything about IPv6
> equally well applies to doing anything on any OS & on any web browser.


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.

-- 
Nuno Silva

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

#194681

Nuno Silva wrote:
>> The new issue is a globally routable IPv6 address is unique to the device. 
>>
>> IPv6 removes the "all devices look the same" protection that NAT
>> provided. With IPv6, if an application bypasses the VPN and leaks IPv6,
>> the ISP sees the real IPv6 address of the device doing the torrenting
> 
> (Or rather, the ISP sees you're torrenting. With the VPN, I gather a
> side goal is also that the ISP isn't aware of that.)

Agree. 

The VPN is supposed to hide all torrent traffic from the ISP entirely.
An IPv6 leak defeats that goal & adds device-level attribution on top.

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.

That's why preventing the host from ever receiving a global IPv6 address
removes both problems at once. The question is what's the *simplest* fix? 

>> A firewall can block IPv6 packets, but it cannot remove the IPv6 identity
>> from the host. The host still has a global IPv6 address, the browser still
>> prefers IPv6, the torrent client still binds to IPv6 and the OS still
>> advertises IPv6 capability. The application can expose the IPv6 address
>> before the firewall ever drops the packet. That is attribution.
> 
> Can a firewall block the RAs themselves?

Good point!

Given a router advertisement is essentially the IPv6 equivalent of DHCP
announcements (except it's automatic and always present unless explicitly
blocked), as Nuno suggested, blocking RAs is indeed another extremely
simple way to prevent the host from ever receiving a global IPv6 address.

If the host never receives a global IPv6 address, then there's nothing for
a browser to expose, nothing for a torrent client to bind to and nothing
for a VPN to bypass. 

So that's two *simple* methods to ensure there is no IPv6 privacy leak:
  modem <--> silent bridge <--> router <--> device <--> application
  modem <--> router with RA blocked <--> device <--> application	 

Both flows prevent the host from ever receiving a global IPv6 address.
The caveat is that only some routers fully support proper RA suppression	.

Given that, I'm curious how many people here actually rely on IPv6 for
anything that would be affected by disabling it at the LAN boundary.	 

>> Even as my original goal was torrenting on VPN, everything about IPv6
>> equally well applies to doing anything on any OS & on any web browser.
> 
> 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.

Again, I agree fully with you on this useful networking-related suggestion.
There are at least 2 variations of the *simplest* way to prevent the IPv6
privacy issue so as to stop the host from receiving a global IPv6 address.

  modem <--> silent bridge <--> router <--> device
  modem <--> router configured for IPv4-only (RA suppressed) <--> device

Both approaches are simple enough to reliably ensure the host never gets a
global IPv6 address, so nothing can leak it (given appropriate hardware).

> 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.

Again you bring up accurate good suggestions to ponder for IPv6 privacy.

Knowing full well nobody in the USA has ever been convicted of torrenting
movies if they fought the charges & knowing that entire troll-farm legal
firms have been sanctioned and effectively put out of business for trying, 
I wasn't worried, per se, about any specific VPN or torrent client leaking.

I was simply trying to plug all the possible privacy holes on the LAN.
It's the same reason I plug all the myriad privacy holes in Mozilla.

As for why a torrent client might connect over IPv6 despite the VPN
supplying only IPv4 DNS, BitTorrent peers and trackers apparently
frequently advertise IPv6 addresses, so, if the host has IPv6 capability
the torrent client will prefer them. That's the mechanism behind any leak.

Browsers also prefer IPv6 over IPv4 unless configured otherwise:
 about:config > network.dns.disableIPv6	> change from false to true 
Optionally, to prevent WebRTC IPv6 leaks in Mozilla-based web browsers:
 media.peerconnection.ice.no_ipv6 > change from false to true 	
 media.peerconnection.ice.default_address_only > change from false to true

These three non-default settings guard against IPv6 DNS lookups, IPv6
WebRTC candidates & IPv6 preferences inside the Firefox web browser.
-- 
Usenet allows purposefully helpful people to pool their experiences.

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

#194683

On 2026-07-21 10:41, Maria Sophia wrote:
> Nuno Silva wrote:
>>> The new issue is a globally routable IPv6 address is unique to the device.
>>>
>>> IPv6 removes the "all devices look the same" protection that NAT
>>> provided. With IPv6, if an application bypasses the VPN and leaks IPv6,
>>> the ISP sees the real IPv6 address of the device doing the torrenting
>>
>> (Or rather, the ISP sees you're torrenting. With the VPN, I gather a
>> side goal is also that the ISP isn't aware of that.)
> 
> Agree.
> 
> The VPN is supposed to hide all torrent traffic from the ISP entirely.
> An IPv6 leak defeats that goal & adds device-level attribution on top.
> 
> 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.

...

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

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

#194687

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.

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

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.
-- 
It's OK to be wrong as long as we're open to learning what's right.	

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.comp.os.windows-10

csiph-web