home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1631 < prev    next >
Text File  |  1995-09-15  |  23KB  |  564 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         K. Egevang
  8. Request for Comments: 1631                           Cray Communications
  9. Category: Informational                                       P. Francis
  10.                                                                      NTT
  11.                                                                 May 1994
  12.  
  13.  
  14.                 The IP Network Address Translator (NAT)
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    The two most compelling problems facing the IP Internet are IP
  25.    address depletion and scaling in routing. Long-term and short-term
  26.    solutions to these problems are being developed. The short-term
  27.    solution is CIDR (Classless InterDomain Routing). The long-term
  28.    solutions consist of various proposals for new internet protocols
  29.    with larger addresses.
  30.  
  31.    It is possible that CIDR will not be adequate to maintain the IP
  32.    Internet until the long-term solutions are in place. This memo
  33.    proposes another short-term solution, address reuse, that complements
  34.    CIDR or even makes it unnecessary. The address reuse solution is to
  35.    place Network Address Translators (NAT) at the borders of stub
  36.    domains. Each NAT box has a table consisting of pairs of local IP
  37.    addresses and globally unique addresses. The IP addresses inside the
  38.    stub domain are not globally unique. They are reused in other
  39.    domains, thus solving the address depletion problem. The globally
  40.    unique IP addresses are assigned according to current CIDR address
  41.    allocation schemes. CIDR solves the scaling problem. The main
  42.    advantage of NAT is that it can be installed without changes to
  43.    routers or hosts. This memo presents a preliminary design for NAT,
  44.    and discusses its pros and cons.
  45.  
  46. Acknowledgments
  47.  
  48.    This memo is based on a paper by Paul Francis (formerly Tsuchiya) and
  49.    Tony Eng, published in Computer Communication Review, January 1993.
  50.    Paul had the concept of address reuse from Van Jacobson.
  51.  
  52.    Kjeld Borch Egevang edited the paper to produce this memo and
  53.    introduced adjustment of sequence-numbers for FTP. Thanks to Jacob
  54.    Michael Christensen for his comments on the idea and text (we thought
  55.  
  56.  
  57.  
  58. Egevang & Francis                                               [Page 1]
  59.  
  60. RFC 1631               Network Address Translator               May 1994
  61.  
  62.  
  63.    for a long time, we were the only ones who had had the idea).
  64.  
  65. 1. Introduction
  66.  
  67.    The two most compelling problems facing the IP Internet are IP
  68.    address depletion and scaling in routing. Long-term and short-term
  69.    solutions to these problems are being developed. The short-term
  70.    solution is CIDR (Classless InterDomain Routing) [2]. The long-term
  71.    solutions consist of various proposals for new internet protocols
  72.    with larger addresses.
  73.  
  74.    Until the long-term solutions are ready an easy way to hold down the
  75.    demand for IP addresses is through address reuse. This solution takes
  76.    advantage of the fact that a very small percentage of hosts in a stub
  77.    domain are communicating outside of the domain at any given time. (A
  78.    stub domain is a domain, such as a corporate network, that only
  79.    handles traffic originated or destined to hosts in the domain).
  80.    Indeed, many (if not most) hosts never communicate outside of their
  81.    stub domain. Because of this, only a subset of the IP addresses
  82.    inside a stub domain, need be translated into IP addresses that are
  83.    globally unique when outside communications is required.
  84.  
  85.    This solution has the disadvantage of taking away the end-to-end
  86.    significance of an IP address, and making up for it with increased
  87.    state in the network. There are various work-arounds that minimize
  88.    the potential pitfalls of this. Indeed, connection-oriented protocols
  89.    are essentially doing address reuse at every hop.
  90.  
  91.    The huge advantage of this approach is that it can be installed
  92.    incrementally, without changes to either hosts or routers. (A few
  93.    unusual applications may require changes). As such, this solution can
  94.    be implemented and experimented with quickly. If nothing else, this
  95.    solution can serve to provide temporarily relief while other, more
  96.    complex and far-reaching solutions are worked out.
  97.  
  98. 2. Overview of NAT
  99.  
  100.    The design presented in this memo is called NAT, for Network Address
  101.    Translator. NAT is a router function that can be configured as shown
  102.    in figure 1. Only the stub border router requires modifications.
  103.  
  104.    NAT's basic operation is as follows. The addresses inside a stub
  105.    domain can be reused by any other stub domain. For instance, a single
  106.    Class A address could be used by many stub domains. At each exit
  107.    point between a stub domain and backbone, NAT is installed. If there
  108.    is more than one exit point it is of great importance that each NAT
  109.    has the same translation table.
  110.  
  111.  
  112.  
  113.  
  114. Egevang & Francis                                               [Page 2]
  115.  
  116. RFC 1631               Network Address Translator               May 1994
  117.  
  118.  
  119.         \ | /                 .                                /
  120.    +---------------+  WAN     .           +-----------------+/
  121.    |Regional Router|----------------------|Stub Router w/NAT|---
  122.    +---------------+          .           +-----------------+\
  123.                               .                      |         \
  124.                               .                      |  LAN
  125.                               .               ---------------
  126.                         Stub border
  127.  
  128.                       Figure 1: NAT Configuration
  129.  
  130.    For instance, in the example of figure 2, both stubs A and B
  131.    internally use class A address 10.0.0.0. Stub A's NAT is assigned the
  132.    class C address 198.76.29.0, and Stub B's NAT is assigned the class C
  133.    address 198.76.28.0. The class C addresses are globally unique no
  134.    other NAT boxes can use them.
  135.  
  136.                                        \ | /
  137.                                      +---------------+
  138.                                      |Regional Router|
  139.                                      +---------------+
  140.                                    WAN |           | WAN
  141.                                        |           |
  142.                    Stub A .............|....   ....|............ Stub B
  143.                                        |           |
  144.                      {s=198.76.29.7,^  |           |  v{s=198.76.29.7,
  145.                       d=198.76.28.4}^  |           |  v d=198.76.28.4}
  146.                        +-----------------+       +-----------------+
  147.                        |Stub Router w/NAT|       |Stub Router w/NAT|
  148.                        +-----------------+       +-----------------+
  149.                              |                         |
  150.                              |  LAN               LAN  |
  151.                        -------------             -------------
  152.                                  |                 |
  153.                {s=10.33.96.5, ^  |                 |  v{s=198.76.29.7,
  154.                 d=198.76.28.4}^ +--+             +--+ v d=10.81.13.22}
  155.                                 |--|             |--|
  156.                                /____\           /____\
  157.                              10.33.96.5       10.81.13.22
  158.  
  159.                      Figure 2: Basic NAT Operation
  160.  
  161.    When stub A host 10.33.96.5 wishes to send a packet to stub B host
  162.    10.81.13.22, it uses the globally unique address 198.76.28.4 as
  163.    destination, and sends the packet to it's primary router. The stub
  164.    router has a static route for net 198.76.0.0 so the packet is
  165.    forwarded to the WAN-link. However, NAT translates the source address
  166.    10.33.96.5 of the IP header with the globally unique 198.76.29.7
  167.  
  168.  
  169.  
  170. Egevang & Francis                                               [Page 3]
  171.  
  172. RFC 1631               Network Address Translator               May 1994
  173.  
  174.  
  175.    before the package is forwarded. Likewise, IP packets on the return
  176.    path go through similar address translations.
  177.  
  178.    Notice that this requires no changes to hosts or routers. For
  179.    instance, as far as the stub A host is concerned, 198.76.28.4 is the
  180.    address used by the host in stub B. The address translations are
  181.    completely transparent.
  182.  
  183.    Of course, this is just a simple example. There are numerous issues
  184.    to be explored. In the next section, we discuss various aspects of
  185.    NAT.
  186.  
  187. 3. Various Aspects of NAT
  188.  
  189. 3.1 Address Spaces
  190.  
  191. Partitioning of Reusable and Non-reusable Addresses
  192.  
  193.    For NAT to operate properly, it is necessary to partition the IP
  194.    address space into two parts - the reusable addresses used internal
  195.    to stub domains, and the globally unique addresses. We call the
  196.    reusable address local addresses, and the globally unique addresses
  197.    global addresses. Any given address must either be a local address or
  198.    a global address. There is no overlap.
  199.  
  200.    The problem with overlap is the following. Say a host in stub A
  201.    wished to send packets to a host in stub B, but the local addresses
  202.    of stub B overlapped the local addressees of stub A. In this case,
  203.    the routers in stub A would not be able to distinguish the global
  204.    address of stub B from its own local addresses.
  205.  
  206. Initial Assignment of Local and Global Addresses
  207.  
  208.    A single class A address should be allocated for local networks. (See
  209.    RFC 1597 [3].)  This address could then be used for internets with no
  210.    connection to the Internet. NAT then provides an easy way to change
  211.    an experimental network to a "real" network by translating the
  212.    experimental addresses to globally unique Internet addresses.
  213.  
  214.    Existing stubs which have unique addresses assigned internally, but
  215.    are running out of them, can change addresses subnet by subnet to
  216.    local addresses. The freed adresses can then be used by NAT for
  217.    external communications.
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Egevang & Francis                                               [Page 4]
  227.  
  228. RFC 1631               Network Address Translator               May 1994
  229.  
  230.  
  231. 3.2 Routing Across NAT
  232.  
  233.    The router running NAT should never advertise the local networks to
  234.    the backbone. Only the networks with global addresses may be known
  235.    outside the stub. However, global information that NAT receives from
  236.    the stub border router can be advertised in the stub the usual way.
  237.  
  238. Private Networks that Span Backbones
  239.  
  240.    In many cases, a private network (such as a corporate network) will
  241.    be spread over different locations and will use a public backbone for
  242.    communications between those locations. In this case, it is not
  243.    desirable to do address translation, both because large numbers of
  244.    hosts may want to communicate across the backbone, thus requiring
  245.    large address tables, and because there will be more applications
  246.    that depend on configured addresses, as opposed to going to a name
  247.    server. We call such a private network a backbone-partitioned stub.
  248.  
  249.    Backbone-partitioned stubs should behave as though they were a non-
  250.    partitioned stub. That is, the routers in all partitions should
  251.    maintain routes to the local address spaces of all partitions. Of
  252.    course, the (public) backbones do not maintain routes to any local
  253.    addresses. Therefore, the border routers must tunnel through the
  254.    backbones using encapsulation. To do this, each NAT box will set
  255.    aside one global address for tunneling. When a NAT box x in stub
  256.    partition X wishes to deliver a packet to stub partition Y, it will
  257.    encapsulate the packet in an IP header with destination address set
  258.    to the global address of NAT box y that has been reserved for
  259.    encapsulation. When NAT box y receives a packet with that destination
  260.    address, it decapsulates the IP header and routes the packet
  261.    internally.
  262.  
  263. 3.3 Header Manipulations
  264.  
  265.    In addition to modifying the IP address, NAT must modify the IP
  266.    checksum and the TCP checksum. Remember, TCP's checksum also covers a
  267.    pseudo header which contains the source and destination address. NAT
  268.    must also look out for ICMP and FTP and modify the places where the
  269.    IP address appears. There are undoubtedly other places, where
  270.    modifications must be done. Hopefully, most such applications will be
  271.    discovered during experimentation with NAT.
  272.  
  273.    The checksum modifications to IP and TCP are simple and efficient.
  274.    Since both use a one's complement sum, it is sufficient to calculate
  275.    the arithmetic difference between the before-translation and after-
  276.    translation addresses and add this to the checksum. The only tricky
  277.    part is determining whether the addition resulted in a wrap-around
  278.    (in either the positive or negative direction) of the checksum. If
  279.  
  280.  
  281.  
  282. Egevang & Francis                                               [Page 5]
  283.  
  284. RFC 1631               Network Address Translator               May 1994
  285.  
  286.  
  287.    so, 1 must be added or subtracted to satisfy the one's complement
  288.    arithmetic. Sample code (in C) for this is as follows:
  289.  
  290.    void checksumadjust(unsigned char *chksum, unsigned char *optr,
  291.    int olen, unsigned char *nptr, int nlen)
  292.    /* assuming: unsigned char is 8 bits, long is 32 bits.
  293.      - chksum points to the chksum in the packet
  294.      - optr points to the old data in the packet
  295.      - nptr points to the new data in the packet
  296.    */
  297.    {
  298.      long x, old, new;
  299.      x=chksum[0]*256+chksum[1];
  300.      x=~x;
  301.      while (olen) {
  302.        if (olen==1) {
  303.          old=optr[0]*256+optr[1];
  304.          x-=old & 0xff00;
  305.          if (x<=0) { x--; x&=0xffff; }
  306.          break;
  307.        }
  308.        else {
  309.          old=optr[0]*256+optr[1]; optr+=2;
  310.          x-=old & 0xffff;
  311.          if (x<=0) { x--; x&=0xffff; }
  312.          olen-=2;
  313.        }
  314.      }
  315.      while (nlen) {
  316.        if (nlen==1) {
  317.          new=nptr[0]*256+nptr[1];
  318.          x+=new & 0xff00;
  319.          if (x & 0x10000) { x++; x&=0xffff; }
  320.          break;
  321.        }
  322.        else {
  323.          new=nptr[0]*256+nptr[1]; nptr+=2;
  324.          x+=new & 0xffff;
  325.          if (x & 0x10000) { x++; x&=0xffff; }
  326.          nlen-=2;
  327.        }
  328.      }
  329.      x=~x;
  330.      chksum[0]=x/256; chksum[1]=x & 0xff;
  331.    }
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Egevang & Francis                                               [Page 6]
  339.  
  340. RFC 1631               Network Address Translator               May 1994
  341.  
  342.  
  343.    The arguments to the File Transfer Protocol (FTP) PORT command
  344.    include an IP address (in ASCII!). If the IP address in the PORT
  345.    command is local to the stub domain, then NAT must substitute this.
  346.    Because the address is encoded in ASCII, this may result in a change
  347.    in the size of the packet (for instance 10.18.177.42 is 12 ASCII
  348.    characters, while 193.45.228.137 is 14 ASCII characters). If the new
  349.    size is the same as the previous, only the TCP checksum needs
  350.    adjustment (again). If the new size is less than the previous, ASCII
  351.    zeroes may be inserted, but this is not guaranteed to work. If the
  352.    new size is larger than the previous, TCP sequence numbers must be
  353.    changed too.
  354.  
  355.    A special table is used to correct the TCP sequence and acknowledge
  356.    numbers with source port FTP or destination port FTP. The table
  357.    entries should have source, destination, source port, destination
  358.    port, initial sequence number, delta for sequence numbers and a
  359.    timestamp. New entries are created only when FTP PORT commands are
  360.    seen. The initial sequence numbers are used to find out if the
  361.    sequence number of a packet is before or after the last FTP PORT
  362.    command (delta may be increased for every FTP PORT command). Sequence
  363.    numbers are incremented and acknowledge numbers are decremented. If
  364.    the FIN bit is set in one of the packets, the associated entry may be
  365.    deleted soon after (1 minute should be safe). Entries that have not
  366.    been used for e.g. 24 hours should be safe to delete too.
  367.  
  368.    The sequence number adjustment must be coded carefully, not to harm
  369.    performance for TCP in general. Of course, if the FTP session is
  370.    encrypted, the PORT command will fail.
  371.  
  372.    If an ICMP message is passed through NAT, it may require two address
  373.    modifications and three checksum modifications. This is because most
  374.    ICMP messages contain part of the original IP packet in the body.
  375.    Therefore, for NAT to be completely transparent to the host, the IP
  376.    address of the IP header embedded in the data part of the ICMP packet
  377.    must be modified, the checksum field of the same IP header must
  378.    correspondingly be modified, and the ICMP header checksum must be
  379.    modified to reflect the changes to the IP header and checksum in the
  380.    ICMP body. Furthermore, the normal IP header must also be modified as
  381.    already described.
  382.  
  383.    It is not entirely clear if the IP header information in the ICMP
  384.    part of the body really need to be modified. This depends on whether
  385.    or not any host code actually looks at this IP header information.
  386.    Indeed, it may be useful to provide the exact header seen by the
  387.    router or host that issued the ICMP message to aid in debugging. In
  388.    any event, no modifications are needed for the Echo and Timestamp
  389.    messages, and NAT should never need to handle a Redirect message.
  390.  
  391.  
  392.  
  393.  
  394. Egevang & Francis                                               [Page 7]
  395.  
  396. RFC 1631               Network Address Translator               May 1994
  397.  
  398.  
  399.    SNMP messages could be modified, but it is even more dubious than for
  400.    ICMP messages that it will be necessary.
  401.  
  402. Applications with IP-address Content
  403.  
  404.    Any application that carries (and uses) the IP address inside the
  405.    application will not work through NAT unless NAT knows of such
  406.    instances and does the appropriate translation. It is not possible or
  407.    even necessarily desirable for NAT to know of all such applications.
  408.    And, if encryption is used then it is impossible for NAT to make the
  409.    translation.
  410.  
  411.    It may be possible for such systems to avoid using NAT, if the hosts
  412.    in which they run are assigned global addresses. Whether or not this
  413.    can work depends on the capability of the intra-domain routing
  414.    algorithm and the internal topology. This is because the global
  415.    address must be advertised in the intra-domain routing algorithm.
  416.    With a low-feature routing algorithm like RIP, the host may require
  417.    its own class C address space, that must not only be advertised
  418.    internally but externally as well (thus hurting global scaling). With
  419.    a high-feature routing algorithm like OSPF, the host address can be
  420.    passed around individually, and can come from the NAT table.
  421.  
  422. Privacy, Security, and Debugging Considerations
  423.  
  424.    Unfortunately, NAT reduces the number of options for providing
  425.    security. With NAT, nothing that carries an IP address or information
  426.    derived from an IP address (such as the TCP-header checksum) can be
  427.    encrypted. While most application-level encryption should be ok, this
  428.    prevents encryption of the TCP header.
  429.  
  430.    On the other hand, NAT itself can be seen as providing a kind of
  431.    privacy mechanism. This comes from the fact that machines on the
  432.    backbone cannot monitor which hosts are sending and receiving traffic
  433.    (assuming of course that the application data is encrypted).
  434.  
  435.    The same characteristic that enhances privacy potentially makes
  436.    debugging problems (including security violations) more difficult. If
  437.    a host is abusing the Internet is some way (such as trying to attack
  438.    another machine or even sending large amounts of junk mail or
  439.    something) it is more difficult to pinpoint the source of the trouble
  440.    because the IP address of the host is hidden.
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Egevang & Francis                                               [Page 8]
  451.  
  452. RFC 1631               Network Address Translator               May 1994
  453.  
  454.  
  455. 4. Conclusions
  456.  
  457.    NAT may be a good short term solution to the address depletion and
  458.    scaling problems. This is because it requires very few changes and
  459.    can be installed incrementally. NAT has several negative
  460.    characteristics that make it inappropriate as a long term solution,
  461.    and may make it inappropriate even as a short term solution. Only
  462.    implementation and experimentation will determine its
  463.    appropriateness.
  464.  
  465. The negative characteristics are:
  466.  
  467. 1. It requires a sparse end-to-end traffic matrix. Otherwise, the NAT
  468.    tables will be large, thus giving lower performance. While the
  469.    expectation is that end-to-end traffic matrices are indeed sparse,
  470.    experience with NAT will determine whether or not they are. In any
  471.    event, future applications may require a rich traffic matrix (for
  472.    instance, distributed resource discovery), thus making long-term use
  473.    of NAT unattractive.
  474.  
  475. 2. It increases the probability of mis-addressing.
  476.  
  477. 3. It breaks certain applications (or at least makes them more difficult
  478.    to run).
  479.  
  480. 4. It hides the identity of hosts. While this has the benefit of
  481.    privacy, it is generally a negative effect.
  482.  
  483. 5. Problems with SNMP, DNS, ... you name it.
  484.  
  485. Current Implementations
  486.  
  487.    Paul and Tony implemented an experimental prototype of NAT on public
  488.    domain KA9Q TCP/IP software [1]. This implementation manipulates
  489.    addresses and IP checksums.
  490.  
  491.    Kjeld implemented NAT in a Cray Communications IP-router. The
  492.    implementation was tested with Telnet and FTP. This implementation
  493.    manipulates addresses, IP checksums, TCP sequence/acknowledge numbers
  494.    and FTP PORT commands.
  495.  
  496.    The prototypes has demonstrated that IP addresses can be translated
  497.    transparently to hosts within the limitations described in this
  498.    paper.
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Egevang & Francis                                               [Page 9]
  507.  
  508. RFC 1631               Network Address Translator               May 1994
  509.  
  510.  
  511. REFERENCES
  512.  
  513.    [1] Karn, P., "KA9Q", anonymous FTP from ucsd.edu
  514.        (hamradio/packet/ka9q/docs).
  515.  
  516.    [2] Fuller, V., Li, T., and J. Yu, "Classless Inter-Domain Routing
  517.        (CIDR) an Address Assignment and Aggregation Strategy", RFC 1519,
  518.        BARRNet, cisco, Merit, OARnet, September 1993.
  519.  
  520.    [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot,
  521.        "Address Allocation for Private Internets", RFC 1597, T.J. Watson
  522.        Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994.
  523.  
  524. Security Considerations
  525.  
  526.    Security issues are not discussed in this memo.
  527.  
  528. Authors' Addresses
  529.  
  530.    Kjeld Borch Egevang
  531.    Cray Communications
  532.    Smedeholm 12-14
  533.    DK-2730 Herlev
  534.    Denmark
  535.  
  536.    Phone: +45 44 53 01 00
  537.    EMail: kbe@craycom.dk
  538.  
  539.  
  540.    Paul Francis
  541.    NTT Software Lab
  542.    3-9-11 Midori-cho Musashino-shi
  543.    Tokyo 180 Japan
  544.  
  545.    Phone: +81-422-59-3843
  546.    Fax +81-422-59-3765
  547.    EMail: francis@cactus.ntt.jp
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Egevang & Francis                                              [Page 10]
  563.  
  564.