Hacker News new | ask | show | jobs
by xorcist 1760 days ago
It would still be incompatible with IPv4. It couldn't have avoided the complexity of a prolonged dual stack situation. So it would have had at least comparable deployment complexity.

And when you're incompatible anyway, why wouldn't you at least simplify headers and global routing? BGP has always been on the verge of imploding.

A backwards compatible IPng had been great, but no credible design was ever put forward.

2 comments

No credible design is possible, because when people ask for a backwards-compatible IPng what they're really asking for is a forwards-compatible IPv4, and they can't have it because v4 isn't forwards compatible.

IPv6 is backwards compatible with v4 in a great many different ways. You've got dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... you could make a reasonable argument that it has too many methods of backwards compatibility, even. But obviously v4 isn't forwards compatible with it, because v4 isn't forwards compatible with any longer address length, and the time to fix that was in the 70s.

That's not something that can be changed without replacing v4. In fact, if it could be, we wouldn't need a new protocol in the first place.

A big chunk of the problem was the BSD Sockets, which unlike TLI/XTI leak implementation details like crazy, meaning every BSD Sockets application effectively hardcoded IPv4 behaviours.
Gratuitous changes to "fix" things is exactly why adoption took forever. Look at nonsense like IPv6 extension headers. The number of extension headers is UNBOUNDED. This is HORRIBLE to deal with in hardware, and not pleasant in software.