3 ms·
Ask HN: Will there ever be a UDP2/TCP2/ICMP2?
(I'm not sure how to submit to Ask HN properly, am I doing this correctly?)
I'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's strictly 16 bit is because of the address field in UDP/TCP/similar headers (correct me if I'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.
So, would there every be a chance that something so fundamental in the internet will be replaced? Are some protocols "set in stone" for the rest of Internets lifespan?
- ggm 8y agoQuic
- detaro 8y agois UDP based, exactly because it is so hard to do anything that isn't based on TCP/UDP/ICMP
- ggm 8y agoIt 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 8y agoBut 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 8y agoTrue. 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)
- badrabbit 8y agoThere 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
- jlgaddis 8y agoNote 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.
- fulafel 8y agoAs 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