At 11:28 -0500 11/30/99, Tony Dal Santo wrote:
>Valdis Kletnieks wrote:
>
>> However, I do agree that anybody designing a protocol in the last 3-4
>> years *should* have designed it to be firewall and NAT friendly.
>> (Yes, I know that can be difficult in practice. I guess that's today's
>> "Welcome to Reality").
>
>Daniel Senie wrote:
>
>> > In any event, I've always personally been of the opinion that
>> > if applications don't work in the face of NAT, then the
>> > applications themselves are functionally deficient and should be
>> > fixed. :-)
>>
>> ...and [NAT] must be taken into consideration when designing protocols.
>>
>> .... New protocols should, in my opinion, provide descriptions
>> of how they work or don't work with NAT. If there is a reason why they
>> aren't going to work (carriage of port or address information), a
>> description of how to build an Application Layer Gateway (ALG) should be
>> provided.
>
>I really think trying to make everything "NAT aware" or "NAT friendly"
>is spending effort heading in the wrong direction. While I am forced to
>concede the wide deployment of NAT technology, I believe the problems it
>solves (or at least claims to) are better solved by other means, or
>require different solutions.
The problem is not to make applications "NAT aware" or "NAT friendly". The
problem is to make applications "IP address unaware". What is an
application doing exchanging and using names for things 2 layers below it?
Sounds like a design for trouble if I ever heard of one.
>
>Protocols are difficult enough to get right. I'd rather see time spent
>developing good algorithms than NAT compatibility. What about future
>NAT "features"? Are protocol designers supposed to guess at what new
>convolutions will be dreamt up?
You are absolutely right. Time should be spent developing "good
algorithms" which is common "good architecture". What NAT does is just
another form of the same thing that X.25, ATM, and MPLS do with different
identifiers. It is not bad algorithm there nor bad architecture. (I
presume since there are so many ATM and MPLS supporters (X.25 seems to be
gone for the most part, thank god.)) How does an application exchanging
and using IP addresses qualify as good algorithms or good architecture.
>
>About the only serious issues NAT really addresses are the perceived IP
>address shortage, and being forced to renumber when changing ISPs. As
>for the shortage, this thread seems to indicate there isn't a real firm
>idea of how many addresses are actually being used. Have all the minimally
>used class A and B addresses been reclaimed? I suspect not, which tells
>me the immediate shortage can't be that great. And if switching to IPv6
>in the long term has problems, effort should be spent solving those.
>
>As for being forced to renumber (can't take your address with you),
No, you can't. If you did it would no longer be an address, but only a
name. And then of no use to routing.
>is this really a technical routing problem (tables too large), or more
It is really a technical problem.
>of an economic/political/turf issue? While renumbering can be painful,
Only trying to keep the address is an economic/political/turf issue.
>DNS should hide the change, and things like DHCP can make it less so.
>Besides it shouldn't be too difficult for small organizations, and large
>ones should be able to take their address as they move.
Now you are on to the beginning of a good solution.
>
>While NAT is an adequate stopgap solution to IP address dilemmas, in my
>opinion, it shouldn't be the final solution.
>
>> We are at a crossroads where architectural purity has intersected
>> operational reality.
>
>Let's not continue down the wrong road.
Correct. Lets get an application name space so we don't need to worry
about it.
Take care,
John
