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. :-)
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.
The fact that IS-IS survived as a relevant IP routing protocol says a lot on its own.
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?
With the luxury of hindsight, allowing an admixture of 32-bit and 64-bit addresses strikes me as an obviously clean solution to the one real problem IPv6 solves. But in 1992, that was a complete non-starter.
We have address extensions in v4 packets, we have NAT to help with partial upgrades, and we have a mix of 32-bit and 128-bit addresses (which should be just as obviously clean as a mix of 32-bit and 64-bit addresses, or rather more so due to 64-bits being too small). You don't need to think about whether any of this would have been doable, because we already went and did it.
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