As far as I can tell, most of what is being asked for here has little,
if anything, to do with NAT. To paraphrase:
If we are going to have firewalls which block incoming connections,
communication between entities behind such firewalls should still be
possible without any "external" servers.
That is a tall (not impossible, but quite tall) order, which we have
attempted to address several times with little effect.
And let us be very clear. Network admins have been asking for and using
such features for at least 18 years, well before NAT.
I would recommend separating the problems. The NAT solution, as I
understand it, does not make this problem worses. That is about all one
can ask of the NAT side of the equation.
Yours,
Joel M. Halpern
TJ wrote:
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf