In some email I received from Mikael Olsson, sie wrote:
[...]
> > Applications or protocols that assume end-to-end integrity of the
> > address will fail when traversing a NAT. (TCP was specifically
> > designed to take advantage of, and reuse the IP address in
> > combination with its ports for use as a transport address.)
>
> Is he saying that TCP doesn't work through NAT?
> It is true that you cannot TCP out of the blue to a host
> "protected" by a NAT, but, again, this is also true of firewalls.
> This COULD be the case of many-private-to-few-public NAT,
> which, to my mind, is an abomination.
> Asuume hosts "P1" and "P2" are behind such a NAT, and there's
> a web server "WWW" on the outside.
> P1 opens the connection P1:1024->WWW:80, which will appear
> as NAT1:1024->WWW:80, and finishes it.
> P2 opens the connection P2:1024->WWW:80, which will get
> the now free address NAT1; NAT1:1024->WWW:80, which may
> not work for a couple of minutes.
This depends on your implementation of NAT. One of the address
mapping methods available with IP Filter allows you to take a block
of addresses, X, in your internal network and map them to a block of
public addresses, Y, using port number multiplexing. For each bit
of difference in the netmask for X and Y, you `borrow' a bit from
the port number space (64k - 1024 (reserved port garbage needs to be
avoided)). The actual network I designed this for had a /12 being
mapped into a /19 or /20 (don't quite remember now) and accountability
was a _requirement_. Of course, it works when the netmask of Y is 32.
Sure, you lose the IP# to IP# mapping, but that should be neither here
nor there.
Darren
Received on Sep 09 1999
Intro
