[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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-

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

        /                                                    \   +---+
        |                      Internet                      |---|PC3|
        \____________________________________________________/   +---+
                               | R1|
                                 |/| Unnumbered
                                 | R2|
                    |          | /NAT addresses
                  +---+                  +---+          |
                  |PC1|                  | R3| =========|     to
                  +---+                  +---+          \

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
   ( to 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 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. to 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 (for example) and then
   it will be forwarded to R2 according to the routing protocol used.
   Once PC3 replies to 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. ). This
   represents no problem since the node PC2 is physically on another net
   (i.e., 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).


   [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

Relation to other RFCs