Sam Hartman wrote: >>>>>> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes: > > Keith> I understand. But in practice just knowing your external > Keith> address is often insufficient. You need an intermediate > Keith> server that will forward traffic as well as maintain the > Keith> bindings in both (nay, all) endpoints' NATs. > > Keith> If we're going to standardize NATs of any kind, they need > Keith> to be defined in such a way that no "external" server is > Keith> necessary - not to determine one's external IP address, nor > Keith> to forward traffic between hosts that are all behind NATs, > Keith> nor to maintain state in the NAT, nor to determine a host's > Keith> 'external' IP address or port, nor to listen for traffic > Keith> intended for a host behind a NAT. All of this > Keith> functionality (and more) needs to be "built in" to the NAT > Keith> itself. > > Keith, would the NAT-66 proposal plus some mechanism for a server > inside the NAT to ask the NAT for its global address be sufficient to > meet the needs described above? > > How about the existing proposal plus an IPV6 anycast address for a > stun-like protocol? If not, why not?
I don't think so in either case. The reason I don't think so is that I suspect the NAT traversal problem is really a firewall traversal problem in disguise. People say they want NATs when what they mostly want is stateful firewalls and maybe some topology hiding. We might get them to move to stateless NATs with bidirectional algorithmic mapping and a STUN-like protocol, but they'll still want a statefull firewall to be bundled in to block incoming connections. And if there's a statefull firewall that denies incoming connections by default, there will still be a need for an intermediary in the network "core" that can arrange for traffic to be forwarded between two hosts that are behind firewalls. And there will be little incentive for any network admin to get rid of NAT, because as long as those firewalls are in the way, doing so won't enable many more applications. So if we really want to get rid of NAT, I think we have to resolve a tussle between users and application developers on one hand, and enterprise network operators on the other. The tussle is over two things: (1) how to restrict the kinds of traffic that can be sent over the network, how to communicate those restrictions to apps, and what kind of behavior is reasonable for apps that are presented with such restrictions. (2) to what extent network admins can control what programs are used on hosts that attach to their networks. Hey, I didn't say it was easy. But I don't think anything less will get rid of the need for the kinds of workarounds apps currently have to use to deal with NATs. Even if we got rid of NAT, we wouldn't solve the problem (and NATs wouldn't matter too much) if apps still have to use those workarounds. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf