Network Working Group G. Gloesener
INTERNET-DRAFT Digital Equipment
Expire in six months December 1996
NAT extension for existing "external" networks
<draft-gloesener-nat-ext-00.txt>
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