[gruturo]

> 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.

[xorcist]

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.

[gruturo]

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!

[Hikikomori]

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

[lxgr]

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.

[Hikikomori]

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