Architectural Implications of NAT
draft-iab-nat-implications-09

The information below is for an old version of the document that is already published as an RFC
Document Type RFC Internet-Draft (iab)
Author Tony Hain 
Last updated 2013-03-02 (latest revision 2000-08-10)
Stream Internet Architecture Board (IAB)
Formats pdf htmlized (tools) htmlized bibtex
Stream IAB state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IAB                                                             T. Hain 
Internet Draft                                                Microsoft 
Document: draft-iab-nat-implications-09.txt                 August 2000 
Category: Informational                                                 
 
                   Architectural Implications of NAT 
 
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC 2026 [1].  
    
   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."  
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
   "This memo provides information for the Internet community. This 
   memo does not specify an Internet standard of any kind. Distribution 
   of this memo is unlimited." 
    
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. 
    
    

  
Hain             Informational - Expires January 2001                1 
 

                  Architectural Implications of NAT       August 2000 
 
    
Table of Contents 
 Abstract............................................................1 
 1.  Introduction....................................................3 
 2.  Terminology.....................................................5 
 3.  Scope...........................................................7 
 4.  End-to-End Model................................................7 
 5.  Advantages of NATs..............................................9 
 6.  Problems with NATs.............................................11 
 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..........................................................17 
  7.6.  L2TP tunnels increase frequency of address collisions.......18 
  7.7.  Centralized data collection system report correlation.......19 
 8.  IPv6...........................................................19 
 9.  Security Considerations........................................21 
 10.  Deployment Guidelines.........................................23 
 11.  Summary.......................................................24 
 12.  References....................................................25 
 13.  Acknowledgments...............................................27 
 14.  Author's Addresses............................................27 

  
Hain             Informational - Expires January 2001                2 
 

                  Architectural Implications of NAT       August 2000 
 
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. 
    
Show full document text