3 ms·
The fact that lots of packet processing hardware relied (and still relies) on the IP header having the structure it did means you’d have exactly the problem IPv
by stephen_g 3y ago
The fact that lots of packet processing hardware relied (and still relies) on the IP header having the structure it did means you’d have exactly the problem IPv6 had. So you’d have to roll out brand new hardware that simultaneously supports both types, just like with IPv6.
As for endpoints, it’s similar - no IPv4 endpoint could talk to an IPv4+ (or whatever you want to call it) endpoint without additional code to handle it (just like IPv6 needed software modifications), and if you wanted backwards compatibility you’d have to still have a regular IPv4 address on every endpoint (or NAT) as well as an IPv4+ or whatever address - just like what’s needed with IPv6!
So ‘just’ doing that causes literally all the exact same problems as what we had with IPv6…
- lmm 3y agoIt's actually a lot worse. Unmodified routers route IPv4+ packets to whichever IPv4 endpoint happens to have the "same" address. So depending on which path your packet takes, you suddenly end up in nondeterministic routing loops.
- WorldMaker 3y agoRight, that could also end up the case that the IPv4 endpoints become NAT landlords charging extra for all the "4+" traffic that they have to see. We already see blocks of IPv4 addresses changing hand for lots of money, imagine if they could also monetize "downstream" traffic. Doesn't that give added economic incentive to never "fix" those bottlenecks? They could encourage more people to support "4+" directly on their devices or they could keep collecting easy rent from being NAT gateways. I have a hard time imagining that profit motives wouldn't make deployment of any "IPv4+" worse than IPv6 deployment.
- yardstick 3y ago> So ‘just’ doing that causes literally all the exact same problems as what we had with IPv6… To be fair, there’s a lot of other changes with IPv6 that could have been simplified or approached in a more IPv4 familiar way: - ARP instead of NDP - DHCP instead of SLAAC, DHCPv6, DHCPv6-PD, etc - IP syntax (periods vs colons and square brackets) - IP header design (extension headers/non fixed size approach for the header) - NAT support from the get-go (you can debate the evils of NAT all you want- not including it from the start was a net negative against IPv6 adoption) - Private IP RFC1918 style space instead of the ULA addressing Probably missed a few others. It’s the whole ecosystem you need to take into account. Too many changes were attempted at the same time.
- KWxIUElW8Xt0tD9 3y agoAgainst Stupidity, the Gods Themselves Contend in Vain