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