Ah, OK. I don't really find that too compelling, to be honest - what's your NAT buying you if you don't have many users to mix your traffic with?

I live alone and as far as I can see, all my NAT does for my privacy is a smidgen of plausible deniability (maybe a visitor on my guest wifi made that request), and that you can't tell which of my devices I'm using when I access a particular service - which is a small privacy win, but not a meaningful one in my book. Even for what I imagine is the common case of a family sharing one router, I'd guess it's usually not challenging to distinguish traffic between the relatively small number of potential users/devices.

If you're lucky(?) enough to be behind a NAT with enough hosts to be meaningful privacy-wise (dozens? hundreds?), and whoever's running this NAT isn't keeping logs about it (do they? honestly don't know), then you might be seeing a significant privacy upside. But it's not built-in to the protocol, and just adding a NAT doesn't buy you any privacy by itself.

I think the problem is that the privacy enhancing part of NAT is an emergent side-effect, not the main goal. Now it's got me thinking there should be something like NAT but explicitly targeted to privacy, like guaranteeing that your traffic is mixed through an IP that minimum a hundred other people are using. Or something like that.

> If you're lucky(?) enough to be behind a NAT with enough hosts to be meaningful privacy-wise (dozens? hundreds?), and whoever's running this NAT isn't keeping logs about it (do they? honestly don't know), then you might be seeing a significant privacy upside.

I worked out of a co-working space for a while that were explicit about not logging anything on their NATed shared internet connection. I saw more Google captchas using that (without a VPN) that I’d even see with TOR. After I left, a friend I’d made there told me they eventually found out someone there was doing seriously blackhat seo stuff and they kicked him out. Took a few months but eventually all the captchas went away.

As those unique "fresh" addresses would have to come from some shared routable prefix (which is the core problem with the various IPv6 randomized address solutions), that would still provide strictly worse privacy than NAT: if you happened to be one machine before you are now outing to the world the connection correlations between your tabs, and if you were multiple machines before you are now separating the traffic from the multiple users; meanwhile, no one thinks you are a large number of unrelated addresses (as no one is dumb enough to be tricked by your supposedly-separate addresses that all share the same prefix).

FWIW, one can totally implement NAT for IPv6, and in fact people have: everyone should always use NAT. NAT is the correct solution to this problem, whether you are mixing your traffic locally on your own network or are shifting your traffic through remote mixers (which is effectively what Orchid--the open source decentralized privacy network I work on, funded by some major VCs--does, though it frankly isn't there yet with "#privacy" despite having launched a long time ago and being usable today; btw: I haven't finished implementing this yet, but "use a separate circuit for each target host", which I think best achieves your dream of an address per tab, is one of the features I have been intending to have in Orchid for forever ;P).

(It makes sense for me to attach this to this comment, but I appreciate I am likely preaching the choir with respect to responding to you ;P.) The downsides people like to whine about for NAT involving peer-to-peer connections and hole punching are either misunderstandings (people often like to claim things don't work that do), are caused by shitty NAT implementations (that ignore the RFC recommendations on NAT), or were fixed by PCP/NAT-PMP (which is the technology everyone should be implementing support for in their software stacks, not IPv6).

(With respect to the attack in this article, this isn't an attack on NAT per se: it is an attack on these "application level gateways", which I frankly had always assumed were a "crazy" Linux IPMASQ feature, not something people were using in production. I appreciate why people are doing this: no one integrates PCP/NAT-PMP, and there exist older notably unencrypted and thereby already somewhat unfortunate protocols--such as FTP and SIP--that have port allocation assumptions that the router is trying to fix with heuristics. This mechanism doesn't work if the traffic is encrypted anyway--and all of these protocols support encryption as of 15 years ago, and a lot of users actually did switch--so I will claim these features should not be deployed: developers should use PCP/NAT-PMP in their clients or we should potentially integrate it into their operating systems, and not pretend that ALGs are much more than a dangerous MITM attack.)

> some shared routable prefix ... still provide strictly worse privacy than NAT

Why can't you share the prefix at the network level (ie where the NAT currently resides)? Just use cryptography to randomly distribute your device local prefix across that of the entire network.

For example (there's almost certainly a better way to do this), distribute a shared key when you assign device local prefixes via DHCP. To get a new address, allocate from the local prefix, encrypt with the shared key, and (slight hand waving here) map back into the network prefix. This will produce a pseudorandom distribution that is guaranteed not to overlap other devices (that use the same shared key OFC).

Depending on how downstream software made use of it, you might actually end up with better privacy characteristics than NAT. For example, an IPv6 address per browser tab mixed across multiple devices means that an adversary now has to do some amount of work just to reconstruct the range of the prefix that's being shared (where before NAT gave this information to them more or less for free).

You don't need to come up with this shared-key-DHCP scheme. SLAAC addresses already do this with privacy extensions, using NDP to resolve collisions (which are rare anyway, since the random identifier is 48 bits long).

Whoops I didn't realize the privacy extensions had managed to address this already. In other words, just collide and fix it up later.

Are you necessarily guaranteed 48 bits of address space though? Can't an ISP assign you any size prefix they like? A scheme that only works reliably (how efficiently does NDP resolve collisions?) on networks that observe some arbitrary convention seems like a bad idea to me.

The subnet prefix is a /64. Out of the remaining 64 bits, 16 bits are reserved to be FFFE. The remaining 48 bits used to be your MAC, and with privacy extensions are random.

I don't know how SLAAC works if the gateway's subnet is smaller than a /64. But I doubt any ISP would give you anything smaller than a /64; it'll create problems on their end with no benefit due to larger routing tables (which is the reason NDP exists for routing within a subnet in the first place).

It's not "collide and fix it up later". IIRC NDP is used to check for anything using the new address at the moment, and if it isn't then the device starts using it. NDP is already a core part of IPv6 (it's the only way to route within a subnet) so I don't think you have to worry about perf.

Sorry, I think I didn't articulate very well. It's not just ISPs, can't we arbitrarily nest networks? And you might foreseeably desire privacy on one of these interior LANs. Or perhaps your ISP is abusive and you can't switch for some reason. I dunno. (I know, it's not expected to be an issue in practice, but edge cases bother me.)

At what point (if any) will a scheme relying on NDP begin to break down due to collisions becoming unacceptably expensive to resolve? 16 bits of address space? 10 bits? Or is the algorithm behind NDP so robust that it will work right up until the network is completely full, with every last available address in active use?

>It's not just ISPs, can't we arbitrarily nest networks?

You really don't want to have subnets smaller than /64. It's not worth it.

If you do have smaller subnets, all the subnets that together make up the /64 must be configured to share NDP messages with each other, this is called NDP proxying. But again, the point is IPv6 is specifically designed so that routing stops at the /64 level and uses NDP after that. So don't make subnets smaller than /64.

>And you might foreseeably desire privacy on one of these interior LANs. Or perhaps your ISP is abusive and you can't switch for some reason. I dunno.

If you want multiple subnets, ask your ISP to give you a larger block than a /64. They are likely to do so. In the US you have anywhere from tunnelbroker giving you a /48 if you want, to residential ISPs giving you at least a /60 if not a /56 if your router asks for it.

>At what point (if any) will a scheme relying on NDP begin to break down due to collisions becoming unacceptably expensive to resolve?

NDP is just ICMP messages. It doesn't scale with the number of devices like opening a new TCP connection with every other device on the subnet or something. You broadcast a message and wait for a response. Every time a new device connects to a subnet it has to use NDP to find the router. In the same way every time a device chooses a new SLAAC (privacy extensions) IP, it has to use NDP to find a collision. Every device on the subnet is getting every NDP packet anyway, because that's how subnets work.

>Or is the algorithm behind NDP so robust that it will work right up until the network is completely full, with every last available address in active use?

Thinking of edge cases is fine, but this edge case requires having 200 trillion (2^48, 2.8E14) devices on a single subnet. It's very unrealistic.

Thanks for taking the time to explain this stuff!

> IPv6 is specifically designed so that routing stops at the /64 level and uses NDP after that

I thought IPv6 also supported subnets, DHCP, and static configuration, just like IPv4? Have I misunderstood? If SLAAC and NDP specifically require the full /64 that's fine, I just don't understand what the upsides to such a design choice would be. (But I'm obviously not a networking expert!)

> > perhaps your ISP is abusive

> If you want multiple subnets, ask your ISP to give you a larger block than a /64.

Long ago, I recall an ISP that charged extra for more than one active device. Their supplied router was perfectly capable of NAT but you had to pay extra if you wanted to use it (and there were multiple service tiers depending on how many devices you had). Obviously, the only reasonable way to proceed was to NAT everything using your own router behind theirs.

That particular practice seems unlikely to fly these days, but the point is that if an artificial restriction is possible to implement or information is freely available such capabilities will almost inevitably be abused by bad actors (see browser fingerprinting for a concrete example).

> NDP is just ICMP messages. It doesn't scale with the number of devices

Sorry, it seems I'm really bad at articulating this particular question about scaling. I was specifically wondering about a much smaller subnet, say 2^16. Once a significant fraction (say 90%) of the address space is being utilized, any attempt to select a new address at random should result in a proportional number of collisions. So if you were regularly cycling addresses, it seems there would be a _lot_ of overhead in that case.

> Every device on the subnet is getting every NDP packet anyway, because that's how subnets work.

That seems like it would break down at some point. Which is (one of the reasons, I thought) why subnets and VLANs and all that other stuff existed. If the answer is just "put that stuff in a block larger than /64" that's fine, I'd just never heard that before and don't understand the reasoning behind it. (It's not as though a single subnet is ever expected to exceed 2^32 active addresses?! So why insist on having 2^48?)

Privacy addresses rely on SLAAC, which requires /64s, which means you have a 2^64 space to pick random addresses from. I'd expect collisions to be rare up to about the square root of that (essentially this is a birthday attack), i.e. 2^32 active IPs.

NDP actually uses multicast, so your switches can filter out some of the NDP traffic so that only devices with IPs that share the last 24 bits will receive the NDP query. That should make it possible to scale a subnet to a substantially larger size than would be reasonable on v4.

If you're using a /112 then you're not using SLAAC, and therefore aren't using privacy extensions. DHCPv6 does have an option for assigning temporary addresses, in which case the DHCPv6 server is responsible for avoiding collisions as usual... but really you shouldn't be using /112s. If you are then someone is screwing up somewhere.

There are a few advantages to using /64 as the subnet size: it makes it possible to generate a unique address directly from your EUI-64 address, it's used to help prevent L2 MITM attacks via SEND, and it makes it difficult to exhaustively scan a network to look for active hosts, which shuts down network scanning as a viable technique for spreading malware.

There also shouldn't be a need to dedicate more than 64 bits to the network side of the address. There are ~330 million /64s available... per person on the planet. Does it really need to be larger? And that's just in 2000::/3 as well; if we do in fact run out of space then we can restart allocations using a tighter allocation policy in one of the five other untouched /3s we have available.

>I thought IPv6 also supported subnets, DHCP, and static configuration, just like IPv4?

It does support all of those.

Dagger2's comment already explained the benefit of using /64 as a subnet size. I want to clarify that when I was talking earlier about getting a /60 or larger from your ISP, the point was that a /60 can be divided into sixteen /64 subnets. So you do have multiple subnets. The only subnet division you should avoid is dividing smaller than a /64.

It's not impossible to work with subnets smaller than /64, as long as you enable NDP proxying like I said. Eg some guides for setting up IPv6 for Docker containers, where the host doesn't have a delegated prefix and thus cannot be a sub-router, tell you to assign a /1xx to Docker and enable NDP proxying between NICs in the kernel. The nicer way, which I used to use in my homelab, is to delegate a /64 to your Docker host so that it can be a sub-router, and assign the whole /64 to Docker to assign IPs from. This of course requires that my main homelab router gets a bigger block than a /64 from my ISP. (My "ISP" was a tunnelbroker tunnel, and thus I got a /48.)

>Long ago, I recall an ISP that charged extra for more than one active device.

Well yes, if you absolutely must use an ISP that only gives you a /128, and you must use more than one device, then you'll need to set up NAT66, or any of the various IP tunnels to an external server, and forego having universally routable addresses on your devices.

> one can totally implement NAT for IPv6, and in fact people have

Please don't say things like this out loud!

The purpose of IPv6 was to eliminate the need for filthy hacks like NAT.

NAT does nothing for privacy, not in theory, not in practice.

Everyone trying to get at your private information has figured out hundreds and hundreds of methods for tracking you. Single pixel images. Browser fingerprinting. Hardware fingerprinting. Mouse movement patterns. You name it, they're doing it.

They're not at all slowed down by NAT, but the Internet is harmed by it.

Stop giving advice like this.

I think the situation is quite a bit more complicated than you make out.

To my ISP, NAT obscures device browsing history (assuming there are multiple people and devices within a household). To the best of my knowledge an ISP has no realistic way of engaging in mass browser fingerprinting.

To a web host, NAT obscures the number of users behind a given IP address. Sure, they can likely recover some amount of information by engaging in browser fingerprinting but right off the bat it makes their job harder.

Security and privacy both involve layers. Every bit of information leaked is a concession to an adversary. When I switch my home network over to IPv6 I will almost certainly add NAT to it.

> the Internet is harmed by it

I don't believe you. Shitty software is harmed by it. If you have concrete examples to the contrary, I'm open to them.

> To my ISP, NAT obscures device browsing history (assuming there are multiple people and devices within a household). To the best of my knowledge an ISP has no realistic way of engaging in mass browser fingerprinting.

There's plenty of information that an ISP could silently listen in on, e.g. user-agent header, pre-STARTTLS cipher suites. And realistically how many people are there in a household, and how much do they reflect on each other? What's the threat model where this is a realistic improvement in your privacy?

> Sure, they can likely recover some amount of information by engaging in browser fingerprinting but right off the bat it makes their job harder.

> Security and privacy both involve layers. Every bit of information leaked is a concession to an adversary.

Weak privacy measures are worse than nothing just like weak security measures. Putting in effort to obscure one or two bits is a false economy. One solid layer (e.g. Tor) will protect you far better than any number of weak layers.

> I don't believe you. Shitty software is harmed by it. If you have concrete examples to the contrary, I'm open to them.

Everything peer-to-peer is made needlessly harder, and the result is centralisation that hurts the overall internet. E.g. in a non-NAT world, hosting a multiplayer game and letting your friends join is easy; with NAT, it's hard enough that people rely on the manufacturer providing servers (which they won't do indefinitely) instead.

That's a convincing privacy argument for NAT.

I thought temporary addresses were supposed to (mostly) solve this and would be my preferred way. Though the default 24h lifetime is not quite as helpful, except for hopefully sidestepping the genius - embedded by MAC into my IPv6 - address generation.

  net.ipv6.conf.all.temp_prefered_lft = 86400

It's in a nearby comment chain, but apparently my understanding was outdated and/or just incomplete. The SLAAC privacy extensions will make use of a full /64 prefix instead of a device specific one. That makes it functionally equivalent to NAT if and only if addresses are rotated on a very frequent (ex per browser tab) basis. (I wonder if you could rotate per origin within the same tab?)

You do realise that most IPv6 implementations randomise the /64 "host" part of the address, right?

IPv4 NAT does not provide any additional privacy over IPv6.

You can jump up and down and claim the contrary, but it's just not the case.

Meanwhile, Facebook, Google, and the like are scraping petabytes of information about every Internet-connected person on the planet and selling it to the highest bidder. These organisations are not slowed down in the slightest by IPv4 or IPv6.

This is your argument in a nutshell: https://www.snopes.com/fact-check/pregnant-pause-2/