- From: Keith Moore <moore@cs.utk.edu>
- Date: Thu, 05 Dec 2002 19:10:57 -0500
- To: Dave Crocker <dcrocker@brandenburg.com>
- cc: Graham Klyne <GK@Ninebynine.org>, Tony Hansen <tony@att.com>, discuss@apps.ietf.org
> A host consumes a single address and provides access to a collection > of processes. Clients and servers. The world of processes that access the nework cannot conviently be divided up into 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. One problem with applying this idea to the vast majority of NATs is that we put ordinary self-contained hosts behind them and expect them to be able to function as if they were ordinary hosts with distinct addresses, ordinary network connections, supporting ordinary applications - and it just doesn't work well. Another problem with applying this idea is that it's fine for the view external to the NAT, not so good for the view inside the NAT. NATs try to use ordinary IP as the interface between the NATs and the internal hosts, and it's a pretty lousy interface for that purpose. The one case where this model mostly works is where a NAT is used to multiplex and load-balance traffic between a set of hosts that are dedicated to a small number of very specific purposes (usually a server farm) - and where the applications running on those hosts are specifically chosen, designed, and/or adapted to work in that kind of environment. Keith
Received on Thursday, 5 December 2002 19:16:10 UTC