CIDR and the resulting address space fragmentation was the problem that IPv6 was originally meant to solve; allowing splitting into random-sized subnets makes routing more complex and worse. And if you made the routable part of an IPv6 address longer than 64 bits then that makes the routing much more compute-intensive. 64 bits in the local part of the address is sort of overkill, but a 128 bit address isn't really any harder to use than a 96 bit address, and it means things like, well, being able to automatically assign the local part based on the MAC address, which only works if the local part of the address is more than 48 bits.

You can still use a shorter hash of the Mac address.

Collisions are very unlikely, and a quick ARP packet should detect them if they do happen.

Collisions are just as likely with the 48 bits as they are with the last 24 bits, as some OUI vendors reuse mac addresses.

Using a mac address in the IP is terrible anyway from a privacy point of view, use a random IP in the subnet, send out a check to see if it's already used, if it is choose a new one. That check is already a feature of ipv6.

It would rather be an ICMPv6 neighbor discovery packet or something like that, IPv6 doesn't use ARP.

> Collisions are very unlikely, and a quick ARP packet should detect them if they do happen.

You can do that, sure. But it's more complex and slower.

On Comcast Business the SLAAC would hand out a /64, and DHCPv6 would give you a /64 unless you requested "Prefix Delegation" in which case they'd give you a /56, /58 or /60 depending on how large your static IPv4 allocation was.