[Dagger2]

> 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

[perennialmind]

My point was meant purely as an intellectual exercise, not a critique of engineering choices made in the face of adverse practical realities. My apologies if it came across otherwise.

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.

[Dagger2]

But mine was that you don't need to do this as an intellectual exercise, because we got basically all the things you're asking for.

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.