On Thu, 10 Mar 2022, 19:41 Dave Taht, <dave.taht@gmail.com> wrote:
I am deeply concerned by the onrushing move to udp for QUIC,
IMO, it's a fad that will die away. IMHO, QUIC should also one day become its own protocol number also,
If that was feasible, we would likely be using SCTP by now. TCP, UDP, and ICMP are likely to be the only reliable IP protocols for the foreseeable future on the internet. (As in, inter-domain) and with the 64 bit identifier seems plausible to nat thoroughly. So long as you're doing a proper three tuple NAT, there shouldn't be any need to expand the address space of the transport layer -- the MAP-T approach of constraining it down to e.g. 256 ports seems the most compatible. UDPLite is also easily nat-able and widely available. It's original
use case is now gone, but it would be straightforward to just treat it as another UDP.
Given enough time, seemingly everything becomes HTTP :S (slightly facetious there) Lastly, if we were to look at using up some more protocol space in the
next 20 years, adding 16 or more udp-like protocols would extend things also.
We've got tens of thousands of good ports on each of TCP and UDP already. No need for making more room when the existing ones work. In fact, I'd wager most people wouldn't notice if only TCP/80 and TCP/443 were working, with a DNS resolver at the NAT border. Even NTP is becoming more and more obsolete, as I understand it there are an increasing number of systems that just pull the time and date from the Date header of an HTTP request. M