Re: NATmakes a networik a host -- must every process have an IP address?

At 02:51 PM 12/5/02 -0800, Dave Crocker wrote:
>Graham,
>
>
>Monday, December 2, 2002, 9:54:54 AM, you wrote:
>Graham> More generally, NATted systems only really "work" when they make only
>Graham> outgoing connections.  (Yes, you can define a "pass-through", but 
>that's a
>Graham> horrible hack, and only lets you have one receiving endpoint.)
>
>
>I'm not fond of the problems that NATs incur, but I think that we are
>tending to argue "purity" from a false premise.
>
>As others have noted, NATs do more than deal with an address space
>problem. They permit a degree of plug-and-play that has otherwise not
>been possible.  Note that a NAT can be a DHCP client as well as
>provider, thereby making the entire customer site plug and play.
>
>But to comment on the Subject line of this note:
>
>A host consumes a single address and provides access to a collection
>of processes.  Clients and servers.
>
>A NAT does the same thing.  In terms of "inconvenience" such as for
>providing servers, the problem with NATs is administering address/port
>assignments, rather than there being a core problem with the idea of a
>NAT.

That's an interesting viewpoint, but I think that application designers 
currently conceive applications in terms of being deployed on a host, 
rather than some sub-component of a host.  Clearly, the new viewpoint can 
be made to work (at a price in added overall "host" complexity), but as 
experience shows not every application designer is thinking in terms 
necessary for new applications to work in this environment.  In time, given 
that NAT is a reality, maybe application designers will be weaned off their 
dependency on IP address stability for creating rendezvous points -- but I 
think the alternatives will all be more complex, and for what other advantage?

Also I think the "plug-and-play" advantage you cite, like security, is 
something that can be provided separately from the existence of NAT.

>Graham> Where this all leads, I think, is that the worst thing about NAT 
>is that it
>Graham> hinders the deployment of new applications.
>
>How is this different from having "protected" ports below 1000 on
>Unix?

I think that's entirely different -- I'm not sure why you suggest it's 
not.  The protected ports don't prevent the deployment of new applications 
because application designers *can* choose non-protected ports.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Monday, 9 December 2002 09:25:22 UTC