>>>>> "Keith" == Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> 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'm a bit concerned about adding requirements that would involve
solving the NAT discovery problem. We've already had a lot of bad
luck with that approach in protocols like midcom, nsis, etc.
In contrast, in environments where it works, stun has been quite successful.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf