[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 08 09 rfc2993                            
IAB                                                  T. Hain, Microsoft
Internet Draft
Document: draft-iab-nat-implications-00.txt                  March 1998

                   Architectural Implications of NAT

Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   A revised version of this draft document will be submitted to the
   RFC editor as an Informational RFC for the Internet Community.
   Discussion and suggestions for improvement are requested. This
   document will expire before October 1998. Distribution of this draft
   is unlimited.


   In light of the growing interest in, and deployment of network
   address translation (NAT - RFC 1631), this paper will present some
   highlights of the architectural implications.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in [RFC-2119].

Hain                                                                 1

Internet Draft       Architectural Implications of NAT      March 1998


   One view of NAT is that it is the feature which finally breaks the
   semantic overload of the IP address as both a locator and the end-
   point identifier (EID). Another view of NAT is that of ‘necessary
   evil’, where there is a real concern that the technology is the weed
   which is destined to choke out continued development.

   Since there are valid arguments on multiple points, some of them are
   listed here in a point-counter point style followed by a highlight
   of the issues.

NAT value add                       NAT affliction
--------------------------------    --------------------------------
Masks Global Address Changes        Mandates Multiple Name Spaces
Lowers Address Utilization          Allows end-to-end address conflicts
Lowers ISP support burden           Increases local support burden
Breaks end-to-end association       Breaks end-to-end association
Transparent to end systems          Unique development for each app
Load sharing as virtual host        Performance impact with scale
Delays need for IPv4 replacement    Complicates integration of IPv6

NAT value add

   - Masking the address changes that take place from either dial-based
     access, or provider changes improves stability in the local
   - Globally routable addresses can be reused for dial customers,
     which appears to lower the demand and utilization of addresses.
   - There is a potential that NAT's would lower an ISP’s support
     burden since there could be a consistent, simple device with a
     known configuration.
   Taken together these are strong motivations for moving quickly with
   NAT deployment.

   Breaking the semantic overload of the IP address will force
   applications to find a more appropriate mechanism for end point
   identification. This will not work for legacy applications, so RFC
   1631 discusses how to look into the packet and make NAT transparent
   to the application. The greatest gain will be making developers of
   new apps think about what they are doing.

   Load sharing may be implemented through a function which redirects
   via packet manipulation, and is architecturally a NAT. This scheme
   gives the appearance that a service located through a single IP
   address has the responsiveness that is only possible with a group of
   machines, but the end client is not aware of actual implementation.

Hain                     Expires October 1998                        2

Internet Draft       Architectural Implications of NAT      March 1998

   Some consider it a feature to limit evolution potential through NAT,
   where integration plans that assume the current address space is
   globally unique will fail, leaving IPv4 to continue unchallenged.
   (This viewpoint is not shared by the IAB.)

NAT affliction

   A significant failure of NAT is the name space inconsistency. Very
   small-scale implementations usually do not see this because DNS is
   not used on the local side. When DNS is required to resolve a given
   host name on both sides of a NAT there is no good answer. Returning
   the local address will assure global invisibility, while returning
   the global address will prevent local visibility. If DNS were to
   return both, the results would be unpredictable.

   While NAT stabilizes the address used by local systems, it allows
   address collisions for applications that associate the end point IP
   addresses with the connection. The only way around this is to look
   into the application data stream and replace the address, then
   recalculate the checksum. Functionally this becomes an Application
   Level Gateway, even when it is still called a NAT.

   The recent mass growth of the Internet has been driven by support of
   low cost publication via the web. The next big push appears to be
   support of virtual private networks (VPN’s). Technically VPN’s treat
   the IP infrastructure as a multiplexing substrate allowing the end
   points to build circuits to run IP over. VPN’s redefine network
   visibility and increase the likelihood of address collision when
   traversing NAT’s. Address management in the 'hidden space' behind
   NAT's will become a significant burden, as there is no central body
   capable of, or willing to do it. The lower burden for the ISP is
   actually a transfer of burden to the local level, because
   administration of addresses and names is both distributed and more

   The greatest concern from the explosion of NAT's is the impact on
   the fledgling efforts at deploying IP security. For lack of another
   globally unique EID, the traditional use of the IP address was
   assumed. This combination of required global uniqueness, and assured
   reuse by NAT leaves the IPsec effort with a severely restricted
   working set.

   In a statement about the use of IPv4 today, RFC 2101 details
   architectural issues and notes:
      "...it has been considered more useful to deliver the packet,
      then worry about how to identify the end points, than to
      provide identity in a packet that cannot be delivered."

   This argument presumes that delivering the packet has an inherent
   value, even if the end points can’t be identified. In a self-
   fulfillment of that prophecy, the applications developed to date are

Hain                     Expires October 1998                        3

Internet Draft       Architectural Implications of NAT      March 1998

   structured to assume packets will be delivered and identity is only
   assured in controlled environments. In many ways, this fundamental
   impediment to basic trust has been the stalling factor in deploying
   security across the Internet. In another note from RFC 2101:
      "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 (ed: Application Level Gateway) or a NAT."

   Load sharing through a NAT function has all the scaling properties
   of the funnel that it is. There is a small but significant overhead
   involved as checksums are recalculated for every packet,
   (particularly for apps that include the end point IP address in the
   data stream). This point is generally glossed over with the line
   'throw more hardware at it', but the laws of physics eventually

   The existence of NAT's will complicate the integration of IPv6
   because the name space and end point addresses are not consistent
   and globally unique. While multiple addresses are less of a concern
   to an IPv6 node, the disjoint name space will certainly make
   management interesting.

Security Considerations

   NAT's break a fundamental assumption of IPsec, and therefore
   represent a tremendous risk to deployment of enhanced security
   across the Internet. It is difficult to identify all the
   combinations of header orderings that are possible using NAT's,
   VPN's, and IPsec. It is even more difficult to clearly state which
   of those are applicable, or workable in any given context. IPsec can
   be made to work over NAT's, some of the time, when it is using
   certs, but even then there may be IP addresses in the SAs. Even the
   Null ESP has problems with NATs because IKE currently uses IP
   addresses that are in encrypted packets. In some implementations
   there may be work-arounds through the appropriate ordering of NAT's
   and VPN's, but in the end the lack of address administration behind
   the NAT's will result in collision and failure.

   With sufficient thought and advance planning, some of the issues
   between IPsec and NAT's can be worked around. Attempts to retrofit
   IPsec over and existing NAT infrastructure can be problematic, so in
   the generic sense; NAT's are the greatest single threat to security
   integration being deployed in the Internet today.

Hain                     Expires October 1998                        4

Internet Draft       Architectural Implications of NAT      March 1998


   NAT’s are a 'fact of life', and will proliferate as an enhancement
   which sustains the existing IPv4 infrastructure. At the same time,
   they require strong applicability statements, clearly stating what
   works and what does not.

   NAT's are a 'necessary evil' as well, and by fragmenting the Name
   Space, NAT's create an administrative burden that is not easily
   resolved. It is equivalent to digging a hole where the longer we
   continue digging, the harder it will be to get out. More
   significantly, they inhibit the roll out of IPsec, which will in
   turn slow growth of applications that require a secure
   infrastructure. As such, NAT’s represent the single greatest threat
   to a secure Internet.

   There have been many discussions lately about the value of
   continuing with IPv6 development when the market place is widely
   deploying IPv4 NAT’s. A short sighted view would miss the point that
   both have a role, because NAT’s address some real-world issues
   today, while IPv6 is targeted at solving fundamental problems, as
   well as moving forward. It should be recognized that there will be a
   long co-existence as applications and services develop for IPv6. The
   lifetime of existing IPv4 systems will likely be measured in
   decades. At best, NAT's are a diversion from forward motion, but
   they do enable wider participation at the present state. At their
   worst, they break an association that arguably should never have
   been made to begin with.

   Everyone needs to focus on the goal, which is continued evolution of
   the Internet, and recognize continued development of IP (in all
   current and future versions) is the path. It has been noted that the
   success of the Internet is based on the ‘living’ characteristic of
   IP. As in life, when growth, evolution, and forward progress stops,
   decay overtakes and destroys. History has shown that protocols
   presented as ‘complete and finished’ have had very short lifetimes,
   while those still ‘a work in progress’ manage to survive and
   continue moving ahead. All parties need to understand the
   significant role they are playing in pursuing the goal, and that
   none can get there without all the others.


   [RFC 1631], Egevang, K., Francis, P., "The IP Network Address
   Translator", RFC 1631, May 1994

   [RFC 2101], Carpenter et. al., "IPv4 Address Behavior Today", RFC
   2101, February 1997

   [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997

Hain                     Expires October 1998                        5

Internet Draft       Architectural Implications of NAT      March 1998


   The IAB contributed to this draft.

Author's Addresses

   Tony Hain
   One Microsoft Way            Phone:  1-425-703-6619
   Redmond, Wa. USA             Email:  tonyhain@microsoft.com

Hain                     Expires October 1998                        6