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

Carlos E. R. wrote:

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
   formatting link
   (Windows) firefox
   formatting link
   (Linux) xdg-open
   formatting link
   (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
   formatting link
   firefox
   formatting link
   7. Test IPv6 prefix delegation dhclient -6 -v (Linux/Android Termux) 8. Test for VPN leaks firefox
   formatting link
   firefox
   formatting link
   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
   formatting link
   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

May I ask others out there what your IPv6 results were with Firefox?

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

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

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

Edit:

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

Find this line:

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

Uncomment it:

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

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

### What this does

Suppose a host has both:

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

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

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

### What it does *not* do

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

### Why it exists

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

### Is this useful for avoiding VPN leaks?

Not really. It reduces the chance that applications will choose IPv6, but it doesn't eliminate it. If your concern is privacy or ensuring that

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

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.

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

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.

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.

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

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.

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)

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?

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.

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

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.

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

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

These steps are useful for anyone to save into their debugging checklist.

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.

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.

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!

Richmond wrote:

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

Specifically for

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.

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.

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.

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.

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.