3 ms·
> 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
by Reelin 6y ago
> 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).
- Arnavion 6y agoYou 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).
- Reelin 6y agoWhoops 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.
- Arnavion 6y agoThe 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.
- Reelin 6y agoSorry, 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?
- Arnavion 6y ago>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.