<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Mar 2022, 19:41 Dave Taht, <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am deeply concerned by the onrushing move to udp for QUIC, <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">IMO, it's a fad that will die away.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">IMHO, QUIC should also one day become its own protocol number also,<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and with the 64 bit identifier seems plausible to nat thoroughly. </blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">UDPLite is also easily nat-able and widely available. It's original<br>
use case is now gone, but it would be straightforward to just treat it<br>
as another UDP.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Given enough time, seemingly everything becomes HTTP :S (slightly facetious there)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lastly, if we were to look at using up some more protocol space in the<br>
next 20 years, adding 16 or more udp-like protocols would extend<br>
things also.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">M</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>