rfc2993.txt

RFC 的详细文档！

Network Working Group                                           T. Hain
Request for Comments: 2993                                    Microsoft
Category: Informational                                   November 2000


                   Architectural Implications of NAT

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   In light of the growing interest in, and deployment of network
   address translation (NAT) RFC-1631, this paper will discuss some of
   the architectural implications and guidelines for implementations. It
   is assumed the reader is familiar with the address translation
   concepts presented in RFC-1631.

Table of Contents

   1.  Introduction................................................... 2
   2.  Terminology.................................................... 4
   3.  Scope.......................................................... 6
   4.  End-to-End Model............................................... 7
   5.  Advantages of NATs............................................. 8
   6.  Problems with NATs............................................ 10
   7.  Illustrations................................................. 13
    7.1 Single point of failure...................................... 13
    7.2.  ALG complexity............................................. 14
    7.3. TCP state violations........................................ 15
    7.4.  Symmetric state management................................. 16
    7.5.  Need for a globally unique FQDN when advertising public
          services................................................... 18
    7.6.  L2TP tunnels increase frequency of address collisions...... 19
    7.7.  Centralized data collection system report correlation...... 20
   8.  IPv6.......................................................... 21
   9.  Security Considerations....................................... 22
   10.  Deployment Guidelines........................................ 23
   11.  Summary...................................................... 24
   12.  References................................................... 27




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


   13.  Acknowledgments.............................................. 28
   14.  Author's Address............................................. 28
   15.  Full Copyright Statement..................................... 29

1.  Introduction

   Published in May 1994, written by K. Egevang and P. Francis, RFC-1631
   [2] defined NAT as one means to ease the growth rate of IPv4 address
   use.  But the authors were worried about the impact of this
   technology.  Several places in the document they pointed out the need
   to experiment and see what applications may be adversely affected by
   NAT's header manipulations, even before there was any significant
   operational experience.  This is further evidenced in a quote from
   the conclusions: 'NAT has several negative characteristics that make
   it inappropriate as a long term solution, and may make it
   inappropriate even as a short term solution.'

   Now, six years later and in spite of the prediction, the use of NATs
   is becoming widespread in the Internet.  Some people are proclaiming
   NAT as both the short and long term solution to some of the
   Internet's address availability issues and questioning the need to
   continue the development of IPv6.  The claim is sometimes made that
   NAT 'just works' with no serious effects except on a few legacy
   applications.  At the same time others see a myriad of difficulties
   caused by the increasing use of NAT.

   The arguments pro & con frequently take on religious tones, with each
   side passionate about its position.

   -  Proponents bring enthusiasm and frequently cite the most popular
      applications of Mail & Web services as shining examples of NAT
      transparency.  They will also point out that NAT is the feature
      that finally breaks the semantic overload of the IP address as
      both a locator and the global endpoint identifier (EID).
   -  An opposing view of NAT is that of a malicious technology, a weed
      which is destined to choke out continued Internet development.
      While recognizing there are perceived address shortages, the
      opponents of NAT view it as operationally inadequate at best,
      bordering on a sham as an Internet access solution. Reality lies
      somewhere in between these extreme viewpoints.

   In any case it is clear NAT affects the transparency of end-to-end
   connectivity for transports relying on consistency of the IP header,
   and for protocols which carry that address information in places
   other than the IP header.  Using a patchwork of consistently
   configured application specific gateways (ALG's), endpoints can work
   around some of the operational challenges of NAT.  These operational
   challenges vary based on a number of factors including network and



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


   application topologies and the specific applications in use.  It can
   be relatively easy to deal with the simplest case, with traffic
   between two endpoints running over an intervening network with no
   parallel redundant NAT devices.  But things can quickly get quite
   complicated when there are parallel redundant NAT devices, or where
   there are more distributed and multi-point applications like multi-
   party document sharing.  The complexity of coordinating the updates
   necessary to work around NAT grows geometrically with the number of
   endpoints.  In a large environment, this may require concerted effort
   to simultaneously update all endpoints of a given application or
   service.

   The architectural intent of NAT is to divide the Internet into
   independent address administrations, (also see "address realms",
   RFC-2663 [3]) specifically facilitating casual use of private address
   assignments RFC-1918 [4].  As noted by Carpenter, et al RFC-2101 [5],
   once private use addresses were deployed in the network, addresses
   were guaranteed to be ambiguous.  For example, when simple NATs are
   inserted into the network, the process of resolving names to or from
   addresses becomes dependent on where the question was asked.  The
   result of this division is to enforce a client/server architecture
   (vs. peer/peer) where the servers need to exist in the public address
   realm.

   A significant factor in the success of the Internet is the
   flexibility derived from a few basic tenets.  Foremost is the End-
   to-End principle (discussed further below), which notes that certain
   functions can only be performed in the endpoints, thus they are in
   control of the communication, and the network should be a simple
   datagram service that moves bits between these points.  Restated, the
   endpoint applications are often the only place capable of correctly
   managing the data stream.  Removing this concern from the lower layer
   packet-forwarding devices streamlines the forwarding process,
   contributing to system-wide efficiency.

   Another advantage is that the network does not maintain per
   connection state information.  This allows fast rerouting around
   failures through alternate paths and to better scaling of the overall
   network.  Lack of state also removes any requirement for the network
   nodes to notify each other as endpoint connections are formed or
   dropped.  Furthermore, the endpoints are not, and need not be, aware
   of any network components other than the destination, first hop
   router(s), and an optional name resolution service.  Packet integrity
   is preserved through the network, and transport checksums and any
   address-dependent security functions are valid end-to-end.






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


   NAT devices (particularly the NAPT variety) undermine most of these,
   basic advantages of the end-to-end model, reducing overall
   flexibility, while often increasing operational complexity and
   impeding diagnostic capabilities.  NAT variants such as RSIP [6] have
   recently been proposed to address some of the end-to-end concerns.
   While these proposals may be effective at providing the private node
   with a public address (if ports are available), they do not eliminate
   several issues like network state management, upper layer constraints
   like TCP_TIME_WAIT state, or well-known-port sharing. Their port
   multiplexing variants also have the same DNS limitations as NAPT, and
   each host requires significant stack modifications to enable the
   technology (see below).

   It must be noted that firewalls also break the end-to-end model and
   raise several of the same issues that NAT devises do, while adding a
   few of their own.  But one operational advantage with firewalls is
   that they are generally installed into networks with the explicit
   intent to interfere with traffic flow, so the issues are more likely
   to be understood or at least looked at if mysterious problems arise.
   The same issues with NAT devices can sometimes be overlooked since
   NAT devices are frequently presented as transparent to applications.

   One thing that should be clearly stated up front is, that attempts to
   use a variant of NAT as a simple router replacement may create
   several significant issues that should be addressed before
   deployment.  The goal of this document is to discuss these with the
   intent to raise awareness.

2.  Terminology

   Recognizing that many of these terms are defined in detail in RFC
   2663 [3], the following are summaries as used in this document.

   NAT - Network Address Translation in simple form is a method by which
   IP addresses are mapped from one address administration to another.
   The NAT function is unaware of the applications traversing it, as it
   only looks at the IP headers.

   ALG - Application Layer Gateway: inserted between application peers
   to simulate a direct connection when some intervening protocol or
   device prevents direct access.  It terminates the transport protocol,
   and may modify the data stream before forwarding.

   NAT/ALG - combines ALG functions with simple NAT.  Generally more
   useful than pure NAT, because it embeds components for specific
   applications that would not work through a pure NAT.





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


   DNS/ALG -  a special case of the NAT/ALG, where an ALG for the DNS
   service interacts with the NAT component to modify the contents of a
   DNS response.

   Firewall - access control point that may be a special case of an ALG,
   or packet filter.

   Proxy - A relay service designed into a protocol, rather than
   arbitrarily inserted.  Unlike an ALG, the application on at least one
   end must be aware of the proxy.

   Static NAT - provides stable one-to-one mapping between address
   spaces.

   Dynamic NAT - provides dynamic mapping between address spaces
   normally used with a relatively large number of addresses on one side
   (private space) to a few addresses on the other (public space).

   NAPT - Network Address Port Translation accomplishes translation by
   multiplexing transport level identifiers of multiple addresses from
   one side, simultaneously into the transport identifiers of a single
   address on the other.  See 4.1.2 of RFC-2663.  This permits multiple
   endpoints to share and appear as a single IP address.

   RSIP - Realm Specific IP allows endpoints to acquire and use the
   public address and port number at the source.  It includes mechanisms
   for the private node to request multiple resources at once.  RSIP
   clients must be aware of the address administration boundaries, which
   specific administrative area its peer resides in for each
   application, and the topology for reaching the peer.  To complete a
   connection, the private node client requests one or more addresses
   and/or ports from the appropriate RSIP server, then initiates a
   connection via that RSIP server using the acquired public resources.
   Hosts must be updated with specific RSIP software to support the
   tunneling functions.