Re: Site local

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: Iljitsch van Beijnum <iljitsch@muada.com>

    > The problem with NAT is not that the addresses in the IP header are
    > changed.

Well, that is a problem (e.g. with IPSec), but you're right, it's more of an
engineering problem than an architectural one.

    > The problem with NAT is that you're not talking to who you think you
    > are talking to. And if you don't know, you can't tell someone else, so
    > it becomes impossible to set up new connections in a different way
    > than from the same source to the same destination as the current
    > session.

Actually, it means you can't use the address namespace to tell someone else
the identity of a third party. You could pass the third party's identity
using some other namespace (e.g. a DNS name), which would then go through
the same process of creating a forwarding tag with local scope (i.e. a
NAT'ed address), and installing the necessary bindings.

Which leads us to the *real* architectural problem with NAT, which is that
it means that there is critical state (those bindings) stored in boxes out
on the network. This hasn't proved to be a major problem so far, as most
uses of NAT boxes (e.g. the one in front of the network in my house) are i)
on the only path out anyway, and ii) fairly reliable.

However, were we to start seeing configurations where i) there are alternate
paths from the source to the destination, and ii) there is a NAT box in the
path *after* the two paths split, then we'd have something of a problem.

	Noel