4 ms·

The myth that it would have been easier to switch to a protocol that is just ip4 with more bits needs to die. The companies too cheap or lazy to adopt ipv6 wou

The myth that it would have been easier to switch to a protocol that is just ip4 with more bits needs to die. The companies too cheap or lazy to adopt ipv6 would still be clinging to classic ipv4 with NAT.

DougMerritt 3y ago
ipv4 with NAT is in fact still extremely common, but skipping that, which parts of ipv6 (beyond extra bits) do you regard as essential versus which parts are over-engineered?
- lmm 3y ago
  What "parts of ipv6 (beyond extra bits)" are you concerned about? As far as I know there aren't any, unless you're talking about extensions or something?
  - DougMerritt 3y ago
    I haven't been fresh on this stuff for years, but there are some other differences. Included multicast, true QoS, included IPsec, a few other things. It's just that I sometimes see people advocating upgrading from ipv4+NAT to ipv6 for reasons beyond address bits, so I thought that's where you (edit, "they", oops) were coming from. I was just curious.
stephen_g 3y ago
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++...
cyberax 3y ago
Is it such a myth, though? IPv6 still causes troubles in deployment. For example, Android phones (still!!!) don't support stateful DHCPv6. Moreover, DHCPv6 was designed by idiots and out of many options for DUIDs it doesn't allow the most logical one: a user-specified host name. PMTU in IPv6 is even _more_ broken than in V4 because extension headers just plain don't work in the wide Internet.
- ripdog 3y ago
  > For example, Android phones (still!!!) don't support stateful DHCPv6. That's Google's fault, not the protocol's.
- drewg123 3y ago
  Thank you for mentioning extension headers. IMHO, they are the worst mistake in IPv6, because they are unbounded. If you design your hardware to handle extension headers, there are all kinds of edge cases to worry about, and regression testing the different combination of headers is nearly impossible. So lots of hardware vendors just don't handle them (or handle just one), which means they might as well not exist.
paulddraper 3y ago
That's....not true.
deleted 3y ago
[deleted]
ianburrell 3y ago
IPv4 with more bits is usually proposed to have 64-bit (or even just 40-bit). IPv6 with 128-bit seems excessive but it makes transition mechanisms possible. NAT64 encodes the IPv4 address in the 64-bit host portion. MAP is even more interesting since it stores the whole NAT address and port for stateless CGNAT.

DougMerritt 3y ago

ipv4 with NAT is in fact still extremely common, but skipping that, which parts of ipv6 (beyond extra bits) do you regard as essential versus which parts are over-engineered?

lmm 3y ago
What "parts of ipv6 (beyond extra bits)" are you concerned about? As far as I know there aren't any, unless you're talking about extensions or something?
- DougMerritt 3y ago
  I haven't been fresh on this stuff for years, but there are some other differences. Included multicast, true QoS, included IPsec, a few other things. It's just that I sometimes see people advocating upgrading from ipv4+NAT to ipv6 for reasons beyond address bits, so I thought that's where you (edit, "they", oops) were coming from. I was just curious.

stephen_g 3y ago

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

cyberax 3y ago

Is it such a myth, though? IPv6 still causes troubles in deployment. For example, Android phones (still!!!) don't support stateful DHCPv6. Moreover, DHCPv6 was designed by idiots and out of many options for DUIDs it doesn't allow the most logical one: a user-specified host name. PMTU in IPv6 is even _more_ broken than in V4 because extension headers just plain don't work in the wide Internet.

ripdog 3y ago
> For example, Android phones (still!!!) don't support stateful DHCPv6. That's Google's fault, not the protocol's.
drewg123 3y ago
Thank you for mentioning extension headers. IMHO, they are the worst mistake in IPv6, because they are unbounded. If you design your hardware to handle extension headers, there are all kinds of edge cases to worry about, and regression testing the different combination of headers is nearly impossible. So lots of hardware vendors just don't handle them (or handle just one), which means they might as well not exist.

paulddraper 3y ago

That's....not true.

deleted 3y ago

[deleted]

ianburrell 3y ago

IPv4 with more bits is usually proposed to have 64-bit (or even just 40-bit). IPv6 with 128-bit seems excessive but it makes transition mechanisms possible. NAT64 encodes the IPv4 address in the 64-bit host portion. MAP is even more interesting since it stores the whole NAT address and port for stateless CGNAT.