Comment by orangeboats
5 days ago
Another day, another Godwin's law of networking.
>It was doomed the moment you had to maintain two separate stacks
Pray, tell me, how are we supposed to extend IPv4 with another {insert a number here} bits without creating a new protocol (that neccessitates running two stacks)?
Suppose that you have an old computer that understands only 32 bit addresses -- good ol' IPv4. Let's name it 192.168.10.10.
It then receives a packet from another computer with hypothetical "IPv4+" support, 172.12.10.98.12.4.24.31... ...Wait a minute, it can't, because your old computer understands only 32 bit addresses!
What if we really forced it to receive the packet anyway? It will see that the packet is from 172.12.10.98, because once again, it understands 32 bit addresses only.
It then sends back the reply to... you guessed it, 172.12.10.98. Not 172.12.10.98.12.4.24.31.
Yeah,172.12.10.98.12.4.24.31 will never get its reply back.
Do you see why any "IPv4 with extra octets" proposal are doomed to begin with now?
It wouldn't be able to receive it. That simple. Which is not a problem, any server would still have an old ipv4 address (172.12.10.98 from your example), like they currently do and probably will for decades.
Devil's advocate. There could be a extension for ipv4 stacks. Ipv4 stacks would need to be modified to include the extension in any reply to a packet received with one. It would also be a dns modification to append the extension if is in the record. Ipv6 stacks would either internally reconstruct the packet as if it were ipv6.
It would be easy to make such an extension, but you're going to hit the same problem v6 did: no v4 stacks use your extension.
How will you fix that? By gradually reinventing v6, one constraint at a time. You're trying to extend v4, so you can't avoid hitting all of the same limits v6 did when it tried to do the same thing. In the end you'll produce something that's exactly as hard to deploy as 6to4 is, but v6 already did 6to4 so you achieved nothing.
Having just optional field in the ipv4 header with extra address bits would leave all the stack source code with just some 100 lines of extra code. Would mean, you can have one stack that handles just both. Make special addresses where the additional bits are all 0, which means the field is not there at all. These addresses could reach ipv4 only addresses and could be reached from them. When you really want to make sure these devices aren't parsing ipv4+ packets, change the checksum-code for all packages that contain the optional field. That would mean all ipv4 only devices would ignore ipv4+ packages. Instead you could change the version to 5 for all with optional address bits.
This is stuff that could be implemented in any ipv4 stack in some days of work.
IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
You clearly do not understand networking. Or else you won't make such a statement:
>This is stuff that could be implemented in any ipv4 stack in some days of work.
The sysadmins across the world, who had to deal with decades-old, never-updated devices facepalmed in unison.
At least the other comment agreed that "IPv4+" hosts will never be able to talk to IPv4 hosts.
>IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
It is already adopted in many countries. Don't blame the protocol for your countrymen's incompetence.