Re udp port overload on ipv4 (was Re: V6 still not supported)

Thu Mar 10 20:03:58 UTC 2022

On Thu, 10 Mar 2022, 19:41 Dave Taht, <dave.taht at 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

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220310/5d761bf6/attachment.html>