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.
Disagree. you don't want to be routing unless you actually have to. A large flat network is more desirable a lot of the time (e.g thousands of devices in a DC) than a bunch of artificially carved up subnets.
The reason you don't see them very often is because people have had to use IPv4, which means ARP, which just doesn't scale. At some point in size, ARP chatter becomes the majority of the traffic on your network, which isn't great.
ND fixes this, and allows for ridiculously large networks (the way our good maker intended).
Due the mass use of encryption and overlays, you can't trust any process or device any more.
First, a /16 network is 65536 devices, which is pretty big as-is. And like in V4, you'll be able to disregard recommendations and choose a larger local net size (just change the netmask).
But it's a bad idea. You will have a shared media that can be brought down by erroneous broadcasts or devices. This is a classic story: https://www.computerworld.com/article/2581420/all-systems-do...
> ND fixes this, and allows for ridiculously large networks (the way our good maker intended).
ND doesn't solve it. It works in practice using the same old broadcast, just like ARP. Some switches might do ND snooping, but if you have thousands of devices, they'll overflow their internal tables and fall back to regular broadcasts.
ND also has unsolvable issues, like the neighbors cache size problems. Since you have a freaking /64 for your local network, you can't easily store the mapping for ALL hosts, and you're susceptible to various cache exhaustion attacks (including negative entries).
"big" is a relative term. For some cases, that's a really annoying restriction.
> But it's a bad idea. You will have a shared media that can be brought down by erroneous broadcasts or devices. This is a classic story: https://www.computerworld.com/article/2581420/all-systems-do...
IPv6 doesn't have the concept of "broadcast".
> ND doesn't solve it. It works in practice using the same old broadcast
No, ND uses multicast.
Running any network with >100k hosts has its challenges, but these are surmountable with IPv6, and not at all with IPv4.
Indeed. It has magic fairies delivering multicast packets to the right interfaces.
> No, ND uses multicast.
How do you think multicast is implemented in Ethernet?
Via MLD snooping on switches that support it. Yes, some switches will fall back to broadcast, but only if they're not multicast aware.
It's not a good outcome either way.
Unicast MAC table space is scarce, too, and suffers the same failure modes when filled. You don't see people claiming this makes IPv4 over Ethernet infeasible. Do proper capacity planning, and this isn't a problem. Oversubscribe your network, and this is a problem even without multicast in the picture.
Yup.
> You don't see people claiming this makes IPv4 over Ethernet infeasible
Actually, people DO claim that. Flat Ethernet doesn't scale, and you need to use routing to break up broadcast domains.
This has nothing to do with unicast MAC table limits, and everything to do with ARP's O(n^2) scaling property. You use just as many MAC table entries in a network with 10 VLANs of 100 hosts as you do with 1 VLAN of 1000 hosts. Ethernet scales fine; ARP doesn't.
But what about thinking about the next step, neurons in the home. 65k's on the low side for home neuron count.
For a 16-bit network, you can enumerate all active public servers by exhaustively port-scanning it; it takes something like a few hundred gigabytes of traffic, which is nothing these days. For a 64-bit network, it takes quadrillions of gigabytes of traffic and just isn't feasible.
64 bits is enough space to fit a small public key, which v6 uses to secure neighbor discovery.
There are anonymity benefits too: privacy extensions wouldn't work as well on smaller subnets.
As an added bonus, having extra bits to spare is useful if it ever turns out that we need them. If we run out of space in 2000::/3 then we can start over in one of the five other unused /3s using tighter allocation policies. L3 protocols are incredibly hard to deploy and it would really suck to deploy a bigger one only to have to deploy another, even bigger one again soon after.
I don't think there's a good reason to give up all of that. Smaller addresses break compatibility with v4 just as thoroughly as bigger ones do, so it wouldn't even help deployment much.