3 ms·

IP64 would have worked, and would have kicked the can much further than another few decades. If I were asked to invent IP 2.0 I'd have suggested just extending

by api 11y ago

IP64 would have worked, and would have kicked the can much further than another few decades. If I were asked to invent IP 2.0 I'd have suggested just extending the V4 address space by another 32 bits and calling it a day. But I do see the advantage of big addresses. They give you room for meaningful cryptographic semantic information and stateless auto configuration, both of which are very valuable in big distributed systems and for security. So yeah, could have been simpler but not a big deal. Things like struct sockaddr_storage make programming it pretty easy too, but most older devs aren't familiar with them.

zzalpha 11y ago
IP64 would have worked, and would have kicked the can much further than another few decades. If I were asked to invent IP 2.0 I'd have suggested just extending the V4 address space by another 32 bits and calling it a day. And you'd still have to rewrite all software to take advantage of it. Everyone who thinks they could've come up with a better solution seems to conveniently forget that no solution would've both extended the address space while providing free backward compatibility with v4. Those are, quite literally, incompatible goals. Any hacky solution you do come up with (like, say, NAT64) applies to IPv6, as well. Meanwhile, IPv6 goes on to address a whole host of other issues, like the mess that is CIDR, simplified autoconfiguration, built in address randomization/privacy extensions, etc.
- mprovost 11y ago
  I don't think that's true - there were proposals that extended the address space in a backwards-compatible way but they were rejected in favour of a clean-slate approach that required rewriting everything and breaking existing networks.
  - zzalpha 11y ago
    Specifics, please. How do you extend the address space such that old devices in legacy addresses can communicate with new devices in an extended address space without NAT64-like hacks.
    - mprovost 11y ago
      This is probably the best historical document looking at the original discussions around IPng (which eventually became v6). Interestingly these debates were happening right around the time of the invention of the www so there isn't a lot online today. https://tools.ietf.org/html/rfc1454 https://tools.ietf.org/html/rfc1454 Section 6 (Transition Plans) talks about plans to use new headers or IP Options to carry the extra information for the new protocol in an IPv4 packet. In the end they went for the alternative which was not to have a transition plan, they went for the dual stack approach instead. The SIP proposal is interesting, it's basically the same as v4 but with 64 bit addresses. They were worried that it might not be enough, of course their predictions about exhausting the 32 bit address space were off by decades.
      - zzalpha 11y ago
        That section makes my point for me. From the text: (a) That IPng hosts can also use IPv4 or (b) There is translation by an intermediate system And that "The transition plans espoused by the various proposals are simply different combinations of the above." Those options are precisely equivalent to dual stack and NAT64 respectively. No method of extending the address space van avoid doing one of the two. Amusingly, it even predicts the situation today, noting that "Experience would tend to show that all these things will in fact happen, regardless of which protocol is chosen." The mistake the committee made was dismissing NAT immediately instead of standardizing and approach alongside dual stack, to provide operators with options.
- p1mrx 11y ago
  An interesting thought experiment is "What would the Internet be like if everyone used 6to4, without the anycast gateways?" I think it would have been deployed more rapidly, at the cost of being architecturally hideous.
mprovost 11y ago
Personally I think there is still room for a new version of IP. v6 is still only in single digits. If something better came along (that was backwards compatible!) you could potentially outstrip it. Just because some committee made a bad decision 20+ years ago doesn't mean that the discussion is over. A lot of the people implementing these solutions were children when v6 was designed and they might have new ideas. A 64 bit, backwards compatible version of IP could be a winner. Part of the problem of course is that most people still don't see v4 as needing a replacement because it's still working.

by api 11y ago

zzalpha 11y ago

IP64 would have worked, and would have kicked the can much further than another few decades. If I were asked to invent IP 2.0 I'd have suggested just extending the V4 address space by another 32 bits and calling it a day. And you'd still have to rewrite all software to take advantage of it. Everyone who thinks they could've come up with a better solution seems to conveniently forget that no solution would've both extended the address space while providing free backward compatibility with v4. Those are, quite literally, incompatible goals. Any hacky solution you do come up with (like, say, NAT64) applies to IPv6, as well. Meanwhile, IPv6 goes on to address a whole host of other issues, like the mess that is CIDR, simplified autoconfiguration, built in address randomization/privacy extensions, etc.

mprovost 11y ago
I don't think that's true - there were proposals that extended the address space in a backwards-compatible way but they were rejected in favour of a clean-slate approach that required rewriting everything and breaking existing networks.
- zzalpha 11y ago
  Specifics, please. How do you extend the address space such that old devices in legacy addresses can communicate with new devices in an extended address space without NAT64-like hacks.
  - mprovost 11y ago
    This is probably the best historical document looking at the original discussions around IPng (which eventually became v6). Interestingly these debates were happening right around the time of the invention of the www so there isn't a lot online today. https://tools.ietf.org/html/rfc1454 https://tools.ietf.org/html/rfc1454 Section 6 (Transition Plans) talks about plans to use new headers or IP Options to carry the extra information for the new protocol in an IPv4 packet. In the end they went for the alternative which was not to have a transition plan, they went for the dual stack approach instead. The SIP proposal is interesting, it's basically the same as v4 but with 64 bit addresses. They were worried that it might not be enough, of course their predictions about exhausting the 32 bit address space were off by decades.
    - zzalpha 11y ago
      That section makes my point for me. From the text: (a) That IPng hosts can also use IPv4 or (b) There is translation by an intermediate system And that "The transition plans espoused by the various proposals are simply different combinations of the above." Those options are precisely equivalent to dual stack and NAT64 respectively. No method of extending the address space van avoid doing one of the two. Amusingly, it even predicts the situation today, noting that "Experience would tend to show that all these things will in fact happen, regardless of which protocol is chosen." The mistake the committee made was dismissing NAT immediately instead of standardizing and approach alongside dual stack, to provide operators with options.
p1mrx 11y ago
An interesting thought experiment is "What would the Internet be like if everyone used 6to4, without the anycast gateways?" I think it would have been deployed more rapidly, at the cost of being architecturally hideous.

mprovost 11y ago

Personally I think there is still room for a new version of IP. v6 is still only in single digits. If something better came along (that was backwards compatible!) you could potentially outstrip it. Just because some committee made a bad decision 20+ years ago doesn't mean that the discussion is over. A lot of the people implementing these solutions were children when v6 was designed and they might have new ideas. A 64 bit, backwards compatible version of IP could be a winner. Part of the problem of course is that most people still don't see v4 as needing a replacement because it's still working.