On Tuesday, December 2, 2003, at 10:44 AM, Michel Py wrote:
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.
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
compromise.
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