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

Groups > alt.internet.wireless > #18878 > 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.internet.wireless

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 3 of 3 — ← Prev page 1 2 [3]

#18921

As a related aside, if your network ever does go to hell in a handbasket, 
the following manual commands seem to surgically fix mine in a flash.
a. This sequence touches every networking layer that commonly breaks.
b. Renaming interfaces removes whitespace headaches & makes scripting sane.
c. Toggling up/down forces driver rebinding and flushes stale states.
d. Setting static IP + DNS eliminates DHCP weirdness
e. The connectivity validation is in the proper escalation order
    i.   Local gateway
    ii.  Public IP
    iii. DNS resolution
    iv.  HTTP throughput
    v.   Full speed test
f. route print -4 confirms the metrics and/or stale routes
g. Resetting Winsock is the nuclear option for corrupt proxies.

One-time commands to simplify the networking scripts:
 netsh interface set interface name="Ethernet 2" newname="eth0"
 netsh interface set interface name="Wi-Fi 2" newname="wlan0"
One-time commands to set a networking metric baseline:
 netsh interface ipv4 set interface "eth0" metric=10
 netsh interface ipv4 set interface "wlan0" metric=20

Set your network for Ethernet (in my case, via a wireless router):
 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 
 At this point you can now run psiphon.bat or vpn.bat

Set your network for Wi-Fi (in my case, via a Wi-Fi NIC card):
 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"
  (note that the SSID should always be hidden broadcast!)
 netsh interface ipv4 show config
 netsh interface ipv4 show config name="wlan0"
 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 
 At this point you can now run psiphon.bat or vpn.bat
 
============================================================
Here's a networking cheat sheet if anyone needs the commands.
============================================================
 Layer 1: link & adapter state
  check NIC driver + link status
   wmic nic get Name,NetEnabled,Speed
  show adapter statistics (errors/drops)
   netstat -e
  show interface statistics
   netsh interface ipv4 show interfaces
============================================================
 Layer 2: arp & neighbor discovery
  show arp table
   arp -a
  show ipv4 neighbor cache
   netsh interface ipv4 show neighbors
  clearing arp can fix phantom MAC mappings
   arp -d *
============================================================
 Layer 3: ip configuration & routing
  show ipv4 global settings
   netsh interface ipv4 show global
  show ipv4 addresses
   netsh interface ipv4 show address
  show routing table (ipv4 only)
   route print -4
  show active tcp/udp endpoints
   netstat -an
  check for leftover VPN static routes
   route print -4
   route delete <network>
============================================================
 Layer 4: dhcp
  check dhcp server discovery
   netsh dhcp show server
  show dhcp-assigned addresses
   netsh interface ip show addresses
  force dhcp renew
   ipconfig /release && ipconfig /renew
============================================================
 Layer 5: dns
  test dns resolution
   nslookup example.com
  show dns cache
   ipconfig /displaydns
  flush dns cache
   ipconfig /flushdns
  check browser DNS-over-HTTPS interference
   Chrome:  chrome://settings/security
   Firefox: about:preferences#privacy
============================================================
 Layer 6: firewall
  show firewall rules
   netsh advfirewall firewall show rule name=all
  show firewall profile state
   netsh advfirewall show allprofiles
============================================================
 Layer 7: winsock
  show winsock providers
   netsh winsock show catalog
  reset winsock (fixes corruption)
   netsh winsock reset
  reset tcp/ip stack (deeper than winsock)
   netsh int ip reset
============================================================
 Layer 8: connectivity tests
  ping gateway
   ping <gateway>
  ping ipv4-only target
   ping -4 8.8.8.8
  trace ipv4 route
   tracert 8.8.8.8
  test ipv4 http
   curl -4 http://example.com
============================================================
 Layer 9: system logs
  open event viewer
   eventvwr.msc
  check dhcp logs
   (event viewer > microsoft > windows > dhcp-client)
  check tcp/ip logs
   (event viewer > system > tcpip)
  check ndis driver logs
   (event viewer > system > ndis)
============================================================
 Layer 10: advanced routing & bindings
  show interface metrics
   netsh interface ipv4 show interfaces
  show binding joins
   netsh interface ip show joins
  show tcp global parameters
   netsh interface tcp show global
============================================================
 Layer 11: proxy cleanup 
  show winhttp proxy
   netsh winhttp show proxy
  reset winhttp proxy
   netsh winhttp reset proxy
============================================================
 Layer 12: NIC driver rebinding
  disable NIC driver
   wmic path win32_networkadapter where NetEnabled=true call disable
  enable NIC driver
   wmic path win32_networkadapter where NetEnabled=false call enable
============================================================
Verify no leftover VPN routes
 route print -4
 route delete eth0
Some browsers override system DNS:
 about:preferences#privacy
 chrome://settings/security
-- 
On Usenet, friendly kind-hearted people help each other out daily.

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

#18908

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

You are spouting a load of meaningless gibberish.
It sounds like you are basically disabling IPv6 but coming up with a 
load of complete rubbish to make it sound like you are doing something 
more clever. YOU ARE NOT DOING ANYTHING OTHER THAN DISABLING IPv6.

-- 
Brian Gregory (in England).

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

#18911

Brian Gregory wrote:
>> 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.
> 
> You are spouting a load of meaningless gibberish.
> It sounds like you are basically disabling IPv6 but coming up with a 
> load of complete rubbish to make it sound like you are doing something 
> more clever. YOU ARE NOT DOING ANYTHING OTHER THAN DISABLING IPv6.

Hi Brian Gregory,

Thank you for being blunt, as there is no doubt you are right about this.
I was wrong. 

The reason I was wrong was simply that I read too much into the fact that I
couldn't find IPv6 once I set up the bridge after wiping out my network,
but, in reality, I didn't check the network well before I wiped it out.

The bridge, as bridges are wont to do, did nothing to the IPv6 address!

And the only reason I set up the bridge was because I wiped out networking
in my attempt to rip the heart out of Windows IPv6 routing capability.

I wrote up a recovery checklist so that anyone following this thread has
all the steps necessary to wipe out IPv6 properly (hex 20) from Windows.

And Carlos wrote up the steps so that anyone on Linux can follow suit.
Plus, I added the steps necessary to wipe IPv6 out of the Firefox browser.

So there is a *lot* of good value which came of this IPv6 privacy effort.
Thanks again for not beating around the bush to let us know what you think!
-- 
We all strive to add privacy that marketing doesn't want us to have.

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

#18914

On Wed, 22 Jul 2026 16:54:00 -0400
Maria Sophia <mariasophia@comprehension.com> wrote:

> Brian Gregory wrote:
> >> 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.  
> > 
> > You are spouting a load of meaningless gibberish.
> > It sounds like you are basically disabling IPv6 but coming up with
> > a load of complete rubbish to make it sound like you are doing
> > something more clever. YOU ARE NOT DOING ANYTHING OTHER THAN
> > DISABLING IPv6.  
> 
> Hi Brian Gregory,
> 
> Thank you for being blunt, as there is no doubt you are right about
> this. I was wrong. 
> 
> The reason I was wrong was simply that I read too much into the fact
> that I couldn't find IPv6 once I set up the bridge after wiping out
> my network, but, in reality, I didn't check the network well before I
> wiped it out.
> 
> The bridge, as bridges are wont to do, did nothing to the IPv6
> address!
> 
> And the only reason I set up the bridge was because I wiped out
> networking in my attempt to rip the heart out of Windows IPv6 routing
> capability.
> 
> I wrote up a recovery checklist so that anyone following this thread
> has all the steps necessary to wipe out IPv6 properly (hex 20) from
> Windows.
> 
> And Carlos wrote up the steps so that anyone on Linux can follow suit.
> Plus, I added the steps necessary to wipe IPv6 out of the Firefox
> browser.
> 
> So there is a *lot* of good value which came of this IPv6 privacy
> effort. Thanks again for not beating around the bush to let us know
> what you think!

You shouldn't disable IPv6. It is the current generation of Internet
Protocol. Rather then disabling it just turn on IPv6 privacy.

sysctl net.ipv6.conf.eth0.use_tempaddr = 2

If your VPN doesn't support IPv6 that's your VPN's problem. Switch to
one that does. NAT was never intended as a privacy or security feature.
When it set use_tempaddr to 2 you use different addresses for outgoing
connections and those addresses expire after a certain (configurable)
amount of time. Disabling IPv6 and only using a legacy protocol just
because you don't understand it is like shooting yourself in the foot.
Don't do it.

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

#18915

agris wrote:
>> So there is a *lot* of good value which came of this IPv6 privacy
>> effort. Thanks again for not beating around the bush to let us know
>> what you think!
> 
> You shouldn't disable IPv6. It is the current generation of Internet
> Protocol. Rather then disabling it just turn on IPv6 privacy.
> 
> sysctl net.ipv6.conf.eth0.use_tempaddr = 2
> 
> If your VPN doesn't support IPv6 that's your VPN's problem. Switch to
> one that does. NAT was never intended as a privacy or security feature.
> When it set use_tempaddr to 2 you use different addresses for outgoing
> connections and those addresses expire after a certain (configurable)
> amount of time. Disabling IPv6 and only using a legacy protocol just
> because you don't understand it is like shooting yourself in the foot.
> Don't do it.

This thread has been a learning experience for me & hopefully for others.
To be clear, I'll never disagree with a logically defensible viewpoint.

While NAT was never a security feature and while IPv6 is a modern Internet
protocol, we must agree RFC 8981 privacy extensions exist for a reason.

As you noted, RFC 8981 enabling of IPv6 Privacy Extensions generates
temporary, randomized outgoing addresses which rotate periodically.
 sysctl net.ipv6.conf.eth0.use_tempaddr = 2

Meanwhile, the stable IPv6 address remains available for inbound
connections, but outbound traffic uses those ephemeral identities.	.

With that in mind, this is one of those technical debates where smart
people land on different sides because the trade-offs aren't trivial.
 a. VPN leaks are a real, practical concern. 
 b. IPv6 privacy extensions aren't a magic shield. 
 c. Some users simply don't need IPv6 yet. 		

Whether unilaterally disabling IPv6 is "shooting yourself in the foot"
depends on whether or not we need IPv6 in the first place. Do we?

I would ask everyone here who cares about this topic to ask themselves...
Q1: Do you use any services, apps, or devices that require direct 
    inbound connections from the internet (such as hosting a game server, 
    running a self-hosting services, or accessing your network remotely)?
Q2: Do you ever use a VPN (either always, often, or occasionally) 
    for privacy, work, or bypassing geo-restrictions?
Q3: When you use VPNs, is your priority mainly IP obfuscation or security?
Q4: Does your ISP currently give you an IPv6 address?
Q5: Do you ever connect multiple devices through your home network 
    (PC, phone, tablet, smart TV, etc.) and care about them communicating 
    smoothly with each other (such as with file sharing, casting, local
    streaming, or LAN gaming)?
Q6: Do you ever use modern devices or apps that require IPv6 to work 
    such as smart-home devices, peer-to-peer apps, or anything that 
    requires "IPv6 connectivity" in its settings?

The point of these questions is to ascertain if we even need IPv6.
For example, 
 a. I do not host anything that needs IPv6
 b. I don't have apps that require IPv6
 c. My WISP doesn't even give me IPv6
 d. I bittorrent only through a VPN
 e. When I switch networks (e.g., a hotspot) I only care about privacy

So, in my case, IPv6 adds no value and only leaks my real identity.
Even if my ISP does not give me IPv6, my devices device (Windows, Linux,
Android, etc.) & browsers will still try to use IPv6 whenever possible.	 

At home, IPv6 is NOT a privacy threat because there is nothing to leak.

But when my device is *outside* my network (admittedly, that's for laptops
and phones), the device will happily use IPv6 which leaks our identities.

When I go to the public library and connect my phone & laptop to their
Wi-Fi network, the laptop & phone get an IPv6 address which websites see.

But the latter half of that IPv6 address is unique to the device!
However, when I just looked that up, I found something we haven't stated.
 A. Android rotates temporary IPv6 addresses regularly
 B. Windows 10/11 generates temporary IPv6 addresses by default
 C. Most Linux variants enable IPv6 privacy extensions by default

Android, Windows, and modern Linux all use temporary IPv6 addresses!
By default.

Windows uses two timers:
 a. Preferred lifetime (generally 24 hours)
 b. Valid lifetime (generally 7 days)

Android rotates temporary IPv6 addresses every 24 hours.

Modern Linux distros ship with:
 net.ipv6.conf.default.use_tempaddr = 2
 net.ipv6.conf.all.use_tempaddr = 2
 a. Preferred lifetime (generally 24 hours)
 b. Valid lifetime (generally 7 days, but this isn't used in most Linux's)

Since our IPv6 temporary address (RFC 8981) lasts ~24 hours, we're
trackable if we, for example visit the same network twice in a day.

Two visits to the same website on the same day, from home, could be linked.
 a. With IPv4 they know it's the same household. 
 b. With IPv6 they know it's the same device.

Please correct me if I'm wrong, as the whole point is to understand IPv6.
-- 
Once we understand the complexities, the whole thing becomes very simple.

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

#18917

On 23/07/2026 04:06, Maria Sophia wrote:
> agris wrote:
>>> So there is a *lot* of good value which came of this IPv6 privacy
>>> effort. Thanks again for not beating around the bush to let us know
>>> what you think!
>>
>> You shouldn't disable IPv6. It is the current generation of Internet
>> Protocol. Rather then disabling it just turn on IPv6 privacy.
>>
>> sysctl net.ipv6.conf.eth0.use_tempaddr = 2
>>
>> If your VPN doesn't support IPv6 that's your VPN's problem. Switch to
>> one that does. NAT was never intended as a privacy or security feature.
>> When it set use_tempaddr to 2 you use different addresses for outgoing
>> connections and those addresses expire after a certain (configurable)
>> amount of time. Disabling IPv6 and only using a legacy protocol just
>> because you don't understand it is like shooting yourself in the foot.
>> Don't do it.
> 
> This thread has been a learning experience for me & hopefully for others.
> To be clear, I'll never disagree with a logically defensible viewpoint.
> 
> While NAT was never a security feature and while IPv6 is a modern Internet
> protocol, we must agree RFC 8981 privacy extensions exist for a reason.
> 
> As you noted, RFC 8981 enabling of IPv6 Privacy Extensions generates
> temporary, randomized outgoing addresses which rotate periodically.
>   sysctl net.ipv6.conf.eth0.use_tempaddr = 2
> 
> Meanwhile, the stable IPv6 address remains available for inbound
> connections, but outbound traffic uses those ephemeral identities.	.
> 
> With that in mind, this is one of those technical debates where smart
> people land on different sides because the trade-offs aren't trivial.
>   a. VPN leaks are a real, practical concern.
>   b. IPv6 privacy extensions aren't a magic shield.
>   c. Some users simply don't need IPv6 yet. 		
> 
> Whether unilaterally disabling IPv6 is "shooting yourself in the foot"
> depends on whether or not we need IPv6 in the first place. Do we?
> 
> I would ask everyone here who cares about this topic to ask themselves...
> Q1: Do you use any services, apps, or devices that require direct
>      inbound connections from the internet (such as hosting a game server,
>      running a self-hosting services, or accessing your network remotely)?
> Q2: Do you ever use a VPN (either always, often, or occasionally)
>      for privacy, work, or bypassing geo-restrictions?
> Q3: When you use VPNs, is your priority mainly IP obfuscation or security?
> Q4: Does your ISP currently give you an IPv6 address?
> Q5: Do you ever connect multiple devices through your home network
>      (PC, phone, tablet, smart TV, etc.) and care about them communicating
>      smoothly with each other (such as with file sharing, casting, local
>      streaming, or LAN gaming)?
> Q6: Do you ever use modern devices or apps that require IPv6 to work
>      such as smart-home devices, peer-to-peer apps, or anything that
>      requires "IPv6 connectivity" in its settings?
> 
> The point of these questions is to ascertain if we even need IPv6.
> For example,
>   a. I do not host anything that needs IPv6
>   b. I don't have apps that require IPv6
>   c. My WISP doesn't even give me IPv6
>   d. I bittorrent only through a VPN
>   e. When I switch networks (e.g., a hotspot) I only care about privacy
> 
> So, in my case, IPv6 adds no value and only leaks my real identity.
> Even if my ISP does not give me IPv6, my devices device (Windows, Linux,
> Android, etc.) & browsers will still try to use IPv6 whenever possible.	
> 
> At home, IPv6 is NOT a privacy threat because there is nothing to leak.
> 
> But when my device is *outside* my network (admittedly, that's for laptops
> and phones), the device will happily use IPv6 which leaks our identities.
> 
> When I go to the public library and connect my phone & laptop to their
> Wi-Fi network, the laptop & phone get an IPv6 address which websites see.
> 
> But the latter half of that IPv6 address is unique to the device!
> However, when I just looked that up, I found something we haven't stated.
>   A. Android rotates temporary IPv6 addresses regularly
>   B. Windows 10/11 generates temporary IPv6 addresses by default
>   C. Most Linux variants enable IPv6 privacy extensions by default
> 
> Android, Windows, and modern Linux all use temporary IPv6 addresses!
> By default.
> 
> Windows uses two timers:
>   a. Preferred lifetime (generally 24 hours)
>   b. Valid lifetime (generally 7 days)
> 
> Android rotates temporary IPv6 addresses every 24 hours.
> 
> Modern Linux distros ship with:
>   net.ipv6.conf.default.use_tempaddr = 2
>   net.ipv6.conf.all.use_tempaddr = 2
>   a. Preferred lifetime (generally 24 hours)
>   b. Valid lifetime (generally 7 days, but this isn't used in most Linux's)
> 
> Since our IPv6 temporary address (RFC 8981) lasts ~24 hours, we're
> trackable if we, for example visit the same network twice in a day.
> 
> Two visits to the same website on the same day, from home, could be linked.
>   a. With IPv4 they know it's the same household.
>   b. With IPv6 they know it's the same device.
> 
> Please correct me if I'm wrong, as the whole point is to understand IPv6.

Sounds right.
In theory you can change things so that RFC 8981 privacy addresses 
change more often, but I believe it isn't often simple to do and can 
cause unexpected problems in certain situations. Plus, of course, it has 
to be done once on each device you want to keep private.

-- 
Brian Gregory (in England).

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

#18920

Brian Gregory wrote:
>> Two visits to the same website on the same day, from home, could be linked.
>>   a. With IPv4 they know it's the same household.
>>   b. With IPv6 they know it's the same device.
>> 
>> Please correct me if I'm wrong, as the whole point is to understand IPv6.
> 
> Sounds right.
> In theory you can change things so that RFC 8981 privacy addresses 
> change more often, but I believe it isn't often simple to do and can 
> cause unexpected problems in certain situations. Plus, of course, it has 
> to be done once on each device you want to keep private.

Thanks Brian for checking me as I never even looked at IPv6 until I started
modifying the LiquidVPN killswitch (which simply removed the gateway)
because when I changed from a USB dongle Wi-Fi on my Ethernet-only desktop,
the Wi-Fi card I added was so much more complex, that Windows "fixed
itself" every time I wiped out the gateway, so the killswitch didn't work.

When I started writing that killswitch, I ran into IPv6 considerations for
the first time, which I never thought about since I didn't use IPv6.

What I didn't know was that EVERYTHING uses IPv6 if it can, nowadays.

So, for example, in the IPv4-only days, if I take a device (phone or
laptop) to a local hotspot, and visit a website twice within the same day,
then they only know that "something" connected from that particular site.

But, in these dual-stack IPv4+IPv6 days, all our device operating systems
and browsers prefer IPv6 over IPv4 so we connect using the IPv6 IP address.

Now, if I take a device (phone or laptop) to a local hotspot, and visit a
website twice within the same day, now they know that the "same device"
connected from that particular site, which is a recent elevation to me.

That "oh shit!" moment is the same as when I realized that the pixel
imperfections in two camera photos uniquely identifies that same camera,
such that if I post two photos to two websites, anyone scraping those two
web sites can tell both pictures were taken from the same camera.

Only after those "oh shit!" moments can I begin to implement ameliorations.

Hence, I thank you for correcting all my false statements about IPv6
privacy, as I love it when someone sets me straight on my assumptions.
-- 
Of the million things we need to know about privacy, most know 3.

[toc] | [prev] | [standalone]

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

Back to top | Article view | alt.internet.wireless

csiph-web