The IP Network Address Translator (NAT)
RFC 1631
Document | Type |
RFC - Informational
(May 1994; No errata)
Obsoleted by RFC 3022
Was draft-egevang-addrtrans (individual)
|
|
---|---|---|---|
Authors | Kjeld Egevang , Paul Francis | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1631 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 1994 for a long time, we were the only ones who had had the idea). 1. Introduction 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) [2]. 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 The design presented in this memo is called NAT, for Network Address Translator. NAT is a router function that can be configured as shown in figure 1. Only the stub border router requires modifications. NAT's basic operation is as follows. The addresses inside a stub domain can be reused by any other stub domain. For instance, a single Class A address could be used by many stub domains. At each exit point between a stub domain and backbone, NAT is installed. If there is more than one exit point it is of great importance that each NAT has the same translation table.Show full document text