Hacker News new | ask | show | jobs
by p_l 1762 days ago
Around 1990~1991, the TUBA proposal was already ready to go with two implementations (one on hardware router), bringing addresses to iirc either 160bits or 144 bits (don't recall exactly, been long time). Might have been better if they went for 144 bit host name and embedded port numbers in the last 2 bytes, but the point was to run TCP and UDP close to unchanged.

Then IPng got started and for most of 1990s IETF played with sweeping changes while "temporary solution" that was IPv4 entrenched itself in worse and worse ways.
1 comments
drewg123 1762 days ago
I was an undergrad then, and wasn't really aware of this sort of thing. I just went and read the TUBA RFC (rfc1347), and it looks like CNLP was no walk in the part either. From the RFC: CLNP contains a number of optional and/or variable length fields. For example, CLNP allows addresses to be any integral number of bytes up to 20 bytes in length

Did anybody advocate for the simple approach of just expanding the in_addr from 32 to 64 bits, calling it IPv5 and being done with it? That's what I think would have been the right thing to do..

link
xorcist 1762 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.

link
Dagger2 1762 days ago
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.

link
p_l 1762 days ago
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.
link
drewg123 1762 days ago
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.
link
p_l 1762 days ago
I believe the specific evolution called for using full length addresses for simplicity - i.e. CLNP with always 20byte long address fields.
link