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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf