rfc1631.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页

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.




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


        \ | /                 .                                /
   +---------------+  WAN     .           +-----------------+/
   |Regional Router|----------------------|Stub Router w/NAT|---
   +---------------+          .           +-----------------+\
                              .                      |         \
                              .                      |  LAN
                              .               ---------------
                        Stub border

                      Figure 1: NAT Configuration

   For instance, in the example of figure 2, both stubs A and B
   internally use class A address 10.0.0.0. Stub A's NAT is assigned the
   class C address 198.76.29.0, and Stub B's NAT is assigned the class C
   address 198.76.28.0. The class C addresses are globally unique no
   other NAT boxes can use them.

                                       \ | /
                                     +---------------+
                                     |Regional Router|
                                     +---------------+
                                   WAN |           | WAN
                                       |           |
                   Stub A .............|....   ....|............ Stub B
                                       |           |
                     {s=198.76.29.7,^  |           |  v{s=198.76.29.7,
                      d=198.76.28.4}^  |           |  v d=198.76.28.4}
                       +-----------------+       +-----------------+
                       |Stub Router w/NAT|       |Stub Router w/NAT|
                       +-----------------+       +-----------------+
                             |                         |
                             |  LAN               LAN  |
                       -------------             -------------
                                 |                 |
               {s=10.33.96.5, ^  |                 |  v{s=198.76.29.7,
                d=198.76.28.4}^ +--+             +--+ v d=10.81.13.22}
                                |--|             |--|
                               /____\           /____\
                             10.33.96.5       10.81.13.22

                     Figure 2: Basic NAT Operation

   When stub A host 10.33.96.5 wishes to send a packet to stub B host
   10.81.13.22, it uses the globally unique address 198.76.28.4 as
   destination, and sends the packet to it's primary router. The stub
   router has a static route for net 198.76.0.0 so the packet is
   forwarded to the WAN-link. However, NAT translates the source address
   10.33.96.5 of the IP header with the globally unique 198.76.29.7



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


   before the package is forwarded. Likewise, IP packets on the return
   path go through similar address translations.

   Notice that this requires no changes to hosts or routers. For
   instance, as far as the stub A host is concerned, 198.76.28.4 is the
   address used by the host in stub B. The address translations are
   completely transparent.

   Of course, this is just a simple example. There are numerous issues
   to be explored. In the next section, we discuss various aspects of
   NAT.

3. Various Aspects of NAT

3.1 Address Spaces

Partitioning of Reusable and Non-reusable Addresses

   For NAT to operate properly, it is necessary to partition the IP
   address space into two parts - the reusable addresses used internal
   to stub domains, and the globally unique addresses. We call the
   reusable address local addresses, and the globally unique addresses
   global addresses. Any given address must either be a local address or
   a global address. There is no overlap.

   The problem with overlap is the following. Say a host in stub A
   wished to send packets to a host in stub B, but the local addresses
   of stub B overlapped the local addressees of stub A. In this case,
   the routers in stub A would not be able to distinguish the global
   address of stub B from its own local addresses.

Initial Assignment of Local and Global Addresses

   A single class A address should be allocated for local networks. (See
   RFC 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 1994


3.2 Routing Across NAT

   The router running NAT should never advertise the local networks to
   the backbone. Only the networks with global addresses may be known
   outside the stub. However, global information that NAT receives from
   the stub border router can be advertised in the stub the usual way.

Private Networks that Span Backbones

   In many cases, a private network (such as a corporate network) will
   be spread over different locations and will use a public backbone for
   communications between those locations. In this case, it is not
   desirable to do address translation, both because large numbers of
   hosts may want to communicate across the backbone, thus requiring
   large address tables, and because there will be more applications
   that depend on configured addresses, as opposed to going to a name
   server. We call such a private network a backbone-partitioned stub.

   Backbone-partitioned stubs should behave as though they were a non-
   partitioned stub. That is, the routers in all partitions should
   maintain routes to the local address spaces of all partitions. Of
   course, the (public) backbones do not maintain routes to any local
   addresses. Therefore, the border routers must tunnel through the
   backbones using encapsulation. To do this, each NAT box will set
   aside one global address for tunneling. When a NAT box x in stub
   partition X wishes to deliver a packet to stub partition Y, it will
   encapsulate the packet in an IP header with destination address set
   to the global address of NAT box y that has been reserved for
   encapsulation. When NAT box y receives a packet with that destination
   address, it decapsulates the IP header and routes the packet
   internally.

3.3 Header Manipulations

   In addition to modifying the IP address, NAT must modify the IP
   checksum and the TCP checksum. Remember, TCP's checksum also covers a
   pseudo header which contains the source and destination address. NAT
   must also look out for ICMP and FTP and modify the places where the
   IP address appears. There are undoubtedly other places, where
   modifications must be done. Hopefully, most such applications will be
   discovered during experimentation with NAT.

   The checksum modifications to IP and TCP are simple and efficient.
   Since both use a one's complement sum, it is sufficient to calculate
   the arithmetic difference between the before-translation and after-
   translation addresses and add this to the checksum. The only tricky
   part is determining whether the addition resulted in a wrap-around
   (in either the positive or negative direction) of the checksum. If



Egevang & Francis                                               [Page 5]