Ugh. This is one of my favorite "what ifs" in the computer engineering. Things I would change: 1. Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 2. Just use the IPv4 "local subnet" prefix logic for broadcast domains. No "on-link" nonsense. 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary. 4. Remove SLAAC…
> Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 16 bits is just way too small. The article clearly states that network operators just love to bridge together larger and larger networks due to the mobile IP problem. In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough.
And once you go over 16 bits, you really need to start dealing with routing.
> In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough.
This is not a fair comparison. You won't have a 10.0.0.0/8 network in IPv4 that has 16 million computers in the same broadcast domain. You'll likely have multiple /8 or /16 networks, with routing between them.
And in my hypothetical world, you'll have 56 bits for that routing. Your ISP can delegate you a /32 prefix, giving you 24 bits for your own routing hierarchy.
This is not dissimilar from the current situation. You have just 64 bits of the "network address", because the lower 64 bits are needed for SLAAC.