[wolvoleo]

Yes. I wish they had simply used a more sane address length instead, and maybe given everyone 65535 addresses at most. More than enough for the craziest home lab ever.

Really, just adding 2 bytes to IPv4 would have fixed everything and made it a lot simpler to move over. IPv6 is overkill and I think that really hurt its adoption. I remember being at uni and being told "this is the next big thing". In 1993. And it's not even a big thing now. Not on the user side anyway, I can still access everything from IPv4.

[Dagger2]

Adding two bytes would have been just as much work as adding 12 bytes, and would have left us with too few addresses rather than too many. The MAC address space is now 64 bits and L3 is necessarily less dense than L2, so 128 bits is the smallest power of 2 where we can be reasonably sure we won't end up with too few addresses.

Considering how hard deploying a new L3 protocol is, we're only going to get one shot at it so it's a lot better to end up with too many addresses rather than too few.

[wolvoleo]

Ehm but IPv6 packets still have the L2 layer as well right? Which already includes the MAC address. So that 64 address MAC space is doubled, it's not like you're saving any. It was a pretty arbitrary decision to accommodate the MAC address inside the IPv6 address and these days it's usually randomised anyway for privacy purposes, so the MAC part of an IPv6 packet doesn't have to be the size of the MAC address.

L3 has nothing to do with MAC addresses anyway so I've always found that a pretty weird decision anyway. Sure, it avoids having to implement ARP but we need that again now anyway with the randomisation. And ARP is like a one-time in a few minutes kinda thing anyway.

I'm pretty sure that if we'd just gone for "a couple bytes extra" we'd have long been completely over. It's the whole L3 transition itself that suffers from the complexity. I remember it well in the 2000s, nobody in telecoms wanted to touch it. And when IPv6 was invented in '93 or so, the installed base was extremely small. It'd have been a piece of cake to get it over with then.

[Dagger2]

The point of L3 is to aggregate hosts into networks, so that routing only has to keep track of network prefixes instead of the individual MAC address of every machine. (The amount of routing updates needed for the latter would scale as something like O(hosts²) which just wouldn't work for large networks, let alone the Internet.)

The aggregation necessarily "wastes" L3 addresses, so if you think you'll have enough machines to justify an L2 address size of n bits then that also implies needing an L3 address size of n+m bits, where m is a number that represents how densely packed your L3 address space is. Anything smaller than that will be too small to handle the full extent of your L2 address space.

RFC 3194 (https://www.rfc-editor.org/rfc/rfc3194.html) suggests we'd want something like 80 bits to handle EUI-64. 128 bits is the next power of 2 up from there.

> It was a pretty arbitrary decision to accommodate the MAC address inside the IPv6 address [...] Sure, it avoids having to implement ARP

You're thinking of SLAAC, which picks the address by slapping the MAC/EUI-64 into the right-hand 64 bits, but this is just a convenient way of picking the address bits. There's no special significance to those bits and you still need to do ARP.

> I'm pretty sure that if we'd just gone for "a couple bytes extra" we'd have long been completely over.

We still can't get people to stop hardcoding socket(AF_INET, ...) or manually crafting sockaddr_in structures. This is the minimum amount of work that will always be needed, regardless of how many extra bits are involved, and even this part hasn't been quick.