logoalt Hacker News

perennialmindyesterday at 10:23 PM2 repliesview on HN

CLNP had existing implementations and was fundamentally sound. On its technical merits, RFC1347 TCP and UDP with Bigger Addresses (TUBA) wins hands-down. But it took too long for the ISO to agree to a hand-off (the IETF wanted to be able _fork_ it, which seems nuts to me) and the IAB required ownership.

But aside from that, I actually do think we could have baked address extensions into the existing packet format's option fields and had a gradual upgrade that relied on that awful bodge that was (and is) NAT. And had a successful transition wherein it died a well-deserved death by now. :-)


Replies

Dagger2today at 3:18 AM

> we could have baked address extensions into the existing packet format's option fields and had a gradual upgrade that relied on that awful bodge that was (and is) NAT

We did and do have this. I wrote about the option fields part in [1] but we also have NAT as part of the migration, in the form of NAT64.

Not only was doing these things not enough for us to be done by now, they weren't even enough to stop you from moaning that we didn't do them! How could anything have been good enough if these are the standards it's judged by?

[1]: https://news.ycombinator.com/item?id=47829991

convolvatronyesterday at 11:54 PM

I didn't have too much visibility in the CLNP world, although we did have a test network where I worked. My personal issue was that I just couldn't read the massively overwrought ISO specs. My admittedly biased viewpoint there wasn't anything really wrong with Ipv6, but the providers were quite happy with the way things were and actually kind of liked the internet-as-television model that we ended up with.

I do think that the IETF didn't realize that they were losing their agency, so its very likely that TUBA would have made the difference. not for any technical reason, but that it would have been a few years earlier when people were still listening.

show 1 reply