Leo Bicknell wrote:

On Fri, Sep 07, 2001 at 05:09:43PM -0400, Andy Dills wrote:

...

One is content, the other a content-delivery mechanism. Think about the post office. It's perfectly acceptable for them to stamp a forwarded address on the envelope to ensure it's delivery, but perfectly unacceptable to modify the content inside.

But NAT goes further. Consider if the post office opened up your letter, looked at the return address on it, saw that was wrong and stuck the new one on it, put it back in the envelope and then sent it on its way. That's exactly what NAT does with some protocols.

Funny story (with a NAT analogy): The US post office will forward mail within the USA for free, but won't redirect mail to outside the USA for free. My roommate moved back to Canada. Rather than re-address (and pay) per-letter, I saved a bunch of his mail up, boxed it, and sent it via the post office. International mail generally gets inspected, which is to say, opened. The package contained a bunch of mail, with valid postmarks and addresses. Somehow, the *contents* got re-injected into the mail system. The mail returned to its original (ie old) address, thus defeating my attempt to bulk-forward it to my ex-roommate. ;-) The moral is, if I wanted my package to survive the broken forwarding mechanism, I should have re-addressed the contents, too. Or, if it absolutely, positively needs to get where you want it to go... don't mail it. (end funny story) IP is the transport layer. While many programs may let us type IP addresses at them, any protocol higher up the stack which involves or relies on IP addresses is, IMHO, badly broken. It would be just as bad to involve MAC addresses. At the very least, it defeats the whole purpose of having a *stack*. smd is correct in his observation of the overloading (network location and ID) being a problem. Generic NAT (1:1 or many:fewer, no special handling of ports or protocols)is incompatible with things that put IP addresses in the payload and expect them to match the headers. If brand X of NAT is messing with the contents, it's probably to work around this incompatibility, or rather to try and fix a broken protocol. (Leo - you are complaining about a NAT box *fixing* a problem for you! Did that occur to you?) Anything that needs to assure identity, even using local knowledge of IP addresses, should at a minimum do so by tunneling, so that the NAT affects on the encasulation, not the encapsulated header+data. (Hello, IPsec.) Or better yet, use some other identity mechansim. Fundamentally, TCP (which is the real issue) is client-server. (E.g.: Syn, syn-ack, ack.) The server must be known; who the client is arbitrary and irrelevant. (Not unlike NANOG. :-) ) It's really this simple: If you need to do non-TCP, server-server stuff, you need a static IP. It doesn't matter whether dynamic IP and port comes from NAT or DHCP - there will always be things you can't do behind those. If you want to do those things, don't go behind one of them. Or implement better protocols that don't break when NAT is used, or place ridulous burdens on ports that need to be opened on firewalls (H.323 ?!?), or better yet, use some kind of 3-way, 3-party handshake to establish peer-peer between NAT'd client-type boxes (for programs that facilitate copyright violations.) And by the way, whatever happened to the notion that the firewall should also be a proxy at the application layer rather than a mere packet-forwarding-and-munging box? Brian Dickson (now at Velocita, but speaking for himself.)