Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]