No. Just imagine the encryption we'd have in IPv4 -- none, and for multiple reasons: too expensive, public crypto was considered a "munition" when IPv4 was deve

No. Just imagine the encryption we'd have in IPv4 -- none, and for multiple reasons: too expensive, public crypto was considered a "munition" when IPv4 was developed, etc. How about IPv6? We'd most likely have 40-bit export ciphers, if anything, but crypto was still considered a "munition" by the US govt when IPv6 work began in the 1990s. Perhaps IPv6 would have taken longer due to that fight, and later adopted 40-bit export if we were "lucky." IPv6 carries a measurable percentage of Internet traffic now, but when it was developed, in the 1990s, public crypto sucked. And so that's what would be baked into IPv6 now, for all time. I totally get the appeal of having all traffic automatically encrypted, it's just that A) IETF would screw it up somehow and B) it would take too long to deploy through "official" channels. It would turn into an unwanted Christmas present, 20 years too late. The alternative offers much stronger crypto and a much faster deployment timetable: let the public build encrypted protocols based on UDP. If they work, maybe people will use them. There's actually been some success here, like with QUIC, Noise, etc. I think we need to get beyond the idea of waiting for standards bodies to give us state-of-the-art. They have a terrible track record. We can do better ourselves, and already are.