As per Relevance of the word globally, we have this rfc below:
Network Working Group K.
Request for Comments: 1631 Cray
Category: Informational P.
May 1994
The IP Network Address Translator (NAT
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The two most compelling problems facing the IP Internet are
address depletion and scaling in routing. Long-term and short-
solutions to these problems are being developed. The short-
solution is CIDR (Classless InterDomain Routing). The long-
solutions consist of various proposals for new internet
with larger addresses
It is possible that CIDR will not be adequate to maintain the
Internet until the long-term solutions are in place. This
proposes another short-term solution, address reuse, that
CIDR or even makes it unnecessary. The address reuse solution is
place Network Address Translators (NAT) at the borders of
domains. Each NAT box has a table consisting of pairs of local
addresses and globally unique addresses. The IP addresses inside
stub domain are not globally unique. They are reused in
domains, thus solving the address depletion problem. The
unique IP addresses are assigned according to current CIDR
allocation schemes. CIDR solves the scaling problem. The
advantage of NAT is that it can be installed without changes
routers or hosts. This memo presents a preliminary design for NAT
and discusses its pros and cons
This memo is based on a paper by Paul Francis (formerly Tsuchiya)
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
introduced adjustment of sequence-numbers for FTP. Thanks to
Michael Christensen for his comments on the idea and text (we
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.
The two most compelling problems facing the IP Internet are
address depletion and scaling in routing. Long-term and short-
solutions to these problems are being developed. The short-
solution is CIDR (Classless InterDomain Routing) [2]. The long-
solutions consist of various proposals for new internet
with larger addresses
Until the long-term solutions are ready an easy way to hold down
demand for IP addresses is through address reuse. This solution
advantage of the fact that a very small percentage of hosts in a
domain are communicating outside of the domain at any given time. (
stub domain is a domain, such as a corporate network, that
handles traffic originated or destined to hosts in the domain).
Indeed, many (if not most) hosts never communicate outside of
stub domain. Because of this, only a subset of the IP
inside a stub domain, need be translated into IP addresses that
globally unique when outside communications is required
This solution has the disadvantage of taking away the end-to-
significance of an IP address, and making up for it with
state in the network. There are various work-arounds that
the potential pitfalls of this. Indeed, connection-oriented
are essentially doing address reuse at every hop
The huge advantage of this approach is that it can be
incrementally, without changes to either hosts or routers. (A
unusual applications may require changes). As such, this solution
be implemented and experimented with quickly. If nothing else,
solution can serve to provide temporarily relief while other,
complex and far-reaching solutions are worked out
2. Overview of
The design presented in this memo is called NAT, for Network
Translator. NAT is a router function that can be configured as
in figure 1. Only the stub border router requires modifications
NAT's basic operation is as follows. The addresses inside a
domain can be reused by any other stub domain. For instance, a
Class A address could be used by many stub domains. At each
point between a stub domain and backbone, NAT is installed. If
is more than one exit point it is of great importance that each
has the same translation table
Egevang & Francis [Page 2]
RFC 1631 Network Address Translator May 1994
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. |
. ---------------
Stub
Figure 1: NAT
For instance, in the example of figure 2, both stubs A and
internally use class A address 10.0.0.0. Stub A's NAT is assigned
class C address 198.76.29.0, and Stub B's NAT is assigned the class
address 198.76.28.0. The class C addresses are globally unique
other NAT boxes can use them
\ | /
+---------------+
|Regional Router
+---------------+
WAN | |
| |
Stub A .............|.... ....|............ Stub
| |
{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
When stub A host 10.33.96.5 wishes to send a packet to stub B
10.81.13.22, it uses the globally unique address 198.76.28.4
destination, and sends the packet to it's primary router. The
router has a static route for net 198.76.0.0 so the packet
forwarded to the WAN-link. However, NAT translates the source
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
path go through similar address translations
Notice that this requires no changes to hosts or routers.
instance, as far as the stub A host is concerned, 198.76.28.4 is
address used by the host in stub B. The address translations
completely transparent
Of course, this is just a simple example. There are numerous
to be explored. In the next section, we discuss various aspects
NAT
3. Various Aspects of
3.1 Address
Partitioning of Reusable and Non-reusable
For NAT to operate properly, it is necessary to partition the
address space into two parts - the reusable addresses used
to stub domains, and the globally unique addresses. We call
reusable address local addresses, and the globally unique
global addresses. Any given address must either be a local address
a global address. There is no overlap
The problem with overlap is the following. Say a host in stub
wished to send packets to a host in stub B, but the local
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
address of stub B from its own local addresses
Initial Assignment of Local and Global
A single class A address should be allocated for local networks. (
RFC 1597 [3].) This address could then be used for internets with
connection to the Internet. NAT then provides an easy way to
an experimental network to a "real" network by translating
experimental addresses to globally unique Internet addresses
Existing stubs which have unique addresses assigned internally,
are running out of them, can change addresses subnet by subnet
local addresses. The freed adresses can then be used by NAT
external communications
Egevang & Francis [Page 4]
RFC 1631 Network Address Translator May 1994
3.2 Routing Across
The router running NAT should never advertise the local networks
the backbone. Only the networks with global addresses may be
outside the stub. However, global information that NAT receives
the stub border router can be advertised in the stub the usual way
Private Networks that Span
In many cases, a private network (such as a corporate network)
be spread over different locations and will use a public backbone
communications between those locations. In this case, it is
desirable to do address translation, both because large numbers
hosts may want to communicate across the backbone, thus
large address tables, and because there will be more
that depend on configured addresses, as opposed to going to a
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
maintain routes to the local address spaces of all partitions.
course, the (public) backbones do not maintain routes to any
addresses. Therefore, the border routers must tunnel through
backbones using encapsulation. To do this, each NAT box will
aside one global address for tunneling. When a NAT box x in
partition X wishes to deliver a packet to stub partition Y, it
encapsulate the packet in an IP header with destination address
to the global address of NAT box y that has been reserved
encapsulation. When NAT box y receives a packet with that
address, it decapsulates the IP header and routes the
internally
3.3 Header
In addition to modifying the IP address, NAT must modify the
checksum and the TCP checksum. Remember, TCP's checksum also covers
pseudo header which contains the source and destination address.
must also look out for ICMP and FTP and modify the places where
IP address appears. There are undoubtedly other places,
modifications must be done. Hopefully, most such applications will
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
the arithmetic difference between the before-translation and after
translation addresses and add this to the checksum. The only
part is determining whether the addition resulted in a wrap-
(in either the positive or negative direction) of the checksum.
Egevang & Francis [Page 5]
RFC 1631 Network Address Translator May 1994
so, 1 must be added or subtracted to satisfy the one's
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
- optr points to the old data in the
- nptr points to the new data in the
*/
{
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
include an IP address (in ASCII!). If the IP address in the
command is local to the stub domain, then NAT must substitute this
Because the address is encoded in ASCII, this may result in a
in the size of the packet (for instance 10.18.177.42 is 12
characters, while 193.45.228.137 is 14 ASCII characters). If the
size is the same as the previous, only the TCP checksum
adjustment (again). If the new size is less than the previous,
zeroes may be inserted, but this is not guaranteed to work. If
new size is larger than the previous, TCP sequence numbers must
changed too
A special table is used to correct the TCP sequence and
numbers with source port FTP or destination port FTP. The
entries should have source, destination, source port,
port, initial sequence number, delta for sequence numbers and
timestamp. New entries are created only when FTP PORT commands
seen. The initial sequence numbers are used to find out if
sequence number of a packet is before or after the last FTP
command (delta may be increased for every FTP PORT command).
numbers are incremented and acknowledge numbers are decremented.
the FIN bit is set in one of the packets, the associated entry may
deleted soon after (1 minute should be safe). Entries that have
been used for e.g. 24 hours should be safe to delete too
The sequence number adjustment must be coded carefully, not to
performance for TCP in general. Of course, if the FTP session
encrypted, the PORT command will fail
If an ICMP message is passed through NAT, it may require two
modifications and three checksum modifications. This is because
ICMP messages contain part of the original IP packet in the body
Therefore, for NAT to be completely transparent to the host, the
address of the IP header embedded in the data part of the ICMP
must be modified, the checksum field of the same IP header
correspondingly be modified, and the ICMP header checksum must
modified to reflect the changes to the IP header and checksum in
ICMP body. Furthermore, the normal IP header must also be modified
already described
It is not entirely clear if the IP header information in the
part of the body really need to be modified. This depends on
or not any host code actually looks at this IP header information
Indeed, it may be useful to provide the exact header seen by
router or host that issued the ICMP message to aid in debugging.
any event, no modifications are needed for the Echo and
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
ICMP messages that it will be necessary
Applications with IP-address
Any application that carries (and uses) the IP address inside
application will not work through NAT unless NAT knows of
instances and does the appropriate translation. It is not possible
even necessarily desirable for NAT to know of all such applications
And, if encryption is used then it is impossible for NAT to make
translation
It may be possible for such systems to avoid using NAT, if the
in which they run are assigned global addresses. Whether or not
can work depends on the capability of the intra-domain
algorithm and the internal topology. This is because the
address must be advertised in the intra-domain routing algorithm
With a low-feature routing algorithm like RIP, the host may
its own class C address space, that must not only be
internally but externally as well (thus hurting global scaling).
a high-feature routing algorithm like OSPF, the host address can
passed around individually, and can come from the NAT table
Privacy, Security, and Debugging
Unfortunately, NAT reduces the number of options for
security. With NAT, nothing that carries an IP address or
derived from an IP address (such as the TCP-header checksum) can
encrypted. While most application-level encryption should be ok,
prevents encryption of the TCP header
On the other hand, NAT itself can be seen as providing a kind
privacy mechanism. This comes from the fact that machines on
backbone cannot monitor which hosts are sending and receiving
(assuming of course that the application data is encrypted).
The same characteristic that enhances privacy potentially
debugging problems (including security violations) more difficult.
a host is abusing the Internet is some way (such as trying to
another machine or even sending large amounts of junk mail
something) it is more difficult to pinpoint the source of the
because the IP address of the host is hidden
Egevang & Francis [Page 8]
RFC 1631 Network Address Translator May 1994
4.
NAT may be a good short term solution to the address depletion
scaling problems. This is because it requires very few changes
can be installed incrementally. NAT has several
characteristics that make it inappropriate as a long term solution
and may make it inappropriate even as a short term solution.
implementation and experimentation will determine
appropriateness
The negative characteristics are
1. It requires a sparse end-to-end traffic matrix. Otherwise, the
tables will be large, thus giving lower performance. While
expectation is that end-to-end traffic matrices are indeed sparse
experience with NAT will determine whether or not they are. In
event, future applications may require a rich traffic matrix (
instance, distributed resource discovery), thus making long-term
of NAT unattractive
2. It increases the probability of mis-addressing
3. It breaks certain applications (or at least makes them more
to run).
4. It hides the identity of hosts. While this has the benefit
privacy, it is generally a negative effect
5. Problems with SNMP, DNS, ... you name it
Current
Paul and Tony implemented an experimental prototype of NAT on
domain KA9Q TCP/IP software [1]. This implementation
addresses and IP checksums
Kjeld implemented NAT in a Cray Communications IP-router.
implementation was tested with Telnet and FTP. This
manipulates addresses, IP checksums, TCP sequence/acknowledge
and FTP PORT commands
The prototypes has demonstrated that IP addresses can be
transparently to hosts within the limitations described in
paper
Egevang & Francis [Page 9]
RFC 1631 Network Address Translator May 1994
[1] Karn, P., "KA9Q", anonymous FTP from ucsd.
(hamradio/packet/ka9q/docs).
[2] Fuller, V., Li, T., and J. Yu, "Classless Inter-Domain
(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.
Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994.
Security
Security issues are not discussed in this memo
Authors'
Kjeld Borch
Cray
Smedeholm 12-14
DK-2730
Phone: +45 44 53 01 00
EMail: kbe@craycom.
Paul
NTT Software
3-9-11 Midori-cho Musashino-
Tokyo 180
Phone: +81-422-59-3843
Fax +81-422-59-3765
EMail: francis@cactus.ntt.
Egevang & Francis [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
