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