
Ask HN: Will there ever be a UDP2/TCP2/ICMP2? - baalimago
(I&#x27;m not sure how to submit to Ask HN properly, am I doing this correctly?)<p>I&#x27;m fairly new to the internet protocols, but while studying NAT translations it struck me that the enforced 16 bit max port number could be problematic for several reason (primary because they will run out), and the reason that it&#x27;s strictly 16 bit is because of the address field in UDP&#x2F;TCP&#x2F;similar headers (correct me if I&#x27;m wrong). Almost every other protocol on the internet is receiving continuous updates, but these headers have stayed the same for decades, causing potentially harmful restrictions.<p>So, would there every be a chance that something so fundamental in the internet will be replaced? Are some protocols &quot;set in stone&quot; for the rest of Internets lifespan?
======
badrabbit
There is ipv6 so you wouldn't use NAT (with few exceptions).

IPV4 is a legacy deprecated protocol people keep on using.

More specifically, port addeess translation (what you seem to be talking about
when you say 'NAT') would not have have a problem with 16bit port numbers if
you can use a large pool of IP addresses for the outside interface(which is
almost always the case with natv6).

Even with IPv4 it's 65535 sessions per IP, that's a ton of simultaneous
sessions. Any router that would do PAT (that I can think) would encounter
resource issues at over 20K stateful sessions but if your router can handle it
all you have to do is add one more external ip to add capacity for 65535 more
sessions.

Lastly,you can always do NAT/PAT upstream before it hits the final routers.per
access vlan for example or per host if individual hosts need >65535 sessions
(adding an ip to the host if that number is greater).

Let's say a UDPv2 doubles it to 32bit: for a device pushing 1 million
packet/sec (around 1Gbps) that comes out to an added 16Mbps that is pure waste
unless someone has a very unique situation where they would push >65535
sessions per IP.

There is QUIC for an alternative layer4 as well as a few others. UDP and TCP
both do their jobs well,if additional needs arise it would be an entirely new
protocol,not an updated version of tcp and udp

------
fulafel
As the ipv6 transition is well on its way¹, doing this would be just starting
again from 0 with an inferior solution. NAPT is just a kludge after all and
not a full replacement for native internet connectivity.

¹
[https://www.google.com/intl/en/ipv6/statistics.html](https://www.google.com/intl/en/ipv6/statistics.html)

------
jlgaddis
Note that "NAT translations" (for IP) actually use a combination of five
different fields (a "5-tuple"): source IP address, source port, destination IP
address, destination port, and protocol.

This means that you aren't limited to, for example, 65,535 TCP sessions on a
single host even though there are only that many ports available.

------
ggm
Quic

~~~
detaro
is UDP based, exactly because it is so hard to do anything that isn't based on
TCP/UDP/ICMP

~~~
ggm
It has session layer behaviour. For the internet stack, that's new. It's UDP
but integrated bbr so has rate limiting feedback like TCP.

~~~
detaro
But it does not live on the same level in the stack as UDP/TCP (unlike SCTP,
which had multiple streams years ago, but has been stopped by the
unfriendlyness of the Internet to things that are not UDP/TCP). It's
interesting, but if anything it's a negative example in regard to the OPs
question.

~~~
ggm
True. But it's the most innovative we've seen in years, and it's informative
(to me at least) around the question: maybe we won't, just as HTTPS went on
top of the transport layer not alongside it, maybe new protocol work is going
on above transport for a reason?

OSI session layer was useful. Not having one has caused some tensions (former
OSI implementor btw)

