> What other choice do we/did we have ? Being more deliberate and serious about NAT, rather than taking the position that "NAT is evil". In particular, this w

> What other choice do we/did we have ? Being more deliberate and serious about NAT, rather than taking the position that "NAT is evil". In particular, this would mean throwing away four assumptions about IP addresses: -- non-ephemerality (an IP address survived for long periods of time, often not even changing across reboot) -- global uniqueness (your IP address is in use only by you) -- isotropy (what you think your IP address is, is what all the parties you communicate with think your IP address is) -- non-overloading (one IP address per host, or at most one address per interface) In the years since the early 1990s when IPv6 was still being decided, the first assumption was weakened by DHCP, the second by RFC 1918, and the third by NAT. The fourth is somewhat weakened by Dual Stack IPv4 and IPv6. If instead of dealing with issues like https://www.wikiwand.com/en/Happy_Eyeballs https://www.wikiwand.com/en/Happy_Eyeballs under Dual Stack it were applied in IPv4-only settings where a host would acquire and use different addresses with different prefixes & masks, multihoming and mobility would have gotten easier faster. However, application layers that embed IPv4 addresses into them were commonplace and even today when a smartphone can swap addresses rapidly (disconnect from wifi, fall-back through 4g or the like, connect to new wifi) causing user-noticeable disruptions. IPv6 does not help in this situation because the same assumptions are in the way: addresses are long-lived, a host uses approximately one globally unique address at a time, and IPv6's "NAT is evil" foundations make using NAT more bug-prone -- and NAT involving IPv6 on at least one side of the NAT is in widespread use. CATNIP was one IPng proposal wherein there would be canonical translations among various protocols, with extensibility to add yet more protocols, that would face these problems and more like them head-on. It was rejected because the compromise SIP+PIP was "more ready" to be rolled out immediately, and taking the time to get the details of CATNIP right (or do it iteratively) would mean a delay in standardization and thus deployment. That was more than twenty years ago. Standardization was done pretty fast for IPv6... The lessons of slow and reluctant IPv6 deployment have been mis-learnt as, "we can never introduce a new network layer protocol in less than twenty years". Because (in part) isotropy and global uniqueness are taken to mean that there's no protocol translation "in the middle" or "at the edges" allowing completely uncoordinated deployment by any size site (from a backbone ISP to an individual household). That is, as with IPv6, the expectation is dual stack with one stack doing the heavy lifting, and with the other stack used only in coordination with some "upstream" or "peer" network. Finally, I think the wish to sunset IPv4 is backwards. IPv4ever should be embraced, with IPv4-only devices never needing to upgrade to talk to the parts of the Internet that no longer talk IPv4 themselves. Protocol translation and Application Layer Gatwaying are things that should be made to work well, rather than things to be called "evil". The lessons learned in doing that should be applied to progressing beyond IPv6, too.