AWS is estimated to make $400M to $1B with the new IPv4 charge

I'm aware of how routers work and this is obviously simplified. But basically you would just have a high part of the address that would be outside the mask, and old routers would just ignore it.

So your IPv6 would be 1.2.3.4.5.6.7.8, and old routers would just see 5.6.7.8 and route to the place where that IP should go. The router at 5.6.7.8 would be responsible for understanding IPv6 and how to route from there with the full address.

> Seriously is there any real technical hurdle why we didn't do it this way?

Yes, because designing and implementing a protocol like USB is nothing like designing and implementing an internetworking protocol.

> not sure why the protocol couldn't be upgraded so that xxx.xxx.xxx.xxx, xxxx.xxxx.xxxx.xxxx and xxx.xxx.xxx.xxx.xxx are all accepted

You can't just add address bits to a fixed-size protocol header that wasn't intended to be extended in that manner. IP addresses don't actually look like those dotted strings you're talking about. Those representations are for convenience and ease of reading for humans. For computers, it's a 4-byte quantity that's sent over the wire in binary, not a string of base-10 numbers separated by dots. When these things were designed, CPUs, custom processing units, and RAM were incredibly expensive. When you designed a protocol, you designed it for efficiency in size and parsing speed. Otherwise no one would implement your protocol, because it wouldn't be cost-effective to do so. Today we throw around JSON payloads in our HTTP responses without a care for the bandwidth needed or processing power used to parse. If you tried to do something like that back in 1981 when IPv4 was introduced, you'd be laughed out of the room and fired.

Your middle suggestion ("xxxx.xxxx.xxxx.xxxx") makes no sense: each part of the dotted-quad notation we're familiar with represents an 8 bit quantity (base-10 numbers 0 through 255). Adding another base-10 digit is nonsensical. The last example, a dotted-...er...quint? is certainly one option, which would increase the address field in the header from 4 to 5 bytes, giving us 256 times the current number of addresses (more or less). IPv6, instead of going from 4 to 5 address bytes, goes to 8 address bytes. That allows us to give every grain of sand on all the Earth's beaches an IPv6 address, several times over. Overkill? Maybe. Probably. But consider how long it's taken to adopt this new protocol. If we were to only add 1 more address byte, and then run out of addresses again, we'd likely have to wait even longer than this time for a future IPv7 to become adopted.

Now, going back to the fairly modest 1-byte increase in the address fields (and presumably no other protocol changes). For some devices a fairly simple software update would suffice, but for many router-type hardware of the time (25+ years ago), it wouldn't have been feasible to solely upgrade the software or firmware. Consider that things like routing tables would now require 25% more memory per address, and memory was something routers of the time didn't have in abundance. And some of these older pieces of hardware actually had parts of the protocol "parsing" done in hardware, which you can't change after the fact; you need to scrap the entire thing and build something new.

I do agree that it was foolish to design a whole new protocol. If they'd just released a new protocol where the only change was more address bits, I'm sure it'd be fully adopted by now and IPv4 would be a thing of the past.

That wouldn't work either. Why would the 5.6.7.8 router necessarily know how to route to the longer-address destination? There's no guarantee it's been upgraded. And why should it have to, anyway? It could get DoSed (accidentally, even) by traffic intended for a completely different destination outside its control.

Also consider that even if that 5.6.7.8 router knew how to route to the 1.2.3.4.5.6.7.8 network, it would have no guarantee that the packets wouldn't hit another router along the way that didn't understand the extra address bits. You could end up with weird routing loops and other issues. (Fortunately TTLs would quash these, but not after wasting a bunch of extra resources.)

Now, there might be some clever ways to work around this, and it might require some more internet infrastructure to deal with these routing challenges. Maybe that would have been faster and cheaper to deal with than the current IPv6 mess we have, maybe not.

This ongoing "IPv4 with more bits" meme needs to die.

There was no way to change IPv4 to have more address space while maintaining compatibility with existing routers. Routers are hardware-accelerated so can't just support new protocols with a software update.

If you need a new protocol, why just lengthen the address without fixing other weaknesses, since you'll never be able to change it again? This is IPv6, and while you can argue some changes weren't necessary, it is simply not true say that IPv4 with extra bits would have been easy.

AWS is holding onto those routers running something earlier than, what, IOS 12.4 from 2005? And all those servers with iDRAC6s from, what, 2012?

Some day people will stop pretending IPv6 support is something that hasn't been ubiquitous in network gear for a decade or more.