From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1631.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc1631.txt (limited to 'doc/rfc/rfc1631.txt') diff --git a/doc/rfc/rfc1631.txt b/doc/rfc/rfc1631.txt new file mode 100644 index 0000000..3779ba4 --- /dev/null +++ b/doc/rfc/rfc1631.txt @@ -0,0 +1,563 @@ + + + + + + +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] + +RFC 1631 Network Address Translator May 1994 + + + so, 1 must be added or subtracted to satisfy the one's complement + arithmetic. Sample code (in C) for this is as follows: + + void checksumadjust(unsigned char *chksum, unsigned char *optr, + int olen, unsigned char *nptr, int nlen) + /* assuming: unsigned char is 8 bits, long is 32 bits. + - chksum points to the chksum in the packet + - optr points to the old data in the packet + - nptr points to the new data in the packet + */ + { + long x, old, new; + x=chksum[0]*256+chksum[1]; + x=~x; + while (olen) { + if (olen==1) { + old=optr[0]*256+optr[1]; + x-=old & 0xff00; + if (x<=0) { x--; x&=0xffff; } + break; + } + else { + old=optr[0]*256+optr[1]; optr+=2; + x-=old & 0xffff; + if (x<=0) { x--; x&=0xffff; } + olen-=2; + } + } + while (nlen) { + if (nlen==1) { + new=nptr[0]*256+nptr[1]; + x+=new & 0xff00; + if (x & 0x10000) { x++; x&=0xffff; } + break; + } + else { + new=nptr[0]*256+nptr[1]; nptr+=2; + x+=new & 0xffff; + if (x & 0x10000) { x++; x&=0xffff; } + nlen-=2; + } + } + x=~x; + chksum[0]=x/256; chksum[1]=x & 0xff; + } + + + + + + +Egevang & Francis [Page 6] + +RFC 1631 Network Address Translator May 1994 + + + The arguments to the File Transfer Protocol (FTP) PORT command + include an IP address (in ASCII!). If the IP address in the PORT + command is local to the stub domain, then NAT must substitute this. + Because the address is encoded in ASCII, this may result in a change + in the size of the packet (for instance 10.18.177.42 is 12 ASCII + characters, while 193.45.228.137 is 14 ASCII characters). If the new + size is the same as the previous, only the TCP checksum needs + adjustment (again). If the new size is less than the previous, ASCII + zeroes may be inserted, but this is not guaranteed to work. If the + new size is larger than the previous, TCP sequence numbers must be + changed too. + + A special table is used to correct the TCP sequence and acknowledge + numbers with source port FTP or destination port FTP. The table + entries should have source, destination, source port, destination + port, initial sequence number, delta for sequence numbers and a + timestamp. New entries are created only when FTP PORT commands are + seen. The initial sequence numbers are used to find out if the + sequence number of a packet is before or after the last FTP PORT + command (delta may be increased for every FTP PORT command). Sequence + numbers are incremented and acknowledge numbers are decremented. If + the FIN bit is set in one of the packets, the associated entry may be + deleted soon after (1 minute should be safe). Entries that have not + been used for e.g. 24 hours should be safe to delete too. + + The sequence number adjustment must be coded carefully, not to harm + performance for TCP in general. Of course, if the FTP session is + encrypted, the PORT command will fail. + + If an ICMP message is passed through NAT, it may require two address + modifications and three checksum modifications. This is because most + ICMP messages contain part of the original IP packet in the body. + Therefore, for NAT to be completely transparent to the host, the IP + address of the IP header embedded in the data part of the ICMP packet + must be modified, the checksum field of the same IP header must + correspondingly be modified, and the ICMP header checksum must be + modified to reflect the changes to the IP header and checksum in the + ICMP body. Furthermore, the normal IP header must also be modified as + already described. + + It is not entirely clear if the IP header information in the ICMP + part of the body really need to be modified. This depends on whether + or not any host code actually looks at this IP header information. + Indeed, it may be useful to provide the exact header seen by the + router or host that issued the ICMP message to aid in debugging. In + any event, no modifications are needed for the Echo and Timestamp + messages, and NAT should never need to handle a Redirect message. + + + + +Egevang & Francis [Page 7] + +RFC 1631 Network Address Translator May 1994 + + + SNMP messages could be modified, but it is even more dubious than for + ICMP messages that it will be necessary. + +Applications with IP-address Content + + Any application that carries (and uses) the IP address inside the + application will not work through NAT unless NAT knows of such + instances and does the appropriate translation. It is not possible or + even necessarily desirable for NAT to know of all such applications. + And, if encryption is used then it is impossible for NAT to make the + translation. + + It may be possible for such systems to avoid using NAT, if the hosts + in which they run are assigned global addresses. Whether or not this + can work depends on the capability of the intra-domain routing + algorithm and the internal topology. This is because the global + address must be advertised in the intra-domain routing algorithm. + With a low-feature routing algorithm like RIP, the host may require + its own class C address space, that must not only be advertised + internally but externally as well (thus hurting global scaling). With + a high-feature routing algorithm like OSPF, the host address can be + passed around individually, and can come from the NAT table. + +Privacy, Security, and Debugging Considerations + + Unfortunately, NAT reduces the number of options for providing + security. With NAT, nothing that carries an IP address or information + derived from an IP address (such as the TCP-header checksum) can be + encrypted. While most application-level encryption should be ok, this + prevents encryption of the TCP header. + + On the other hand, NAT itself can be seen as providing a kind of + privacy mechanism. This comes from the fact that machines on the + backbone cannot monitor which hosts are sending and receiving traffic + (assuming of course that the application data is encrypted). + + The same characteristic that enhances privacy potentially makes + debugging problems (including security violations) more difficult. If + a host is abusing the Internet is some way (such as trying to attack + another machine or even sending large amounts of junk mail or + something) it is more difficult to pinpoint the source of the trouble + because the IP address of the host is hidden. + + + + + + + + + +Egevang & Francis [Page 8] + +RFC 1631 Network Address Translator May 1994 + + +4. Conclusions + + NAT may be a good short term solution to the address depletion and + scaling problems. This is because it requires very few changes and + can be installed incrementally. 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. Only + implementation and experimentation will determine its + appropriateness. + +The negative characteristics are: + +1. 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. + +Current Implementations + + Paul and Tony implemented an experimental prototype of NAT on public + domain KA9Q TCP/IP software [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 1994 + + +REFERENCES + + [1] 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: kbe@craycom.dk + + + 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: francis@cactus.ntt.jp + + + + + + + + + + + + + + +Egevang & Francis [Page 10] + -- cgit v1.2.3