Network Working Group G. Gloesener INTERNET-DRAFT Digital Equipment Expire in six months December 1996 NAT extension for existing "external" networks Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 1. Introduction The main use of NAT is to connect an existing internal network via an ISP to the Internet. The current NAT RFC1631 supposes that the network number used for the translation is not existing physically on any network. This does not work in some circumstances where the router connected to the ISP line is not under control of the user. This implies that the network where the NAT router is connected to, has the same network number than the one used by NAT. Such a configuration is shown in Figure 1, where the ISP provides a lass C network to his customer. Router R1 is remote and R2 local to the customer. Both routrs have to be accepted as-is from the ISP (i.e. no changes to the config can be done). The class C network 198.56.12. is provided. In this example we have a PC (PC1) connected directly to the internet network as provided by R2. For the internal usage NAT is used, but since the only one CLASS C address is provided, NAT and the external network have the same network number. Subnetting in this case is not a valid approach since at least half of the addresses are then on the external network where usually only a few are needed. Further to this R3 will provide filtering for the internal network, using PC1 as public server. This configuration is not valid as of RFC1631. Gast Gloesener [Page 2] Figure 1: Extended NAT configuration ____________________________________________________ 153.15.34.29 / \ +---+ | Internet |---|PC3| \____________________________________________________/ +---+ | | +---+ | R1| +---+ | |/| Unnumbered | +---+ | R2| +---+ | 198.56.12.1 | |----+--------------+-------+---------| |198.56.12.10 |198.56.12.2 /NAT addresses +---+ +---+ |198.56.12.100 |PC1| | R3| =========| to +---+ +---+ \198.56.12.200 |192.168.1.1 |-------------------+-----------+-------------| |192.168.1.10 +---+ |PC2| +---+ 2. Overview of this extension The extension of NAT discussed in this memo is intended to solve the above situation by extending NAT without interfering with the "basic" NAT implementation according to RFC1631. The way to implement this is to split the NAT network into a physical and a logical part. The logical part being the one used by NAT (198.56.12.100 to 198.56.12.200 in the example above) When this is done one of the interfaces of the router may have one of the physical addresses of the same network number (above it is 198.56.12.2). Other routers or hosts connected physically to that network may also use some of the physical addresses. Note that a second router on the same network may use some of R3s physical addresses (i.e. addresses not used by NAT) for another NAT translation table thus one network number can be used for multiple internal networks. The NAT router (R3) should reply to ARP requests for his physical address and the logical addresses used by NAT (i.e. 198.56.12.100 to 198.56.12.200) on the interface which belongs to the same network number than NAT does, providing its hardware address as destination. For logical (NAT) address assignements the router may not respond or reply with a destination unreachable ICMP packet (Host unreachable) for addresses that are currently not assigned to any "internal" host. PC2 which want to address PC3 will have the source address of his packet modified in router R3 to 198.56.12.110 (for example) and then it will be forwarded to R2 according to the routing protocol used. Once PC3 replies to 198.56.12.100 and the packet comes to R2, R2 will do an ARP request for this address. R3 replying to this request with his hardware address will receive the packet apply the NAT modifications and forward it to PC2 with his address being the new destination address of the IP packet. Looking at the special case where PC2 want to talk to PC1 being virtualy on the same network number (i.e. 198.56.12.0 ). This represents no problem since the node PC2 is physically on another net (i.e. 192.168.1.0), so that it will use its routing table finding R3 being the appropriate router. R3 can determine that the destination is not one of its assigned NAT addresses (logical) so that it will use ARP to find the physical destination which is PC1. The reply of PC1 works like in the previous example for the communication between R2 and R3. The configuration of the ARP replies for the router R3 may be implemented to be done manually or even better and less error generating) automatically. When configuring NAT the router finds out that the NAT network number is used by one of its interfaces and it can now setup this interface to reply to ARP requests for the configured NAT address range(s) (logical addresses). References [1] Egevang K., Francis P., "The IP Network Address Translator (NAT) RFC1631, Cray Communications, NTT, May 1994 Security Considerations Security issues are not covered by this memo Authors Addresses Gast Gloesener Digital Equipment Luxembourg 7a, rue Robert Stumper L-2557 Luxembourg Luxembourg Relation to other RFCs UPDATES RFC1631