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?
pgpV3G6reGOle.pgp
Description: PGP signature