You can't "drive adoption" of anything new in the basic IP protocol space. You're kicking a dead mule. ISPs and IT departments don't care and have little reason

You can't "drive adoption" of anything new in the basic IP protocol space. You're kicking a dead mule. ISPs and IT departments don't care and have little reason to say anything but "no" or "its on the road map" (forever). The present IP stack is fixed in amber, and we'll be lucky to see IPv6 complete adoption. At this point I'd give IPv6 a 50/50 chance of failure. Reasons for this: * No upstream incentive due to little or no competition and not enough "killer apps." * Security FUD: if it's new then it might allow something currently not understood. * ISP desire to control traffic and prohibit anything new. * First thing IT will do if there's a problem is "turn the new thing off." (This happens a lot with IPv6 even if IPv6 is not a cause.) * Vendors with a vested interest in treating the disease (supporting technical debt) rather than curing the patient (actually fixing the problem, reducing the need for complex solutions). My point in the original comment was that QUIC might help stop further ossification by making UDP actually necessary. Otherwise we face the potential for removal of UDP and even removal of non-standard TCP ports, eventually leading to "http only" networks. ISPs and IT departments would like that since less capability equals less support queries and less to monitor. If IP were re-designed today I would suggest at least non-cryptographic but difficult to efficiently modify authentication of all fields (e.g. keyed or nonced checksums), and obfuscation (fast minimal encryption?) of everything under the IP header. No NAT, and nothing useful to filter on. If it's visible and mutable it will become ossified since people will MITM it. That way there would be no choice but to fix endpoint security instead of deploying firewalls and no choice but to adopt IPv6 instead of NAT. You couldn't temporarily work around fundamental problems by nerfing the net. I think there's a general principle here. If easy short term fixes that incur long term technical debt are allowed, they will be deployed. If such a hack is deployed in a federated or decentralized system, it becomes permanent unless extra-systemic means (e.g. legislation or financial incentives) are used to force it to be removed. Therefore federated and decentralized systems should not permit such hacks. Front load the pain by forcing the problem to actually be fixed. This is one thing block chains kind of get right. Everything is cryptographically hashed and authenticated. You can't modify state unilaterally. You either have a compliant node or you don't, and changes must be adopted globally either as soft or hard forks.