From Newsgroup: alt.os.linux

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 IPv6rCasilent bridge ends them.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Richmond wrote:

If a router is in bridge mode (no IPv6 delegation, no prefix
assignment), all connected devices never receive a global IPv6
address. *No global IPv6 address = nothing for the browser to leak.*

Doesn't this depend on whether the ISP supports IPV6? Why is it
necessary to use bridged mode to disable IPV6? my router can switch
off IPv6 without bridged mode? How do you make use of NAT in bridged
mode? Does each device get its own IPV4 address from the ISP?

Furthermore, I don't think it is leaking an ipv6 address, that is what
it is supposed to do, give every device its own public IP address.

Hi Richmond,

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

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

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

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

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

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

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

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

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

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

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

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

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

From Newsgroup: alt.os.linux

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.

. . .

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-07-21, Maria Sophia wrote:

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

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

I guess you'd have the same issue if you were on IPv4 with no NAT and
the VPN only offered IPv6.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Nuno Silva wrote:

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

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

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

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

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

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

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

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

That's the privacy leak.

Given modern Mozilla/Chromium browsers prioritize IPv6 over IPv4,
the practical privacy issue discussed in this PSA isn't limited to VPNs.

The privacy leak occurs because the host has a IPv6 identity available.

Hence, this PSA suggests the *simplest* effective privacy solution is...
modem <--> silent bridge <--> router <--> any device <--> any application

Although, there are other solutions, all of which are more complex (IMHO).

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

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

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

From Newsgroup: alt.os.linux

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-07-21 08:59, Nuno Silva wrote:

On 2026-07-21, Maria Sophia wrote:

Carlos E. R. wrote:

Two things:

Yeah, if you want to remove IPv6 from the equation, if you have e.g. a "router" device with a wireless AP that can be configured to handle (and
hand out) only IPv4, configuring it so and connecting through it would
be a way to be more confident that the issue wouldn't arise.

Were this another network application and protocol, I'd wonder what's prompting the software to connect over IPv6, given the VPN should
provide DNS with IPv4 only, but I'm guessing this is about IPv6
addresses in bittorrent, either of peers or of trackers.

If the torrent application connects outside of the VPN, this is a bug
that should be reported to the app developers. Or to the developers of
the VPN software. I'm unsure which is at fault.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

Were this another network application and protocol, I'd wonder what's
prompting the software to connect over IPv6, given the VPN should
provide DNS with IPv4 only, but I'm guessing this is about IPv6
addresses in bittorrent, either of peers or of trackers.

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

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

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

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

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

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

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

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

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

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

From Newsgroup: alt.os.linux

On 2026-07-21 11:19, Maria Sophia wrote:

Carlos E. R. wrote:

Were this another network application and protocol, I'd wonder what's
prompting the software to connect over IPv6, given the VPN should
provide DNS with IPv4 only, but I'm guessing this is about IPv6
addresses in bittorrent, either of peers or of trackers.

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

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

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

Nono. It is a bug or an error somewhere.

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


I asked chatgpt about it.

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

A:

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

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

Here are the common scenarios:

1. **VPN supports IPv6 properly** rLoN+A

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

2. **VPN only tunnels IPv4 but disables IPv6** rLoN+A

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

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

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

The third case is exactly why many VPN providers either:

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

### Is it a bug?

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

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

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

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

### Why torrenting makes this more obvious

BitTorrent is unusual because:

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

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

### So who is right?

You're both partly right:

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

The important question is whether the VPN provider advertises "full IPv6 protection." If it does, and IPv6 still escapes, then that's a fault
relative to the product's expected behavior. If the provider explicitly
says "we only tunnel IPv4" and leaves IPv6 enabled, then the behavior is expected, even if it's undesirable for someone who wants all traffic protected.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

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

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

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

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

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

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

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

I couldn't believe my eyes.

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

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

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

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

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

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

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

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

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

From Newsgroup: alt.os.linux

On 2026-07-21 11:47, Maria Sophia wrote:

Carlos E. R. wrote:

With IPv4 + NAT, all devices share one public address, so the ISP can't
tell which device is doing what. With IPv6, each device has its own
globally routable address, so any IPv6 leak identifies both the activity >>> and the specific device.

Ah, no. This is precisely what the RFC 8981 IPv6 privacy extensions are
for. The second part of the address rotates, so that nobody outside can
track what machine inside of the router is talking.

The router knows, but the router is yours and you can erase the logs.

Carlos brings up a good point about RFC 8981 IPv6 privacy extensions where
we need to distinguish between tracking over time against identifying the device right now because there are two parts to an IPv6 address.
1. The prefix (this is fixed as it does not rotate under RFC 8981)
2. The interface identifier (this is the part RFC 8981 rotates)

Only recently did I learn about RFC 8981 in the Windows ng but from what
I've researched, AFAIK, RFC 8981 does not hide the device from the ISP.
a. Therefore, AFAIK, RFC 8981 does not prevent device attribution.
b. RFC8981 privacy extensions do not prevent VPN bypass.
c. RFC8981 privacy extensions do not prevent IPv6 leaks.

Given the prefix remains fixed, RFC 8981 cannot hide the device from the
ISP as RFC 8981 only rotates the interface identifier half of the address.

What remains of IPv6 reveals both the subscriber and the specific device. Short term or long term, RFC 8981 does nothing to prevent that prefix leak.

To be clear, RFC 8981 privacy extensions are likely great, but AFAIK, they only prevent long-term correlation of activity across different networks.

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

Only the router owner knows, if he wants.

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

Based on my research (which we discussed in the Windows 10 newsgroup prior) privacy extensions rotate only interface identifiers, not prefixes.

That means, if I'm correct, that even with RFC-8981 privacy extensions...
a. Websites see our IPv6 prefix
b. Websites know which household the traffic comes from
c. Websites can correlate all our temporary IPv6 addresses to that prefix
d. Websites can still identify your home even if the IID rotates

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

When RFC 8981 was first suggested on the Windows ng, I thought that was the panacea but the prefix is the part that ties all our IPv6 activity to our home but RFC 8981 doesn't do anything (as far as I can tell) to the prefix.

As far as I can tell, RFC 8981 does not hide our household identity.
It only hides our device identity, and even that, only over time. .

Given the prefix remains fixed, even with RFC 8981 privacy extensions,
the ISP and any IPv6-reachable website can still correlate all IPv6 activity-short-term and long-term-to the subscriber's household.

Correct me if I'm wrong as I am here to learn so if I'm wrong, say so.

--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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
roLroCroC A 203.0.113.5
rooroCroC 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.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

To be clear, RFC 8981 privacy extensions are likely great, but AFAIK, they >> only prevent long-term correlation of activity across different networks.

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

Only the router owner knows, if he wants.

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

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

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

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

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

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

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

Based on my research (which we discussed in the Windows 10 newsgroup prior) >> privacy extensions rotate only interface identifiers, not prefixes.

That means, if I'm correct, that even with RFC-8981 privacy extensions...
a. Websites see our IPv6 prefix
b. Websites know which household the traffic comes from
c. Websites can correlate all our temporary IPv6 addresses to that prefix
d. Websites can still identify your home even if the IID rotates

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

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

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

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

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

From Newsgroup: alt.os.linux

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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!


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-07-21, Maria Sophia wrote:

Nuno Silva wrote:

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

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

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

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

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

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

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

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

That's the privacy leak.

Given modern Mozilla/Chromium browsers prioritize IPv6 over IPv4,
the practical privacy issue discussed in this PSA isn't limited to VPNs.

The privacy leak occurs because the host has a IPv6 identity
available.

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

Hence, this PSA suggests the *simplest* effective privacy solution is...
modem <--> silent bridge <--> router <--> any device <--> any application

Although, there are other solutions, all of which are more complex (IMHO).

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

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

Who here is actually using IPv6 for anything that would be impacted?

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

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

Not that I'm taking advantage of that on Android. (Yet. :-P)
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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

On 2026-07-21 08:59, Nuno Silva wrote:

Two things:

Yeah, if you want to remove IPv6 from the equation, if you have e.g. a
"router" device with a wireless AP that can be configured to handle (and
hand out) only IPv4, configuring it so and connecting through it would
be a way to be more confident that the issue wouldn't arise.

Were this another network application and protocol, I'd wonder what's
prompting the software to connect over IPv6, given the VPN should
provide DNS with IPv4 only, but I'm guessing this is about IPv6
addresses in bittorrent, either of peers or of trackers.

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

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

From Newsgroup: alt.os.linux

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.



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Nuno Silva wrote:

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

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

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

UPDATE:

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

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

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

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

As a result both Wi-Fi and VPNs were completely & permanently dead.
Wi-Fi didn't work because it depends on a ton of things now removed!
a. NetworkUX
b. OOBENetwork packages
c. NetworkConnectionFlow
d. immersivecontrolpanel dependencies
e. ShellExperienceHost networking hooks
f. Edge legacy system package
g. CBS servicing metadata
h. RPC endpoint mapper entries
VPN didn't work because the connection depends on the OS routing table.

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

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

This kept me online long enough to perform recovery using the MCT Media Creation Tool & Rufus to create a MBR (BIOS + UEFI) recovery USB stick.

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

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

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

From Newsgroup: alt.os.linux

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).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 20/07/2026 20:59, Carlos E. R. wrote:

Because he is torrenting via a tunnel to VPN servers. Apparently the torrrent app bypasses the VPN and connects directly via IPv6, so his identity becomes known.

So he should complain about his VPN client then. NOT ABOUT IPv6.
What a cry baby.
--
Brian Gregory (in England).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Brian Gregory wrote:

On 20/07/2026 20:59, Carlos E. R. wrote:

Because he is torrenting via a tunnel to VPN servers. Apparently the
torrrent app bypasses the VPN and connects directly via IPv6, so his
identity becomes known.

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

Hi Brian Gregory,

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

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

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

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

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

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

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

From Newsgroup: alt.os.linux

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Nuno Silva wrote:

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

If what you're trying to avoid is legal action from the MAFIAA or
actions from the ISP itself, then it really doesn't matter if it's the
NATed IPv4 address which gets leaked or an IPv6 one. Both would point to
your subscription with the ISP.

Hi Nuno Silva,

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

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

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

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

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

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

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

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

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

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

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

From Newsgroup: alt.os.linux

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.





























--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 22/07/2026 21:46, Maria Sophia wrote:

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

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

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

Although I always run dual stack when I can and tend to urge others to
do so too, I do accept that running IPv4 only is a valid option if you
have certain priorities, that differ from mine.
--
Brian Gregory (in England).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-07-23, Brian Gregory wrote:

On 22/07/2026 21:46, Maria Sophia wrote:

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

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

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

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

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

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

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


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

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

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

--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Nuno Silva wrote:

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

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

And, of course, for most people, with only one LAN, using only a
single /64 the first half of the IPv6 address gives away no more than
your IPv4 address gives away -- that it's something of yours.
Although I always run dual stack when I can and tend to urge others to
do so too, I do accept that running IPv4 only is a valid option if you
have certain priorities, that differ from mine.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Then, inside the VPN tunnel, we can explicitly set the DNS servers.
dhcp-option DNS 1.1.1.1 ; set primary DNS to Cloudflare inside the tunnel
dhcp-option DNS 9.9.9.9 ; set secondary DNS to Quad9 for secure fallback

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

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

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


































.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

David Higton <dave@davehigton.me.uk> wrote:

In message <113kg6k$s72$1@nnrp.usenet.blueworldhosting.com>
Maria Sophia <mariasophia@comprehension.com> wrote:

PSA:
IPv6 browser privacy leaks are caused by the host, yet there's a fix.
ISP modem > IPv6-silent bridge > normal home router > Wi-Fi devices

On all platforms, web browsers can leak your globally-routable IPv6
address (even when you're using a VPN). This IPV6 privacy leak happens
because the browsers prefer IPv6 and the OS host itself participates in
IPv6 routing.

I don't understand why you think there's a problem. Very much the whole point of IPv6 is that all your globally routable IPv6 addresses are,
well, globally routable. I'd be happy for the whole world to know what
mine are.

The only ports that are open on any of these addresses to incoming connections are as a result of my opening a pinhole in the firewall.

So, knowing your globally routable addresses is one thing. Allowing connections in to any of them is entirely another matter.

David

NSA-coded post right here lol.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Oregonian Haruspex wrote:

NSA-coded post right here lol.

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

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

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

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

I tried to make it fancier with curlvpn but that errored out on Windows:
TARGET=%comspec% /k echo "curlvpn: forcing curl through VPN TAP adapter" & %Windir%\System32\curl.exe --interface Ethernet --dns-servers 1.1.1.1,9.9.9.9 icanhazip.com
I'm sure that curl syntax would work if curl were compiled differently.
"curlvpn: forcing curl through VPN TAP adapter"
curl: option --dns-servers: the installed libcurl version does not support this
curl: try 'curl --help' for more information

But I like my commands to work universally so I changed it to
Win+R > curldns
Which calls curldns.exe which is defined only in the Windows Registry
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\curldns.exe
Default=C:\path-to\curldns.lnk
Where the TARGET of that curldns.lnk shortcut does the IP check.
%comspec% /k echo "C:\data\sys\pgm\lnk\curldns.lnk $MYIP" & echo curldns & nslookup icanhazip.com & powershell -Command "Resolve-DnsName icanhazip.com" & curl icanhazip.com
NB: There is no command called "curldns.exe"; that's just a reg keyword.

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

From Newsgroup: alt.os.linux

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.
-a-a-a-a *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).
--- Synchronet 3.22a-Linux NewsLink 1.2