Subject: RE: arguments against NAT?

From: "Michel Py" <[email-masked]>
Date: Tue, 2 Dec 2003 07:44:56 -0800

> Melinda Shore wrote:
> although frankly this is one particular area where
> there's a clear and growing divide between this
> community and the network administrator community
> (particularly enterprise and residential).

Because this community has long ignored real problems and followed the
lead of protocol fanatics or rhetoricians that for the sake of technical
elegance design protocols and architectures that look real nice on paper
and don't solve real world issues.

> We've known about these problems for a very long time
> and the argument that these problems are a serious
> impediment to network {stability,robustness,whathaveyou}
> have not been accepted by the people who deploy real
> networks.

The seriousness of the impediments is grossly overblown in this
community. In theory, practice and theory are the same. In practice,
they're not. If NAT was that bad, nobody would use it. NAT is bad, but
not bad enough to disappear.

> I imagine we're going to be running into a similar
> situation with the mad use of tunnels in the
> not-too-distant future.

The market as always will pick the solution that is the best compromise.
Just like NAT, saying that tunnels are bad is as efficient as going duck
hunting with an accordion. If this community does not want to see mad
use of tunnels, it must provide a better solution instead of whining. It
must design protocols and architectures with users in mind, not to
please software developers.

Saying that people that deploy real networks should not use NAT because
NAT creates problems is the same as saying that people should not drive
cars because they pollute. Yes they do, and I'm driving one anyway.

Michel.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 2 Dec 2003 11:43:35 -0500

> and don't solve real world issues.

I don't think that's quite fair.  The problems we're seeing from
NATs - and they're considerable - really are the ones to be expected
as a consequence of the violation of first principles.  We know that
NAT is contributing quite heavily to delaying the more widespread
deployment of VoIP, internet conferencing, and some instant messaging.
There's absolutely no question about that.

> The market as always will pick the solution that is the best 

Several Nobel prizes in economics have recently been given to people
whose careers have been devoted to demonstrating that that's not the
case (particularly around how the lack of availability of information
to all parties interferes with market efficiency).

I really don't see how arguing about the goodness or badness of NAT
is useful.  NAT causes problem - observed problems.  The question that's
in front of us at the moment is the organizational response.  I think
we've done a reasonable job of documenting the issues.  Spencer points
out that none of these documents are BCPs, but to be honest I think that
the typical consumer of IETF documents isn't aware of or doesn't care
about the document status other than yes-it's-an-RFC/no-it's-not-an-RFC.

My concern is more with how we respond to the growing divide between
us and the people who deploy things we recognize are bad, when those
things dominate the market.  We need to keep churning out documents, and
I hope we can at least try to think about coming up with alternative
technologies that are more idiomatic.  For example, midcom and RSIP and
STUN have their flaws, heaven knows, but at least they push addressing
information back out to the endpoints.  That, I think, is far better 
than
much of what's been going on in industry around stateful inspection and
its various adaptations, proxying, and so on.

Really, the question here isn't whether or not NATs are good or bad (and
I hope we can avoid having that discussion yet again), but rather 
whether
or not we're going to be able to come up with a useful response to
unfortunate things happening in the field.

Melinda