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.