home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_n_r
/
draft-rfced-info-srisuresh-01.txt
< prev
next >
Wrap
Text File
|
1997-06-12
|
38KB
|
893 lines
Network Working Group P. Srisuresh
INTERNET-DRAFT 3Com Corporation
Obsoletes: RFC 1631 K. Egevang
Category: Informational Intel Corporation
Expire in six months June 1997
The IP Network Address Translator (NAT)
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).
Preface
This document extends address translation introduced in RFC 1631
to incorporate TCP/UDP port translation. In addition, this
document corrects the Checksum adjustment algorithm published in
RFC 1631 and attempts to discuss NAT operation and limitations
in detail.
Abstract
Basic Network Address Translation or Basic NAT is a feature by
which IP addresses are mapped from one group to another, transparent
to users. Network Address Port Translation, or NAPT is an extension
to Basic NAT, in that many network addresses and their TCP/UDP ports
are translated to a single network address and its TCP/UDP ports.
Srisuresh & Egevang [Page 1]
Internet Draft Network Address Translator June 1997
1. Introduction
The need for IP Address translation arises when a network's internal
IP addresses cannot be used outside the network either for security
reasons or because they are invalid for use outside the network.
Network topology outside a local domain can change in many ways.
Customers may change providers, company backbones may be
reorganized, or providers may merge or split. Whenever external
topology changes with time, address assignment for nodes within the
local domain must also change to reflect the external changes.
Changes of this type can be hidden from the users within the domain
by centralizing changes to a single address translation router.
Basic Address translation feature would allow local hosts on a
private network to transparently access the external global network
and enable access to selective local hosts from the outside.
Organizations with a network setup predominantly for internal use,
with a need for occasional external access are good candidates for
this feature.
Many Small Office, Home Office (SOHO) users and telecommuting
employees have multiple Network nodes in their office, running
TCP/UDP applications, but have a single IP address assigned to
their remote access router by their service provider to access
remote networks. This ever increasing community of remote access
users would be benefited by NAPT, which would permit multiple
nodes in a local network to simultaneously access remote networks
using the single IP address assigned to their router.
There are limitations to using the translation feature. Address
translation must be enabled only on border routers to a stub domain,
where all IP packets are either originated from the domain or
destined to the domain. Address translation requires translation of
not only the IP headers but also some application specific headers
and data, which make reference to IP addresses. FTP is one such
application. Encoded FTP sessions and any encoded sessions in
general that might include IP addresses in the encoding will not
be supported by NAT.
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. The huge advantage of this approach is that it
can be installed without changes to either hosts or routers. (A few
unusual applications may require changes).
2. Terminology and concepts used
Srisuresh & Egevang [Page 2]
Internet Draft Network Address Translator June 1997
2.1. Session flow vs. Packet flow
Connection or session flows are different from packet flows.
A session flow indicates the direction in which the session was
initiated with reference to a network port. Packet flow is the
direction in which the packet has traveled with reference to a
network port.
Take for example, an outbound telnet session. The telnet session
consists of packet flows in both inbound and outbound directions.
Outbound telnet packets carry terminal keystrokes and inbound
telnet packets carry screen displays from the telnet server.
Performing address or TCP port translation for a telnet session
would involve translation of incoming as well as outgoing packets
belonging to that session.
Packets belonging to a TCP/UDP session are uniquely identified
by the tuple of (source IP address, source TU port, target IP
address, target TU port). Packets belonging to all other sessions
are characterized simply by the tuple of (source IP address, target
IP address, IP protocol). A session is uniquely identified by the
first packet of that session.
2.2. TU ports, Server ports, Client ports
For the reminder of this document, we will refer TCP/UDP ports
associated with an IP address simply as "TU ports".
For most TCP/IP hosts, TU port range 0-1023 is used by servers
listening for incoming connections. Clients trying to initiate
a connection typically select a TU port in the range of 1024-65535.
However, this convention is not universal and not always followed.
Some client stations initiate connections using a TU port number
in the range of 0-1023, and there are servers listening on TU
port numbers in the range of 1024-65535.
A complete list of TU port services may be found in Ref[2].
2.3. Start of session for TCP, UDP and others
The first packet of every TCP session tries to establish a session
and contains connection startup information. The first packet of a
TCP session may be recognized by the presence of SYN bit and
absence of ACK bit in the TCP flags. All TCP packets, with the
exception of the first packet must have the ACK bit set.
However, there is no deterministic way of recognizing the start of
Srisuresh & Egevang [Page 3]
Internet Draft Network Address Translator June 1997
a UDP based session or any non-TCP session.
3. Overview of NAT
The design presented in this memo is called NAT, for Network Address
Translator. NAT is a router function that involves address
translation alone or address and TCP/UDP port translation. We will
call the former Basic NAT and the latter NAPT. Together they are
referred to as NAT. Unless mentioned otherwise, Address Translation
or NAT throughout this document will pertain to Basic NAT as well
as NAPT. Only the stub border routers may be configured to perform
address translation.
3.1 Overview of Basic NAT
Basic NAT operation is as follows. A stub domain with a set of
private network addresses could be enabled to communicate with
external network by dynamically mapping to a set of globally
valid network addresses. If the number of local nodes are less
than or equal to addresses in the global set, each local address
is guaranteed to be mapped to an address from global set. Otherwise,
local nodes allowed to have simultaneous access to external network
are limited by the number of addresses in global set. In addition,
individual local addresses may be statically mapped to specific
global addresses to ensure guaranteed access to the outside or to
expose a local node for access from the outside. Multiple sessions
may be initiated from a local node, using the same address mapping.
Addresses inside a stub domain are local to that domain and not
valid outside the domain. Thus, 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.
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub border
Figure 1: NAT Configuration
Srisuresh & Egevang [Page 4]
Internet Draft Network Address Translator June 1997
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 to the globally unique
198.76.29.7 before the packet 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.
3.2. Overview of NAPT
Srisuresh & Egevang [Page 5]
Internet Draft Network Address Translator June 1997
Say, an organization has a private IP network and a WAN link to a
service provider. The private network's stub router is assigned
a globally valid address on the WAN link and the remaining nodes
in the organization have IP addresses that have only local
significance. In such a case, nodes on the private network could
be allowed simultaneous access to external network, using the
single registered IP address with the aid of NAPT. NAPT would
allow mapping of tuples of the type (local IP addresses, local
TU port number) to tuples of the type (registered IP address,
assigned TU port number).
This model fits the requirements of most Small Office Home Office
(SOHO) groups to access external network using a single service
provider assigned IP address. This model could be extended to
allow inbound access by statically mapping a local node per each
service TU port of the registered IP address.
In the example of figure 3 below, stub A internally uses class A
address 10.0.0.0. The stub router's WAN interface is assigned an
IP address 138.76.28.4 by the service provider.
\ | /
+-----------------------+
|Service Provider Router|
+-----------------------+
WAN |
|
Stub A .............|....
|
^{s=138.76.28.4,sport=1024, | v{s=138.76.29.7, sport = 23,
^ d=138.76.29.7,dport=23} | v d=138.76.28.4, dport = 1024}
+------------------+
|Stub Router w/NAPT|
+------------------+
|
| LAN
--------------------------------------------
| ^{s=10.0.0.10,sport=3017, | v{s=138.76.29.7, sport=23,
| ^ d=138.76.29.7,dport=23} | v d=10.0.0.10, dport=3017}
| |
+--+ +--+ +--+
|--| |--| |--|
/____\ /____\ /____\
10.0.0.1 10.0.0.2 ..... 10.0.0.10
Figure 3: Network Address Port Translation (NAPT) Operation
Srisuresh & Egevang [Page 6]
Internet Draft Network Address Translator June 1997
When stub A host 10.0.0.10 sends a telnet packet to host
138.76.29.7, it uses the globally unique address 138.76.29.7 as
destination, and sends the packet to it's primary router. The
stub router has a static route for net 138.76.0.0 so the packet
is forwarded to the WAN-link. However, NAPT translates the tuple
of source address 10.0.0.10 and source TCP port 3017 in the IP
and TCP headers into the globally unique 138.76.28.4 and a
uniquely assigned TCP port, say 1024, before the packet is
forwarded. Packets on the return path go through similar address
and TCP port translations for the target IP address and target
TCP port. Once again, notice that this requires no changes to
hosts or routers. The translation is completely transparent.
In NAPT setup, only TCP/UDP sessions are allowed and must originate
from the local network. However, there are services such as DNS that
demand inbound access. There may be other services for which the
organization wishes to allow inbound session access. It is possible
to statically configure a TU port service on the stub router to be
directed to a specific node in the private network.
In NAPT setup, where the registered IP address is the same as the IP
address of the stub router WAN interface, the router has to be sure
to make distinction between sessions originated from itself versus
those originated from the nodes on local network. All inbound
TCP/UDP sessions are assumed to be directed to the NAT router as
the end node, unless the target service port is statically mapped to
a different node in the local network.
In addition to TCP/UDP sessions, ICMP reject messages will be NAT
monitored as well. But, all other types of sessions are simply not
permitted from local nodes and limited only to the NAT router alone,
as the end node.
4.0. Translation phases of a session.
There are three phases to Address translation, as follows.
4.1. Address binding:
Address binding is the phase in which a local node IP address is
associated with a global address for purposes of translation. For
addresses that have static mapping, the binding happens at startup
time. Otherwise, a local address is bound to a global address
dynamically at the time of session initiation from the local node.
Once a local address is bound to a global address, all subsequent
sessions originating from the same local address will use the same
binding for session based packet translation.
Srisuresh & Egevang [Page 7]
Internet Draft Network Address Translator June 1997
In the case of NAPT, where many local addresses are mapped to a
single globally unique address, the binding would be from (local
IP addr, TU port#) to a TU port of Registered IP address. As
with Basic NAT, this binding is determined at the time of session
initiation.
4.2. Address lookup and translation:
Once address binding is established for a connection setup
through a NAT port, all subsequent packets belonging to the same
connection will be subject to address lookup (and TU port lookup,
in the case of NAPT) for translation purposes.
For outbound packets of a session, the source IP address (and
source TU port, in case of NAPT) and related fields (such as
IP, TCP, UDP and ICMP header checksums) will undergo translation.
For inbound packets of a session, the destination IP address
(and destination TU port, in case of NAPT) and related fields
such as IP, TCP, UDP and ICMP header checksums) will undergo
translation.
4.3. Address unbinding:
Address unbinding is the phase in which a local node IP address is
no longer associated with a global address for purposes of
translation. When the last session based on an address binding is
terminated, it is safe to do the address unbinding after session
termination.
The end of a TCP session is detected when FIN is acknowledged by
both halves of the session or when either half sets RST bit in
TCP flags field. Within a couple seconds after this, the session
can be safely assumed to have been terminated. Dynamically bound
TCP entries that have not been used for say, 24 hours, should
also be safe to delete from the bound list. Dynamically bound
non-TCP entries that have not been used for say, 1 minute, should
also be safe to delete from the bound list. Session timeouts for
TCP and non-TCP sessions could optionally be made user
configurable. Another good way to handle session terminations is
to timestamp entries and keep them as long as possible and retire
the longest idle session when it becomes necessary.
5.0. Header Manipulations
In Basic NAT model, the IP header of every packet must be
modified. This modification includes IP address (source IP
address for outbound packets and destination IP address for
Srisuresh & Egevang [Page 8]
Internet Draft Network Address Translator June 1997
inbound packets) and the IP checksum.
For TCP/UDP sessions, modifications must include update of
checksum in the TCP/UDP headers. This is because TCP/UDP
checksum also covers a pseudo header which contains the source
and destination IP addresses. As an exception, UDP headers
with 0 checksum should not be modified. Basic NAT must also look
out for ICMP and FTP and modify the places where the IP address
appears. There may be other places, where modifications must be
done. Those are not widely known applications.
In NAPT model, modifications to IP header are similar to that of
Basic NAT. For TCP/UDP sessions, modifications must be extended
to include translation of TU port (source TU port for outbound
packets and destination TU port for inbound packets) in the
TCP/UDP header. In general, NAPT must look for IP address as well
as TU port and modify all places in the packet where IP address
and TU port appear.
NAT modifications are per packet based and can be very compute
intensive, as they involve one or more checksum modifications
in addition to simple field translations. Luckily, we have
an algorithm below, which makes checksum adjustment to IP, TCP,
UDP and ICMP headers very simple and efficient. Since all these
headers 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 algorithm
below is applicable only for even offsets (i.e., optr must be at
an even offset from start of header) and even lengths (i.e., olen
and nlen below must be even). 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 & 0xFFFF;
while (olen)
{
old=optr[0]*256+optr[1]; optr+=2;
x-=old & 0xffff;
Srisuresh & Egevang [Page 9]
Internet Draft Network Address Translator June 1997
if (x<=0) { x--; x&=0xffff; }
olen-=2;
}
while (nlen)
{
new=nptr[0]*256+nptr[1]; nptr+=2;
x+=new & 0xffff;
if (x & 0x10000) { x++; x&=0xffff; }
nlen-=2;
}
x=~x & 0xFFFF;
chksum[0]=x/256; chksum[1]=x & 0xff;
}
5.1. FTP sessions
The arguments to the File Transfer Protocol (FTP) PORT command and
PASV response include an IP address and a TCP port (in ASCII!). If
the IP address in PORT command or PASV response is local to the
stub domain, then NAT must substitute this. Because the address
and TCP port are encoded in ASCII, this may result in a change in
the size of packet. For instance, 10,18,177,42,64,87 is 18 ASCII
characters, whereas 193,45,228,137,64,87 is 20 ASCII characters.
If the new size is same as the previous, only the TCP checksum
needs adjustment as a result of change of data. If the new size
is less than or greater than the previous, TCP sequence numbers
must also be changed to reflect the change in length of FTP control
data portion.
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, delta for sequence numbers and a timestamp. New entries are
created only when FTP PORT commands or PASV responses are seen. The
sequence number delta may be increased or decreased for every FTP
PORT command or PASV response. Sequence numbers are incremented
and acknowledge numbers are decremented by this delta.
The sequence number adjustment must be coded carefully, not to harm
performance for TCP in general. Of course, if the FTP session is
encrypted, PORT command and/or PASV response will fail.
5.2. ICMP packet modifications
If an ICMP message is passed through NAT, it may require two address
modifications and three checksum modifications. This is because most
Srisuresh & Egevang [Page 10]
Internet Draft Network Address Translator June 1997
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. In a NAPT setup, if the IP message
embedded within ICMP happens to be a TCP or UDP packet, you will
also need to modify the appropriate TU port number within the
TCP/UDP header.
No modifications are needed for the Echo and Timestamp messages,
and NAT should never need to handle a Redirect message. As for
SNMP and SMTP applications, translation of addresses within SNMP
or SMTP messages would not be attempted by NAT routers. At some
point, it must be left to application specific proxy agents to
do the translations as appropriate to the application.
5.3. IP option handling
An IP datagram with any of the IP options Record Route, Strict
Source Route or Loose Source Route would involve IP addresses of the
intermediate routers. A NAT intermediate router would simply leave
the addresses untranslated and essentially not participate in the
processing of these options. The reason is simply that NAT is not
a full solution, but just a hack (a nice hack, may be).
An ICMP datagram with record route option is very likely intended
for debugging purposes. Hence, leaving the local addresses
untranslated will likely not break the application.
5.4. Applications with IP-address Content
Any application that carries (and uses) the IP address (and
TU port, in case of NAPT) inside the application will not work
through NAT unless NAT knows of such instances and knows to do
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
Srisuresh & Egevang [Page 11]
Internet Draft Network Address Translator June 1997
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.
6. Miscellaneous issues
6.1. Partitioning of Local and Global Addresses
For NAT to operate properly, it is necessary to partition the IP
address space into two parts - the local addresses used internal
to stub domains, and the globally unique 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 global
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.
6.2. Private address space recommendation
The RFC listed in ref[1] has recommendations on address space
allocation for private networks. Internet Assigned Numbers
Authority (IANA) has three blocks of IP address space, namely
10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for private
internets. In pre-CIDR notation, the first block is nothing but
a single class A network number, while the second block is a set
of 16 contiguous class B networks, and the third block is a set of
256 contiguous class C networks.
An organization that decides to use IP addresses in the address
space defined above can do so without any coordination with IANA
or an Internet registry. The address space can thus be used
privately by many independent organizations at the same time,
with NAT operation enabled on their border routers.
6.3. Routing Across NAT
The router running NAT should not 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.
Srisuresh & Egevang [Page 12]
Internet Draft Network Address Translator June 1997
Typically, the NAT stub router will have a static route configured
to forward all external traffic to service provider router over WAN
link, and the service provider router will have a static route
configured to forward NAT packets (i.e., those whose destination
IP address fall within the range of NAT managed global address list)
to NAT router over WAN link.
6.4. 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.
6.5. Switch-over from Basic NAT to NAPT
In Basic NAT setup, when local network nodes outnumber global
addresses available for mapping (say, a class B local network
mapped to a class C global address block), external network
access to some of the local nodes is abruptly cut off after the
last global address from the address list is used up. This is
very inconvenient and constraining. Such an incident can be
safely avoided by optionally allowing the Basic NAT router to
switch over to NAPT setup for the last global address in the
address list. Doing this will guarantee that hosts on local
network will have continued, uninterrupted access to the external
nodes and services.
7.0. NAT limitations
Srisuresh & Egevang [Page 13]
Internet Draft Network Address Translator June 1997
7.1. Privacy, Security, and Debugging Considerations
Unfortunately, NAT reduces the number of options for providing
security. With NAT, nothing that carries an IP address or TU port or
information derived from an IP address or TU port (such as the
IP/TCP/UDP/ICMP header checksum) can be encrypted. While most
application-level encryption should be ok, this prevents encryption
of TCP/UDP headers.
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 in 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 in a NAT router.
7.2. ARP responses to NAT mapped global addresses on a LAN interface
NAT must be enabled only on border routers of a stub domain. The
examples provided in the document to illustrate Basic NAT and
NAPT have maintained a WAN link for connection to external router
(i.e., service provider router) from NAT router. However, if the
WAN link were to be replaced by a LAN connection and if part or
all of the global address space used for NAT mapping belongs to
the same IP subnet as the LAN segment, the NAT router would be
expected to provide ARP support for the address range that belongs
to the same subnet. Responding to ARP requests for the NAT
mapped global addresses with its own MAC address is a must in
such a situation with Basic NAT setup. If the NAT router did
not respond to these requests, there is no other node in the
network that has ownership to these addresses and hence will
go unresponded.
This scenario is unlikely with NAPT setup except when the single
address used in NAPT mapping is not the interface address of the
NAT router (as in the case of a switch-over from Basic NAT to NAPT
explained in 6.5 above, for example).
Using an address range from a directly connected subnet for NAT
address mapping would obviate static route configuration on the
service provider router.
Srisuresh & Egevang [Page 14]
Internet Draft Network Address Translator June 1997
It is the opinion of the authors that a LAN link to a service
provider router is not very common. However, vendors may be
interested to optionally support proxy ARP just in case.
7.3. Negative characteristics:
1. NAT is compute intensive even with the help of a clever checksum
adjust algorithm, as each data packet is subject to NAT lookup and
modifications. As a result, router forwarding throughput will be
slowed considerably.
2. NAT increases the probability of mis-addressing. For example, same
local address may be bound to different global address at different
times and vice versa. As a result, any traffic flow study based
purely on global addresses and TU ports could be confused and
might misinterpret the results.
3. It breaks certain applications or at least makes them more difficult
to run.
With the exception of FTP, NAT will not do address and TU port
translations outside of the IP and the TCP/UDP headers. This
includes DNS request and response messages. It is expected that
internal DNS servers maintain mapping of names to IP addresses for
internal hosts as well as some external hosts. External DNS servers
would be expected to maintain name mapping for external hosts alone
and not for any of the internal hosts. If the local network does not
have an internal DNS server, all DNS requests may be directed to the
external DNS server to get address mapping for the external hosts.
There may be issues with SNMP as well.
4. It hides the identity of hosts. This is not to be confused with
security however. Security on a router must be relegated to firewall
functionality, independent of or in conjunction with NAT operation.
8.0. Current Implementations
Many commercial implementations are available in the industry that
adhere to the NAT description provided in this document. However,
the authors are not aware of any public domain software for NAT.
REFERENCES
[1] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and,
Lear, E. "Address Allocation for Private Internets", RFC 1918
Srisuresh & Egevang [Page 15]
Internet Draft Network Address Translator June 1997
or its successor.
[2] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700 or
its successor.
9.0. Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
Pyda Srisuresh
3Com Corporation
Santa Clara, CA
U.S.A.
Voice: (408) 764-6968
Fax: (408) 764-6134
EMail: suresh@3com.com
Kjeld Borch Egevang
Intel Denmark ApS
Voice: +45 44530100
Fax: +45 44531415
EMail: kbe@casetech.dk
http: //www.geocities.com/Paris/2610
Srisuresh & Egevang [Page 16]
