FWIW - I wholeheartedly agree with "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." In fact, I think this (end nodes awareness of their "real" external address and port) should be one of the, if not the, biggest design goals for NAT66 ... assuming we do "define" it. This enables the NAT to still "do its thing", while still retaining the ability for apparent end to end communications. Additionally, something like [ ~UPnP | NAT-PMP | NAT-XC | ALD ] to allow firewall pinhole creation might just be useful, with a note of concern around security of course ... /TJ >-----Original Message----- >From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of >Keith Moore >Sent: Tuesday, November 25, 2008 5:43 PM >To: David Morris >Cc: 'IAB'; 'behave@xxxxxxxx WG'; 'IETF Discussion'; 'IESG IESG' >Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to >application developers > >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 mailing list >Ietf@xxxxxxxx >https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf