Literally all we had to do was add a byte to IPv4 and we'd be done but noooo we need to overengineer the next protocol and make it as painful as possible to adopt.
this keeps coming up, if you add a byte to ipv4 you still have a transition problem. 5 byte machines can't talk to 4 byte machines. pretty much the only thing that solves is people not liking the :: syntax. the only other change is auto configuration, which...kind of doesn't matter? is that really causing problems?
Yeah but they could've picked something that at least lets the 4 byte host talk to a 5 byte one. Like if I have 8.8.8.8 and they want to give me 8.8.8.8.0, cool. Or make it 8 bytes instead of 5, same thing.
well, if you want to add an extra byte you kinda have a problem, since v4 is fixed format and is actually cooked into hardware in a lot of places. so if you want to keep v4 mostly untouched you have to use an option, which is going to be pretty slow on the backbone.
you can send a packet from an extended address host to a vanilla v4 host if you map the address space into a range like you suggest..but that v4 host just has no way of sending a message back..so its kinda useless
It'd be useless until everyone switches to the 5-byte thing and people can start putting something besides 0 into that last byte. But at least they could turn on v5 or whatever it's called without having to think about it. Right now I could have two hosts that both agree to use ipv6 and it's still hard because you have to reconfigure everything.
v6 already gives you what you're asking for here: you can turn it on without thinking about it, but actually using the extra addresses from it requires reconfiguring some things (not everything, mind).
Why is that bad when it's v6 doing it, but good when it's your 5-byte thing doing it? Or did you just not think through this enough to realize you were asking for something we already have?
Because you can't generally turn on v6 without thinking about it. Maybe consumers can, even then not always cause it messes random things up. Power users and offices maybe can't. Service operators really can't. If it were as easy as you're saying, all those things like Github would already at least support v6.
I think the addresses are a big issue. The address space is just stupid big, I don't understand why we need to prepare for every grain of sand on Earth having a WiFi chip in it.
Most people can pick up calculating subnets in their head in ipv4 pretty quickly and ipv4 addresses are easy to memorize on accident. My brain turns to mush as soon as I start seeing hexadecimal characters in addresses.
But subnetting in v6 is so much easier than in v4? And it's specifically because of the hex. You don't even need to calculate it, in your head or otherwise, because you just subnet based on characters:
etc. About the only mildly complicated thing is remembering that leading zeros in a number can be dropped but trailing ones can't (i.e. 1 and 001 are the same number, but 1 and 100 are different numbers), but that's something you should've learnt in grade school already.
Why one byte? Is that enough bytes? An extra 4 bits each for source and destination? Maxing out at 2^36 addresses? That seems uncomfortably small safety margin.
I was saying adding a byte to the address so its a 40 bit address which would be two bytes to the header. Obviously it would still have the same issue where hardware and software would be incompatible and would need to be replaced but the same concepts that worked in IPv4 would work in my fake protocol instead of IPv6 where the network needs to be redesigned from the ground up.
How sure are you that 40 bits is a good number of bits? What's your justification? It takes over 30 years to deploy new bits, so you have to be really sure before you start that effort.
40 bits would've bought us a lot of time and would've kicked the can down the road several decades. People from the future would be much better equipped to design a new protocol because they understand their needs better.
How many decades? If several means six, we're already halfway there and at 50% deployment. What's the point of designing something you know will be obsolete the moment it hits 100% deployment?
It really isn't. I mean, at a very basic addressing level, sure, IPv4 addresses and IPv6 addresses are just a sequence of octets. But at a network infrastructure level they are quite different, and IPv6 is (conceptually) designed for large-scale, hands-off deployments. See: SLAAC, NDP, DAD, GUA/ULA/link-local address scopes, unicast vs. multicast vs. anycast, etc.
That would be just as hard to switch to and even more complex. If you think ipv6 is over engineered you haven't had to deal with ipv4. (Source routing is a pain)
We need to pretend we overengineer. But some in the committee made it sure data exfil would be basically impossible to detect / block with IPv6, which all the others, always in love with the most rube-goldberg design possibles, loved the "overengineered" solution.
With rube-goldberg designs, you can then always say stuff like:
"The xz backdoor was TOTALLY unrelated to systemd"
Yet it only concerned distro that shipped with systemd.
Data exfil is basically impossible to detect/block with IPv6? What? No. It's no easier or harder than it is in v4.
I'd also question the Rube-Goldberg-ness part, given how straightforward v6 is compared to the contortions we go through to get v4 to work in the face of address exhaustion.