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

Look up Teredo, in Windows.

In Linux, disabling Ipv6 is feasible.

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

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.

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.

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.

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.

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$ snipped-for-privacy@nnrp.usenet.blueworldhosting.com>

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.

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

Can a firewall block the RAs themselves?

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.

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.

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?

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?

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.

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

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.

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.

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.

...

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.

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.

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

Here are the common scenarios:

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

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

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

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

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

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

The third case is exactly why many VPN providers either:

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

### Is it a bug?

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

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

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

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

### Why torrenting makes this more obvious

BitTorrent is unusual because:

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

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

### So who is right?

You're both partly right:

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

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

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.

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$ snipped-for-privacy@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$ snipped-for-privacy@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$ snipped-for-privacy@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.