4 ms·

If they’d simply added two or four bytes (IPs of 48 or 64 bits) by finding space in the V4 header we would have been done by the mid 2000s. But at this point w

by api 3y ago

If they’d simply added two or four bytes (IPs of 48 or 64 bits) by finding space in the V4 header we would have been done by the mid 2000s. But at this point we are at almost 50% of traffic, so why stop. I wonder if the disaster is partly due to the various standards boards of the time (late 90s) still acting like they had the kind of ability to do things in a coordinated manner they had when the net was just government and research institutions. The fact that it was now a giant unmanaged market hadn’t sunk in.

irdc 3y ago
There is no such space in the IPv4 header. And even if it were possible and you could specify an IPv4+, you’d run into the exact same problem: people would still insist on an IPv4 address to talk to whoever still is in the IPv4 world.
- api 3y ago
  Extend the address space to the right. All V4 addresses become /32 prefixes in a /48 space. 48-bit addresses ending in .0.0 are semantically identical to 32-bit addresses and may in fact be sent as classical 32-bit addressed packets or converted to such in flight to support old devices. Use the IP options facility for additional address bits, or alternately use the identification field and deprecate fragmentation at the IP level which is often broken anyway and is obviated by path MTU discovery. Routers would still have to be updated, but only close to or at the edge for quite some time. Could have been done that way but water under the bridge.
  - lmm 3y ago
    If you'd got that standardised before CIDR then it might've worked, but there's no way to make it happen now; the IPv4 routing table is hopelessly fragmented and getting worse every day. New ISPs would be doomed to be forever second- or third-class citizens - there are no new class A or B blocks to hand out.
  - Dagger2 3y ago
    We already have v6 addresses that are semantically equivalent to v4 ones: ::ffff:a.b.c.d. You could put extra address bits into option headers instead of expanding the address fields, but... what do you do then? How do you make things work? No existing OS, software or hardware device knows how to use them, and you have to go around and update those in exactly the same way you have to on v6. None of what you've suggested here would have allowed us to finish in the mid 2000s.
- Ekaros 3y ago
  There is the Options field, it could have been theoretically used. But that would have made the whole routing and decoding even more inefficient and messy...
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 ago
  It'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 ago
    Right, 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.
pif 3y ago
> But at this point we are at almost 50% of traffic, so why stop. You could say: at this point we are at only 50% of traffic, so why not rollback? In the end, IPv4 is still working fine. Maybe IPv6 was just a huge error while the status quo was already good enough.
- api 3y ago
  IPv4 isn't working fine unless the only use case for the Internet is pure client-server access to centralized cloud. Even there it's not working fine because cloud is running out of IP space. IPv4 address space is just too small. Full stop.
  - pif 3y ago
    We have learnt how to cope with the small address space of IPv4. Full stop.
    - Dagger2 3y ago
      That doesn't mean the problems have gone away. It means we spend time and effort working around them, and many things just don't work at all. It remains true that v4 is too small and that it isn't working fine. That's been the case for so long that a lot of people grew up with the problems and can't even see them because they're so used to them, but the problems are still there.

by api 3y ago

irdc 3y ago

There is no such space in the IPv4 header. And even if it were possible and you could specify an IPv4+, you’d run into the exact same problem: people would still insist on an IPv4 address to talk to whoever still is in the IPv4 world.

api 3y ago
Extend the address space to the right. All V4 addresses become /32 prefixes in a /48 space. 48-bit addresses ending in .0.0 are semantically identical to 32-bit addresses and may in fact be sent as classical 32-bit addressed packets or converted to such in flight to support old devices. Use the IP options facility for additional address bits, or alternately use the identification field and deprecate fragmentation at the IP level which is often broken anyway and is obviated by path MTU discovery. Routers would still have to be updated, but only close to or at the edge for quite some time. Could have been done that way but water under the bridge.
- lmm 3y ago
  If you'd got that standardised before CIDR then it might've worked, but there's no way to make it happen now; the IPv4 routing table is hopelessly fragmented and getting worse every day. New ISPs would be doomed to be forever second- or third-class citizens - there are no new class A or B blocks to hand out.
- Dagger2 3y ago
  We already have v6 addresses that are semantically equivalent to v4 ones: ::ffff:a.b.c.d. You could put extra address bits into option headers instead of expanding the address fields, but... what do you do then? How do you make things work? No existing OS, software or hardware device knows how to use them, and you have to go around and update those in exactly the same way you have to on v6. None of what you've suggested here would have allowed us to finish in the mid 2000s.
Ekaros 3y ago
There is the Options field, it could have been theoretically used. But that would have made the whole routing and decoding even more inefficient and messy...

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 ago
It'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 ago
  Right, 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.

pif 3y ago

> But at this point we are at almost 50% of traffic, so why stop. You could say: at this point we are at only 50% of traffic, so why not rollback? In the end, IPv4 is still working fine. Maybe IPv6 was just a huge error while the status quo was already good enough.

api 3y ago
IPv4 isn't working fine unless the only use case for the Internet is pure client-server access to centralized cloud. Even there it's not working fine because cloud is running out of IP space. IPv4 address space is just too small. Full stop.
- pif 3y ago
  We have learnt how to cope with the small address space of IPv4. Full stop.
  - Dagger2 3y ago
    That doesn't mean the problems have gone away. It means we spend time and effort working around them, and many things just don't work at all. It remains true that v4 is too small and that it isn't working fine. That's been the case for so long that a lot of people grew up with the problems and can't even see them because they're so used to them, but the problems are still there.