rfc2993.txt

RFC 的详细文档！

   VPN - For purposes of this document, Virtual Private Networks
   technically treat an IP infrastructure as a multiplexing substrate,
   allowing the endpoints to build virtual transit pathways, over which
   they run another instance of IP.  Frequently the 2nd instance of IP
   uses a different set of IP addresses.

   AH - IP Authentication Header, RFC-2401 [7], which provides data
   integrity, data origin authentication, and an optional anti-replay
   service.






Hain                         Informational                      [Page 5]

RFC 2993           Architectural Implications of NAT       November 2000


   ESP - Encapsulating Security Payload protocol, RFC 2401, may provide
   data confidentiality (encryption), and limited traffic flow
   confidentiality.  It also may provide data integrity, data origin
   authentication, and an anti-replay service.

   Address administration - coordinator of an address pool assigned to a
   collection of routers and end systems.

   Addressing realm -  a collection of routers and end systems
   exchanging locally unique location knowledge.  (Further defined in
   RFC-2663 NAT Terminology.)  NAT is used a means to distribute address
   allocation authority and provide a mechanism to map addresses from
   one address administration into those of another administration.

3.  Scope

   In discussing the architectural impact of NATs on the Internet, the
   first task is defining the scope of the Internet.  The most basic
   definition is; a concatenation of networks built using IETF defined
   technologies.  This simple description does not distinguish between
   the public network known as the Internet, and the private networks
   built using the same technologies (including those connected via
   NAT).  Rekhter, et al in RFC-1918 defined hosts as public when they
   need network layer access outside the enterprise, using a globally
   unambiguous address.  Those that need limited or no access are
   defined as private.  Another way to view this is in terms of the
   transparency of the connection between any given node and the rest of
   the Internet.

   The ultimate resolution of public or private is found in the intent
   of the network in question.  Generally, networks that do not intend
   to be part of the greater Internet will use some screening technology
   to insert a barrier.  Historically barrier devices between the public
   and private networks were known as Firewalls or Application Gateways,
   and were managed to allow approved traffic while blocking everything
   else.  Increasingly, part of the screening technology is a NAT, which
   manages the network locator between the public and private-use
   address spaces, and then, using ALGs adds support for protocols that
   are incompatible with NAT.  (Use of NAT within a private network is
   possible, and is only addressed here in the context that some
   component of the private network is used as a common transit service
   between the NAT attached stubs.)

   RFC-1631 limited the scope of NAT discussions to stub appendages of a
   public Internet, that is, networks with a single connection to the
   rest of the Internet.  The use of NAT in situations in which a
   network has multiple connections to the rest of the Internet is
   significantly more complex than when there is only a single



Hain                         Informational                      [Page 6]

RFC 2993           Architectural Implications of NAT       November 2000


   connection since the NATs have to be coordinated to ensure that they
   have a consistent understanding of address mapping for each
   individual device.

4.  End-to-End Model

   The concept of the End-to-End model is reviewed by Carpenter in
   Internet Transparency [8].  One of the key points is "state should be
   maintained only in the endpoints, in such a way that the state can
   only be destroyed when the endpoint itself breaks"; this is termed
   "fate-sharing".  The goal behind fate-sharing is to ensure
   robustness.  As networks grow in size, likelihood of component
   failures affecting a connection becomes increasingly frequent. If
   failures lead to loss of communication, because key state is lost,
   then the network becomes increasingly brittle, and its utility
   degrades.  However, if an endpoint itself fails, then there is no
   hope of subsequent communication anyway.  Therefore the End-to-End
   model argues that as much as possible, only the endpoints should hold
   critical state.

   For NATs, this aspect of the End-to-End model translates into the NAT
   becoming a critical infrastructure element:  if it fails, all
   communication through it fails, and, unless great care is taken to
   assure consistent, stable storage of its state, even when it recovers
   the communication that was passing through it will still fail
   (because the NAT no longer translates it using the same mappings).
   Note that this latter type of failure is more severe than the failure
   of a router; when a router recovers, any communication that it had
   been forwarding previous can continue to be successfully forwarded
   through it.

   There are other important facets to the End-to-End model:

   -  when state is held in the interior of the network, then traffic
      dependent on that state cannot be routed around failures unless
      somehow the state is replicated to the fail-over points, which can
      be very difficult to do in a consistent yet efficient and timely
      fashion.
   -  a key principle for scaling networks to large size is to push
      state-holding out to the edges of the network.  If state is held
      by elements in the core of the network, then as the network grows
      the amount of state the elements must holds likewise grows.  The
      capacities of the elements can become severe chokepoints and the
      number of connections affected by a failure also grows.
   -  if security state must be held inside the network (see the
      discussion below), then the possible trust models the network can
      support become restricted.




Hain                         Informational                      [Page 7]

RFC 2993           Architectural Implications of NAT       November 2000


   A network for which endpoints need not trust network service
   providers has a great deal more security flexibility than one which
   does.  (Picture, for example, a business traveler connecting from
   their hotel room back to their home office: should they have to trust
   the hotel's networking staff with their security keys?, or the staff
   of the ISP that supplies the hotel with its networking service?  How
   about when the traveler connects over a wireless connection at an
   airport?)

   Related to this, RFC-2101 notes:
     Since IP Security authentication headers assume that the addresses
     in the network header are preserved end-to-end, it is not clear
     how one could support IP Security-based authentication between a
     pair of hosts communicating through either an ALG or a NAT.

   In addition, there are distributed applications that assume that IP
   addresses are globally scoped, globally routable, and all hosts and
   applications have the same view of those addresses.  Indeed, a
   standard technique for such applications to manage their additional
   control and data connections is for one host to send to another the
   address and port that the second host should connect to.  NATs break
   these applications.  Similarly, there are other applications that
   assume that all upper layer ports from a given IP address map to the
   same endpoint, and port multiplexing technologies like NAPT and RSIP
   break these.  For example, a web server may desire to associate a
   connection to port 80 with one to port 443, but due to the possible
   presence of a NATPT, the same IP address no longer ensures the same
   host.

   Limiting such applications is not a minor issue: much of the success
   of the Internet today is due to the ease with which new applications
   can run on endpoints without first requiring upgrades to
   infrastructure elements.  If new applications must have the NATs
   upgraded in order to achieve widespread deployment, then rapid
   deployment is hindered, and the pace of innovation slowed.

5.  Advantages of NATs

   A quick look at the popularity of NAT as a technology shows that it
   tackles several real world problems when used at the border of a stub
   domain.

   -  By masking the address changes that take place, from either dial-
      access or provider changes, minimizes impact on the local network
      by avoiding renumbering.
   -  Globally routable addresses can be reused for intermittent access
      customers.  This pushes the demand for addresses towards the
      number of active nodes rather than the total number of nodes.



Hain                         Informational                      [Page 8]

RFC 2993           Architectural Implications of NAT       November 2000


   -  There is a potential that ISP provided and managed NATs would
      lower support burden since there could be a consistent, simple
      device with a known configuration at the customer end of an access
      interface.
   -  Breaking the Internet into a collection of address authorities
      limits the need for continual justification of allocations allows
      network managers to avoid the use of more advanced routing
      techniques such as variable length subnets.
   -  Changes in the hosts may not be necessary for applications that
      don't rely on the integrity of the packet header, or carry IP
      addresses in the payload.
   -  Like packet filtering Firewalls, NAPT, & RSIP block inbound
      connections to all ports until they are administratively mapped.

   Taken together these explain some of the strong motivations for
   moving quickly with NAT deployment.  Traditional NAT [2] provides a
   relatively simple function that is easily understood.

   Removing hosts that are not currently active lowers address demands
   on the public Internet.  In cases where providers would otherwise end
   up with address allocations that could not be aggregated, this
   improves the load on the routing system as well as lengthens the
   lifetime of the IPv4 address space.  While reclaiming idle addresses
   is a natural byproduct of the existing dynamic allocation, dial-
   access devices, in the dedicated connection case this service could
   be provided through a NAT.  In the case of a NAPT, the aggregation
   potential is even greater as multiple end systems share a single
   public address.

   By reducing the potential customer connection options and minimizing
   the support matrix, it is possible that ISP provided NATs would lower
   support costs.

   Part of the motivation for NAT is to avoid the high cost of
   renumbering inherent in the current IPv4 Internet.  Guidelines for
   the assignment of IPv4 addresses RFC-2050 [9] mean that ISP customers
   are currently required to renumber their networks if they want to
   switch to a new ISP.  Using a NAT (or a firewall with NAT functions)
   means that only the Internet facing IP addresses must be changed and
   internal network nodes do not need to be reconfigured. Localizing
   address administration to the NAT minimizes renumbering costs, and
   simultaneously provides for a much larger local pool of addresses
   than is available under current allocation guidelines. (The registry
   guidelines are intended to prolong the lifetime of the IPv4 address
   space and manage routing table growth, until IPv6 is ready or new
   routing technology reduces the pressure on the routing table.  This
   is accomplished by managing allocations to match actual demand and to
   enforce hierarchical addressing.  An unfortunate byproduct of the



Hain                         Informational                      [Page 9]

RFC 2993           Architectural Implications of NAT       November 2000


   current guidelines is that they may end up hampering growth in areas
   where it is difficult to sort out real need from potential hoarding.)
   NAT is effective at masking provider switching or other requirements
   to change addresses, thus mitigates some of the growth issues.

   NAT deployments have been raising the awareness of protocol designers
   who are interested in ensuring that their protocols work end-to-end.
   Breaking the semantic overload of the IP address will force
   applications to find a more appropriate mechanism for endpoint
   identification and discourage carrying the locator in the data
   stream.  Since this will not work for legacy applications, RFC-1631
   discusses how to look into the packet and make NAT transparent to the
   application (i.e.: create an application gateway).  This may not be
   possible for all applications (such as IP based authentication in
   SNMP), and even with application gateways in the path it may be
   necessary to modify each end host to be aware when there are
   intermediaries modifying the data.

   Another popular practice is hiding a collection of hosts that provide
   a combined service behind a single IP address (i.e.: web host load
   sharing).  In many implementations this is architecturally a NAT,
   since the addresses are mapped to the real destination on the fly.