Hacker News Reader

> NAT also destroyed much of the end-to-end principle. If you don't have a real IP address and relies on a NAT router to forward your data, it needs to be in a protocol the router recognizes.

Not necessarily. Many protocols can survive being NATed if they don't carry IP/port related information inside their payload. FTP is a famous counterexample - it uses a control channel (TCP21) which contains commands to open data channels (TCP20), and those commands specify IP:port pairs, so, depending on the protocol, a NAT router has to rewrite them and/or open ports dynamically and/or create NAT entries on the fly. A lot of other stuff has no need for that and will happily go through without any rewriting.

I think we agree. Of course a NAT router with an application proxy such as FTP or SIP can relay and rewrite traffic as needed.

TCP and UDP have port numbers that the NAT software can extract and keep state tables for, so we can send the return traffic to its intended destination.

For unknown IP protocols that is not possible. It may at best act like network diode, which is one way of violating the end-to-end principle.

Actually the observation about ports being mostly a TCP/UDP feature is a very good point I had failed to consider. This would indeed greatly limit the ability of a NAT gateway - it could keep just a state table of IP src/dst pairs and just direct traffic back to its source, but it's indeed very crude. Thanks for bringing it up!

You can NAT on IP protocol as well, just not to more than one per external IP.

Of course NAT allows application layer protocols layered on TCP or UDP to pass through without the NAT understanding the application layer – otherwise, NATted networks would be entirely broken.

The end-to-end principle at the IP layer (i.e. having the IP forwarding layer be agnostic to the transport layer protocols above it) is still violated.

You can NAT on IP protocol as well, just not to more than one per external IP.

I guess most people mean NAPT/PAT when they say NAT

There is little point in inventing new protocols, given how low the overhead of UDP is. That's just 8 bytes per packet, and it enables going through NAT. Why come up with a new transport layer protocol, when you can just use UDP framing?

Agreed. Building a custom protocol seems “hard” to many folks who are doing it without any fear on top of HTTP. The wild shenanigans I’ve seen with headers, query params and JSON make me laugh a little. Everything as text is _actually_ hard.

A part of the problem with UDP is the lack of good platforms and tooling. Examples as well. I’m trying to help with that, but it’s an uphill battle for sure.

I think the "problem" of sending data is a lot harder without some concept of payloads and signaling. HTTP just happens to be the way that people do that but many RPCs like zeromsg/nng, gRPC, Avro, Thrift, etc work just fine. Plenty of tech companies use those internally.

Some of this is hurt by the fact that v8, Node's runtime, has had first class JSON parsing support in but no support for binary protocol parsing. So writing Javascript to parse binary protocols is a lot slower than parsing JSON.

> You left out ICMP, my favourite!

Even ICMP has a hard time traversing NATs and firewalls these days, for largely bad reasons. Try pinging anything in AWS, for example...

Have to say that I don't encounter any problems pinging hosts in AWS.

If any host is firewalling out ICMP then it won't be pingable but that does not depend on the hosting provider. AWS is no better or worse than any other in that regard, IME.

Doesn't really have anything to do with nat though.