RFC 3513 mandates that all unicast IPv6 addresses except the ones starting with the bits 000 must have a 64-bit interface identifier in the lower 64 bits.
This was shortsighted, just like having the notion of "class" built into
IPv4 addresses was shortsighted. People are going to need to subnet
past /64 sooner rather than later, and subnetting past /64 is a LOT
better than NAT. Fortunately the mistake is easily rectified, so long
as software doesn't get into the habit of expecting the lower 64 bits
of an address to be a unique interface identifier.
Right. Fortunately the implementations that I'm familiar with seem to have ignored this requirement at least to some degree as they seem to function well with non 64-bit subnet boundaries. However, there is also another requirement that gets in the way of using very small subnets: the well-known anycast addresses. Since the address with all zero bits in the subnet part is the mandatory all subnet routers anycast address this address is unusable (even though this anycast address isn't universally implemented), and another 128 are reserved, making the smallest possible subnet a /126 or /120 respectively.
This has some important advantages, most notably it allows stateless autoconfiguration.
Providing an alternative to stateless autoconfiguration for subnets past /64 might be a acceptable compromise.
DHCPv6 should work with non-/64 subnets as soon as it's integrated in the OSes.
Putting a 64-bit crypto-based host identifier in the bottom 64 bits of IPv6 addresses shouldn't get in the way of regular IPv6 addressing mechanisms and/or operation.
Putting a crypto-based host identifier in the address is unnecessary, since there's really no need to include a strong host identifier in every packet sent to a host. The locator alone is usually sufficient, and if that's not sufficient, the sender can generally encrypt the traffic with a secret known only to the intended destination.
Putting a 64 bit crypto-based identifier in IPv6 addresses isn't something that would be done because it's the only way to arrive at certain functionality, but rather because it's a convenient way to do it. The 64 bits are present in each packet anyway, and putting a crypto identififer in each packet is much simpler than thinking very hard about when one is required, and then find a good place for it.
