alt Hacker Newsyou repeat several times that IAB was too ivory tower and refused to address the critical issues of the day, but don't really go into much detail. I wrote an early implementation of v6, before ratification (and even won the UNH interop prize!). and I struggle to understand exactly what blame you are placing at their feet. just that maybe they took the e2e principle too seriously and should have backed the awful bodge that was NAT?
Replies
It is hard to cover decades of politics in one post on here, but rather than the IAB being in an ivory tower, at least for the first 15 years, I think it was ruled by inertia that was changing, and suffering a bit from The Mythical Man Month second system syndrome.
In the beginning it was an experiment and should have been ambitious, the IETF had just moved to CIDR which bought almost a decade of time, and they should have aimed high.
It is just when you significantly change a system, you need to show users how to accomplish the work they are doing with the old system, even if how they do that changes. If you can't communicate a way to replace their old needs, or how that system is fitting new needs that you could never have predicted, you need to be flexible and demonstrate that ability.
If you look at the National Telecommunications and Information Administration. [Docket No. 160810714-6714-01] comments
Microsoft: https://www.ntia.gov/sites/default/files/publications/micros... ARIN: https://www.ntia.gov/sites/default/files/publications/arin_c...
You will see that the address space argument is the only real one they make. It isn't coincidence that rfc7599 came about ~20 years later when 160810714-6714-01 and federal requirements for IPv6 were being discussed.
If you look at the #nanog discussions between RFC 1883 (ipv6) (late 1996) being proposed and Ipv4 exhaustion in early in (2011) it wasn't just the IAB that was having philosophical discussions around this.
Both rfc3484 and rfc6724 suffered from the lack of executive sponsorship as called out in the above public comments. And the following from rfc6724's intro is often ignored with just pure compliance:
> They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection.
There are many ways that could have played out different, but I noticed Avery Pennarun's last update to that post pretty much says the same in different words.
https://tailscale.com/blog/two-internets-both-flakey
> IPv6 was created in a new environment of fear, scalability concerns, and Second System Effect. As we covered last time, its goal was to replace The Internet with a New Internet — one that wouldn’t make all the same mistakes. It would have fewer hacks. And we’d upgrade to it incrementally over a few years, just as we did when upgrading to newer versions of IP and TCP back in the old days
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. :-)