On Tue, 17 Jun 2003 19:33:24 PDT, "Hallam-Baker, Phillip" said: > No, because I design and use applications I really wish that the IETF > had designed a decent NAT box spec rather than adopting the ostrich > position. If my un-NAT'ed box does a LISTEN on some TCP port, that generates no outbound traffic. However, if a SYN packet arrives at my upstream router for my IP address and that port, the router still knows how to deliver it. If my same box running the same software does a LISTEN on a TCP port while behind a NAT, it also generates no outbound traffic. However, if a SYN packet shows up at the NAT box with the NAT box's IP address and that port number on it, the NAT box HAS NO CLUE who to deliver it to. It's pretty easy to show that there is no *transparent* way to make both cases work. If you handwave some magical-pixie-dust packet that is sent out that says "Hey NAT box, I'm doing a LISTEN on port NNNN", then you have to deal with (a) scaling when lots of clients do this, (b) information leakage security issues, and (c) what happens when the application is started in a NON-NAT environment. If you don't sprinkle pixie dust, then the NAT doesn't know what to do without manual configuration... All the while noting that it could very well be 3-4 hops or more across a large enterprise network before you reach a NAT... or your large enterprise network might be acquisition-legacy hell and a packet can traverse 5 NAT boxes without leaving the corporate network. And deciding what the proper behavior of the corporate NAT to the Internet in Chicago should be when an application in the San Fran and Zurich offices both open port 31337 is left as an exercise for the reader. More "gotchas" can be found in RFC3027. Now, what were you saying about ostriches?
Attachment:
pgp00271.pgp
Description: PGP signature