David Morris wrote:
Actually, he did not say the server forwarded traffic, just that it
provided a way to learn how 'my' address was mapped through 'my' nat.
I understand. But in practice just knowing your external address is
often insufficient. You need an intermediate server that will forward
traffic as well as maintain the bindings in both (nay, all) endpoints' NATs.
If we're going to standardize NATs of any kind, they need to be defined
in such a way that no "external" server is necessary - not to determine
one's external IP address, nor to forward traffic between hosts that are
all behind NATs, nor to maintain state in the NAT, nor to determine a
host's 'external' IP address or port, nor to listen for traffic intended
for a host behind a NAT. All of this functionality (and more) needs to
be "built in" to the NAT itself.
Furthermore it's not sufficient to just define a NAT with a
bidirectional, algorithmic mapping (in order to avoid some of these
problems) because what people have come to expect from NAT (and to rely
on) is that incoming connections are denied by default.
So really, to be viable, any NAT standard needs to include some amount
of firewall functionality. And the firewall needs to be able to keep
working even if the NAT function is turned off.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf