Sam Hartman wrote:
"Keith" == Keith Moore <moore(_at_)network-heretics(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf