One of the basic principles of IP networking is the "End to End model." The
essence of it is that intermediate devices (e.g. routers) do not know more
about any transaction in progress than the end points, and therefore the
end points should keep the necessary state information, and the
intermediate devices should not fiddle with the packets as they fly by.

Network Address Translation (NAT) flys right into the face of this
architectural principle: a NAT device "translates" the IP addresses in
packet headers. However, that's not all: in some NAT configurations, to
properly "hide" the host or network that you're translating, you must
modify not only the IP header, but the packet data payload, for cases where
the data payload contains IP addresses which are not compatible with your
network design. Examples include DNS and FTP. I did not see support for
these types of translations in the NetBSD NAT.

A minor architectural surprise for those of you planning on using (or
actually using) NAT in your networks: it will not work in conjunction with
IP security.

If you authenticate or encrypt, the NAT will no longer be able to
undetectably modify the packet header or data payload. An authentication
will fail, and a translator can't modify what it can't decrypt. This is as
it should be; doing NAT is a violation of the end-to-end model of IP
networking.

Point being: you'll have a lot less pain in the long run if you avoid using
NAT.

	just a word to the wise,

	Erik Fair <fair@clock.org>