ietf
[Top] [All Lists]

RE: arguments against NAT?

2003-12-02 22:10:20
Melinda,

Melinda Shore wrote:
The problems we're seeing from NATs - and they're considerable

It depends of the situation; don't generalize, the reality of numbers is
against you. The number of sites where NAT works just fine is orders of
magnitude greater than the number of sites where it causes more than
minor inconveniences. We're the IETF; we don't design the Internet for
the select few that have issues with NAT, we design it for everyone.

As examples: at home, I don't have a problem with NAT (and I do have an
overkill setup). In most organizations, the argument that NAT breaks
H.323 is moot, because H.323 traffic is internal voice only that is not
being NATted. There are many cases where yes NAT does break things, but
the point I am trying to make is that in the _millions_ of cases where
NAT is deployed and works, it has been deployed because its
inconveniences are far less than its advantages. The reason NAT is
deployed is the failure of this community to provide a better solution.

- really are the ones to be expected as a consequence of the
violation of first principles.

With end-to-end being on top of that list, I agree.

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.

I'm not arguing about that, it is delaying things indeed. However I
wonder which kind of instant messaging you are referring to, as all the
ones I've seen work fine through NAT.

I will also make the point that in the case of VoIP deployment, if NAT
is one of the things that is slowing it down, it's not the only one.
Frankly, at 2.5c / min for long distance calls, no VoIP
hardware/configuration and no QOS worries, in many cases POTS or
voice-grade circuits still are winners. Organizations do not deploy VoIP
because it's cool, organizations deploy VoIP because they want to see an
ROI on it; as of today in many cases this ROI is not there, NAT or not.


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

I have the greatest respect to Economics Nobel prize winners but I have
never met one that has half of a clue on what it takes to operate an
enterprise network on a daily basis. There is a difference between "the
market" and "what the market would/could be if this or that". How many
of these Nobel prizes understand the relationship between NAT and
renumbering (opposed to the obvious and moot "save IP addresses" and
"security" ones)?


I really don't see how arguing about the goodness or
badness of NAT is useful.

Me neither. NAT is bad, period.


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.

Agree, not to mention the fact that the typical network administrator
does not read RFCs. We can document all we want; the influence on market
behavior is very limited.


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.

By providing these people (the market) with a better alternative (which
is not easy) and my stopping to think _only_ about the sacro-saint
principles. 

Earlier, you were concerned about the proliferation of tunnels. Why do
people use tunnels? Partly to run over them protocols that do not cross
NAT. 

However, instead of admitting that people will run non-nattable
protocols over NAT no matter what, we keep designing non-nattable
protocols. At the end of the food chain, the network administrator, not
being able to find an IETF solution to his/her problems (that BTW needs
to be solved in days or weeks, not years) hands the task of making
things work to Karl Kludge and Jerry Rig, with the results we know.

I apologize for using a simplistic example, and I do acknowledge that
what I am about to suggest is not as simple as I might make it sound.
However, think about the following: if
{your_favorite_VoIP_protocol_here} crossed NAT nicely, not only it would
have been _much more_ deployed by now, but also it would not generate
this mesh of tunnels from hell that you are concerned about.


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),

We're not having it.

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.

A good beginning would be to listen to what people that actually _are_
in the field implementing real networks have to say about it.

Millions have implemented NAT. Contrary to popular thinking here, all
are not idiots. I'm tired of hearing that people that implement NAT,
people that use Cisco routers and people that run Microsoft Windows are
idiots. For the record, I'm a triple idiot and my wallet decides which
products are successful and which are not. So far myself and some other
90% of my peers that hold the purse strings and that happen to think
somehow like I do have spent lots of money on Microsoft, Cisco and NAT
and almost nothing on non-nattable VoIP stuff.


Michel.




<Prev in Thread] Current Thread [Next in Thread>