> 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.
8 bits for the home network feels cramped even now, my home network is at 56 devices. But 16 bits are fine for end-user networks.
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.
Large, sparse subnets are nice for their security benefits.
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.
> And once you go over 16 bits, you really need to start dealing with routing.
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).
> 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.
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).
> 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).
Snooping table sizes are typically around 16k entries. IGMP/ND packets are almost always punted to the CPU, so once the CPU is saturated, switches typically either fall back to broadcast or stop forwarding multicasts.
This varies widely by switch model, and 16k is on the low end. I looked at a few random Cisco and Arista switch datasheets just now and saw numbers ranging from 16k to 768k (usually 25% to 100% of the unicast MAC table size of the same switch).
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.
> Actually, people DO claim that [MAC table limits make IPv4 over Ethernet infeasible]. 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.
Think of the unexpected unknowns. The feet of your chairs having light sensors, each tile of a roof having its own ambient vibration monitors, a thermostat on every bookcase shelf, all self organising around the you GooFaceAI determines you to be.
> 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary.
I don’t even think it’s really ok. ARP was layered correctly: IPv4 runs on Ethernet+ARP. Or it can run on other things that aren’t Ethernet+ARP. IPv6 uses IPv6 messages to make itself work on Ethernet, thus baking knowledge of Ethernet into the IPv6 neighbor discovery logic.
If multicast neighbor discovery is useful (which it may well be), then ARPv6 could have used multicast.
I'm honestly not sure if ND along with interface addresses in V6 is a useless hack, or if it is a clever trick. I keep changing my mind all the time. I guess it's kinda both.
On one hand, V6 addresses are big enough to represent hardware addresses directly. So you don't _need_ a low-level protocol like ARP to resolve V6 addresses to hardware addresses, you can represent it as special messages in IPv6 itself.
It also allows some interesting tricks, like local network applications using interface addresses to communicate normally without setting up global connectivity.
On the other hand, interface addresses in V6 cause no end of confusion ("what the heck fe80::88a:fd34:d1b:2de7%en0 means?!?"). And V6 also has no clear distinction between the local network and the Internet, and the easy ability to use broadcasts (just send a packet to the network address).
And it's not like many applications actually use interface addresses anyway. So this is kinda a moot point.
> Reify the MTU into the IP layer. No more ICMP nonsense for PMTU.
If the MTU is fixed, you can't have VPNs, or any other protocol that encapsulates IPv6 packets and then sends them over IPv6. There needs to be some way for a middlebox to communicate that the MTU is lower than normal on a specific path because it is taking up a bit of every packet for overhead.
This statement then implies that we would need to have NAT66. Why? Stateful DHCP then implies the possibility of an endpoint having only a single assigned address. But what if the endpoint needs to have multiple addresses such as tethering or running VMs? With SLAAC the endpoint can just get multiple addresses. Now, just because today stateful DHCPv6 is a possibility, hypervisors need to have NAT66 built in. So the status quo is strictly worse than either only SLAAC or only stateful DHCPv6.
Stateful DHCPv6 allows prefix delegation even now, in its half-assed stupid form.
And if you don't want/have prefix delegation, you can just use multiple DUIDs to get several leases for one endpoint. Unlike in V4, this is fully supported in V6.
Your VM hypervisor will need to request an address during the VM startup, but I think it's actually better from the management standpoint. The network operator will be able to see VMs as the first class citizens in the network management console.
> But what if the endpoint needs to have multiple addresses such as tethering or running VMs?
Android developers are actually adding support for stateful DHCPv6 for exactly that reason :) They want to support tethering for V6 without doing NAT or bridging.
IPv6 was built for a world with 64 bit machines. That's why the address is basically two 64 bit chunks, the first being the global network and the second being the local network. This is why you never allocate an IPv6 network smaller than a /64, so router manufacturers can optimize their hardware to only have to examine the half of the packet that the current routing step cares about.
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 and stateless DHCPv6. Statefulness is helpful for network management.
5. Reify the MTU into the IP layer. No more ICMP nonsense for PMTU.
6. Rework extension headers to be actually useful. No more "next header" bullshit.