Architectural Implications of NAT
RFC 2993

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 09

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