RFC 1631: The IP Network Address Translator (NAT)

Obsoleted by: 3022 INFORMATIONAL

Network Working Group                                         K. Egevang
Request for Comments: 1631                           Cray Communications
Category: Informational                                       P. Francis
                                                                     NTT
                                                                May 1994


                
The IP Network Address Translator (NAT)

Status of this Memo

   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

   The two most compelling problems facing the IP Internet are IP
   address depletion and scaling in routing. Long-term and short-term
   solutions to these problems are being developed. The short-term
   solution is CIDR (Classless InterDomain Routing). The long-term
   solutions consist of various proposals for new internet protocols
   with larger addresses.

   It is possible that CIDR will not be adequate to maintain the IP
   Internet until the long-term solutions are in place. This memo
   proposes another short-term solution, address reuse, that complements
   CIDR or even makes it unnecessary. The address reuse solution is to
   place Network Address Translators (NAT) at the borders of stub
   domains. Each NAT box has a table consisting of pairs of local IP
   addresses and globally unique addresses. The IP addresses inside the
   stub domain are not globally unique. They are reused in other
   domains, thus solving the address depletion problem. The globally
   unique IP addresses are assigned according to current CIDR address
   allocation schemes. CIDR solves the scaling problem. The main
   advantage of NAT is that it can be installed without changes to
   routers or hosts. This memo presents a preliminary design for NAT,
   and discusses its pros and cons.

Acknowledgments

   This memo is based on a paper by Paul Francis (formerly Tsuchiya) and
   Tony Eng, published in Computer Communication Review, January 1993.
   Paul had the concept of address reuse from Van Jacobson.

   Kjeld Borch Egevang edited the paper to produce this memo and
   introduced adjustment of sequence-numbers for FTP. Thanks to Jacob
   Michael Christensen for his comments on the idea and text (we thought



Egevang & Francis                                               [Page 1]

RFC 1631 Network Address Translator May 19941 . Introduction2]. The long-term
   solutions consist of various proposals for new internet protocols
   with larger addresses.

   Until the long-term solutions are ready an easy way to hold down the
   demand for IP addresses is through address reuse. This solution takes
   advantage of the fact that a very small percentage of hosts in a stub
   domain are communicating outside of the domain at any given time. (A
   stub domain is a domain, such as a corporate network, that only
   handles traffic originated or destined to hosts in the domain).
   Indeed, many (if not most) hosts never communicate outside of their
   stub domain. Because of this, only a subset of the IP addresses
   inside a stub domain, need be translated into IP addresses that are
   globally unique when outside communications is required.

   This solution has the disadvantage of taking away the end-to-end
   significance of an IP address, and making up for it with increased
   state in the network. There are various work-arounds that minimize
   the potential pitfalls of this. Indeed, connection-oriented protocols
   are essentially doing address reuse at every hop.

   The huge advantage of this approach is that it can be installed
   incrementally, without changes to either hosts or routers. (A few
   unusual applications may require changes). As such, this solution can
   be implemented and experimented with quickly. If nothing else, this
   solution can serve to provide temporarily relief while other, more
   complex and far-reaching solutions are worked out.

2 . Overview of NAT
Egevang & Francis                                               [Page 2]

RFC 1631 Network Address Translator May 1994
Egevang & Francis                                               [Page 3]

RFC 1631 Network Address Translator May 19943 . Various Aspects of NAT3.1 Address SpacesRFC 1597 [3].)  This address could then be used for internets with no
   connection to the Internet. NAT then provides an easy way to change
   an experimental network to a "real" network by translating the
   experimental addresses to globally unique Internet addresses.

   Existing stubs which have unique addresses assigned internally, but
   are running out of them, can change addresses subnet by subnet to
   local addresses. The freed adresses can then be used by NAT for
   external communications.








Egevang & Francis                                               [Page 4]

RFC 1631 Network Address Translator May 19943.2 Routing Across NAT3.3 Header Manipulations
Egevang & Francis                                               [Page 5]

RFC 1631 Network Address Translator May 1994
Egevang & Francis                                               [Page 6]

RFC 1631 Network Address Translator May 1994
Egevang & Francis                                               [Page 7]

RFC 1631 Network Address Translator May 1994
Egevang & Francis                                               [Page 8]

RFC 1631 Network Address Translator May 19944 . Conclusions1 . It requires a sparse end-to-end traffic matrix. Otherwise, the NAT
   tables will be large, thus giving lower performance. While the
   expectation is that end-to-end traffic matrices are indeed sparse,
   experience with NAT will determine whether or not they are. In any
   event, future applications may require a rich traffic matrix (for
   instance, distributed resource discovery), thus making long-term use
   of NAT unattractive.

2 . It increases the probability of mis-addressing.3 . It breaks certain applications (or at least makes them more difficult
   to run).

4 . It hides the identity of hosts. While this has the benefit of
   privacy, it is generally a negative effect.

5 . Problems with SNMP, DNS, ... you name it.1]. This implementation manipulates
   addresses and IP checksums.

   Kjeld implemented NAT in a Cray Communications IP-router. The
   implementation was tested with Telnet and FTP. This implementation
   manipulates addresses, IP checksums, TCP sequence/acknowledge numbers
   and FTP PORT commands.

   The prototypes has demonstrated that IP addresses can be translated
   transparently to hosts within the limitations described in this
   paper.







Egevang & Francis                                               [Page 9]

RFC 1631 Network Address Translator May 19941] Karn, P., "KA9Q", anonymous FTP from ucsd.edu
       (hamradio/packet/ka9q/docs).

   [2] Fuller, V., Li, T., and J. Yu, "Classless Inter-Domain Routing
       (CIDR) an Address Assignment and Aggregation Strategy", RFC 1519,
       BARRNet, cisco, Merit, OARnet, September 1993.

   [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot,
       "Address Allocation for Private Internets", RFC 1597, T.J. Watson
       Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Kjeld Borch Egevang
   Cray Communications
   Smedeholm 12-14
   DK-2730 Herlev
   Denmark

   Phone: +45 44 53 01 00
   EMail: [email protected]


   Paul Francis
   NTT Software Lab
   3-9-11 Midori-cho Musashino-shi
   Tokyo 180 Japan

   Phone: +81-422-59-3843
   Fax +81-422-59-3765
   EMail: [email protected]














Egevang & Francis                                              [Page 10]