5 ms·

Yes, it's a common idea but relies on a misunderstanding - it would have required exactly the same difficulty as switching to IPv6, because there's no way to ma

Yes, it's a common idea but relies on a misunderstanding - it would have required exactly the same difficulty as switching to IPv6, because there's no way to make an 'ipv4 with more bits' compatible with regular IPv4 software or hardware, without changing to a dual stack arrangement (which requires replacing all the packet processing hardware in big routers that relies on the layout of the IP header) - exactly the same problem we had with IPv6.

tuatoru 3y ago
No. The difficulty is social. Everyone would have been fine with "IPV4.2", IPV4 with six octets, because it's just like something they already knew, fixing its one obvious defect, not enough addresses. The consitituency for replacing the hardware/firmware and software stacks would have been there. IPV6 was not just like IPV4 and so people naturally resisted the devaluation of their hard-won knowledge.
ok123456 3y ago
"Ipv4 with more bits" could have a very simple cut-over. You internally update your stack and networks. Up until the cut-over date, the addresses are truncated into IPv4. After the cut-over, they're routable. This could have been given a time table of say 5 years.
- p_l 3y ago
  No, it didn't work. Other than already mentioned issues of hardware, you also had for years the issue of lots of applications requiring substantial rewrite to support another protocol due to use of BSD Sockets which leaked protocol internals up to application layer. It was a very big and vocal issue about porting to v6 even in early 2000s despite BSD Sockets finally getting a new API (lifted from the Streams-based XTI) that made handling dual stack easier - but everyone still learnt from older manuals. And tricks with time table were tried - vendors would lobby for all sorts of extensions "while they work to update the code", the result was that none did because none wanted to actually put the work to upgrade network stacks and handle dual-stack in applications. After all, IPv6 is not the first attempt to replace the "temporary" solution that was IPv4 whose planned EOL was in 1990.
  - comex 3y ago
    > you also had for years the issue of lots of applications requiring substantial rewrite to support another protocol due to use of BSD Sockets Past tense? I still regularly see code that uses BSD sockets and doesn't support IPv6. Actually, I feel like among C and C++ codebases that make direct TCP or UDP connections, the majority are IPv4-only, even in 2023. Though, direct TCP and UDP connections themselves are less popular than they used to be, and so are C and C++...
    - p_l 3y ago
      Past tense on have to write two complete code paths to support v4 and v6 at the same time. Today we have getaddrinfo, so if you're writing from scratch you can just use that, you can also simplify older code with it and get v6 at the same time. But there's a lot of old code that still doesn't use GAI and was never upgraded.
    - deleted 3y ago
      [deleted]
- Dagger2 3y ago
  v6 basically is v4 with more bits. You could do what you describe with it. The problem is that nobody has the authority to enforce such a timetable on the Internet as a whole, so that's not actually a workable plan.
comex 3y ago
Sure there’s a way. Define a standard way to encapsulate an “IPv4-with-more-bits” packet (let’s call it “IP+”) inside an IPv4 packet. When a router supporting IP+ forwards an IP+ packet to a router that doesn’t support it (assume there’s some way for routers to learn whether their peers support it), it wraps it in an IPv4 packet. When a router receives an IP+ packet wrapped in an IPv4 packet, in unwraps it. In this way, as long as both sides of a connection belong to LANs that support IP+ internally, they can communicate with each other even if some or all of the Internet routers in between only support IPv4. But even if that weren’t a thing, even if you did need all the routers to be replaced, “IPv4 with more bits” would still be better. After all, it’s been decades - the hardware has been replaced. If it were a seamless incremental upgrade, just a switch to flip that enabled “more bits support” and didn’t break anything, then ISPs would have enabled it even when there was little short-term benefit. By now, practically all of the Internet would support it. Instead it’s an entirely separate network, with entirely separate configuration, which historically had a high tendency to break things. No surprise that even today, many people just don’t bother with it.
- fulafel 3y ago
  Your idea sounds a lot like the 6to4 transition mechanism that was used for several years before it was phased out. It won't "just work" on many networks because they firewall off non-tcp/udp protocols but otherwise it served pretty well.
  - oneshtein 3y ago
    Send IP+ by tcp/443, the only working protocol right now.
  - p1mrx 3y ago
    The biggest problem with 6to4 is that the anycast gateways (192.88.99.0/24 and 2002::/16) often go to a different network than the one you're paying for transit, so you can't just turn it on for production traffic and expect it to work. The anycast gateways are only used when communicating between 6to4 and native IPv6 addresses, so if 2002::/16 had been the only IPv6 address space, then it would have been more reliable, but then we'd be stuck with IPv4-based IPv6 addresses forever.

tuatoru 3y ago

No. The difficulty is social. Everyone would have been fine with "IPV4.2", IPV4 with six octets, because it's just like something they already knew, fixing its one obvious defect, not enough addresses. The consitituency for replacing the hardware/firmware and software stacks would have been there. IPV6 was not just like IPV4 and so people naturally resisted the devaluation of their hard-won knowledge.

ok123456 3y ago

"Ipv4 with more bits" could have a very simple cut-over. You internally update your stack and networks. Up until the cut-over date, the addresses are truncated into IPv4. After the cut-over, they're routable. This could have been given a time table of say 5 years.

p_l 3y ago
No, it didn't work. Other than already mentioned issues of hardware, you also had for years the issue of lots of applications requiring substantial rewrite to support another protocol due to use of BSD Sockets which leaked protocol internals up to application layer. It was a very big and vocal issue about porting to v6 even in early 2000s despite BSD Sockets finally getting a new API (lifted from the Streams-based XTI) that made handling dual stack easier - but everyone still learnt from older manuals. And tricks with time table were tried - vendors would lobby for all sorts of extensions "while they work to update the code", the result was that none did because none wanted to actually put the work to upgrade network stacks and handle dual-stack in applications. After all, IPv6 is not the first attempt to replace the "temporary" solution that was IPv4 whose planned EOL was in 1990.
- comex 3y ago
  > you also had for years the issue of lots of applications requiring substantial rewrite to support another protocol due to use of BSD Sockets Past tense? I still regularly see code that uses BSD sockets and doesn't support IPv6. Actually, I feel like among C and C++ codebases that make direct TCP or UDP connections, the majority are IPv4-only, even in 2023. Though, direct TCP and UDP connections themselves are less popular than they used to be, and so are C and C++...
  - p_l 3y ago
    Past tense on have to write two complete code paths to support v4 and v6 at the same time. Today we have getaddrinfo, so if you're writing from scratch you can just use that, you can also simplify older code with it and get v6 at the same time. But there's a lot of old code that still doesn't use GAI and was never upgraded.
  - deleted 3y ago
    [deleted]
Dagger2 3y ago
v6 basically is v4 with more bits. You could do what you describe with it. The problem is that nobody has the authority to enforce such a timetable on the Internet as a whole, so that's not actually a workable plan.

comex 3y ago

Sure there’s a way. Define a standard way to encapsulate an “IPv4-with-more-bits” packet (let’s call it “IP+”) inside an IPv4 packet. When a router supporting IP+ forwards an IP+ packet to a router that doesn’t support it (assume there’s some way for routers to learn whether their peers support it), it wraps it in an IPv4 packet. When a router receives an IP+ packet wrapped in an IPv4 packet, in unwraps it. In this way, as long as both sides of a connection belong to LANs that support IP+ internally, they can communicate with each other even if some or all of the Internet routers in between only support IPv4. But even if that weren’t a thing, even if you did need all the routers to be replaced, “IPv4 with more bits” would still be better. After all, it’s been decades - the hardware has been replaced. If it were a seamless incremental upgrade, just a switch to flip that enabled “more bits support” and didn’t break anything, then ISPs would have enabled it even when there was little short-term benefit. By now, practically all of the Internet would support it. Instead it’s an entirely separate network, with entirely separate configuration, which historically had a high tendency to break things. No surprise that even today, many people just don’t bother with it.

fulafel 3y ago
Your idea sounds a lot like the 6to4 transition mechanism that was used for several years before it was phased out. It won't "just work" on many networks because they firewall off non-tcp/udp protocols but otherwise it served pretty well.
- oneshtein 3y ago
  Send IP+ by tcp/443, the only working protocol right now.
- p1mrx 3y ago
  The biggest problem with 6to4 is that the anycast gateways (192.88.99.0/24 and 2002::/16) often go to a different network than the one you're paying for transit, so you can't just turn it on for production traffic and expect it to work. The anycast gateways are only used when communicating between 6to4 and native IPv6 addresses, so if 2002::/16 had been the only IPv6 address space, then it would have been more reliable, but then we'd be stuck with IPv4-based IPv6 addresses forever.