[gtvwill]

Tbh 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. Seems a monumentally shite oversight to not be like that. I mean it's a freaking telephone book address system. Astounding they baked it in just xxx.xxx.xxx.xxx and didn't upgrade the protocol at all in the last 20 years (is this just entirely due to profit/asset protecting?).

Response was to make a wholly new protocol when they could have just updated the standard and forced suppliers to patch updates?

USB backwards compatability that shiz. The fact I can take a modern usb device and plug it in a 1.1 gen port and it still just works. Why the hell isn't ipv4 like that for upgrades?

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

[superluserdo]

This very confident sentiment comes up in every comment section about IPV4/6

- "Updating the standard" is making a new protocol

- "forced suppliers to patch updates" - how?

- "USB backwards compatability that shiz. The fact I can take a modern usb device and plug it in a 1.1 gen port and it still just works. Why the hell isn't ipv4 like that for upgrades?" - because you're changing the address space of the protocol. If the new standard can address more than 2^32 things, then it won't be backwards compatible with v4.

- "Seriously is there any real technical hurdle why we didn't do it this way?" - Assuming you're talking about having a variable-length address from the start in IPV4, because I assume having a non-fixed packet header size would be much more computationally expensive and violate a lot of assumptions that you can make when the header is fixed (having a fixed region of the buffer that is known to always be the full header). You'd be much better having a fixed-length address that is enough to cover all possible nodes in the network - exactly what IPV6 has done.

- "Astounding they baked it in just xxx.xxx.xxx.xxx" - IPV4 was first deployed in 1982. Wikipedia tells me that the year before, there were just over 200 nodes on the ARPANET. I think you're doing a bit of a disservice to the people who designed this stuff by castigating them for not factoring a 20'000'000x increase in network size into their protocol.

[cqqxo4zV46cp]

Because I don’t want to feel like I’m shopping at IKEA when I’m configuring my router.

[p1mrx]

Here are all the IKEA products you can spell in hex:

A16 ALG, A15EDA ALSEDA, A77E57 ATTEST, BA66E BAGGE, BA615 BAGIS, BA7157 BATIST, BEA7A BEATA, BE57A BESTÅ, BE7A BETA, B1BB1 BIBBI, B155A BISSA, B1716 BITIG, B1AD BLAD, B1ADE7 BLADET, B0A17 BOALT, B0110 BOLLÖ, B055E BOSSE, B0A5 BOÅS, BA5715 BÄSTIS, DA7A DATA, DE701F DETOLF, D10D DIOD, D170 DITO, D177E DITTE, D0F7A DOFTA, D01D DOLD, DA71D DÅTID, ED17 EDIT, E1DE EIDE, E16A ELGÅ, FAD0 FADO, FA5 FAS, FA57B0 FASTBO, F1BBE FIBBE, F1A7A FLÄTA, F070 FOTO, 6A5E11 GASELL, 61DEA GIDEÅ, 61E5 GLES, 610BA1 GLOBAL, 610DA GLÖDA, 60D15 GODIS, 605A GOSA, 60516 GOSIG, 1BE57AD IBESTAD, 157AD ISTAD, 1ADDA LADDA, 1ADE LADE, 1066A LOGGA, 1075 LOTS, 1A77 LÄTT, 0B1 OBI, 0DDA ODDA, 011E OLLE, 5A1B0 SALBO, 5177A SITTA, 50DA SODA, 50F1A SOFIA, 501 SOL, 50157A SOLSTA, 57A11 STÄLL, 7A6 TAG, 7A55A TASSA, 7177A TITTA, 70B1A5 TOBIAS, 70B0 TOBO, 70F7B0 TOFTBO, 706A TOGA, 7016 TOLG, 7016A TOLGA, ADA1 ÅDAL, A5E1E ÅSELE, 061A ÖGLA

Quite a few actually. I used https://lar5.com/ikea/ for the input words.

[kelnos]

> 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.

[bombcar]

What probably could have been done (and kind of was done with NAT) would have been to move one byte from the port number to the address, giving us 256 additional “Internets” worth of addresses but limiting each address to 256 ports.

[p1mrx]

That's a good idea; it's called MAP-T.

Here's a NANOG presentation: https://www.youtube.com/watch?v=ZmfYHCpfr_w