NAT Working Group P. Srisuresh
INTERNET-DRAFT Campio Communications
Obsoletes: RFC 1631 K. Egevang
Category: Informational Intel Corporation
Expires as of October 9, 2000 April 9, 2000
Traditional IP Network Address Translator (Traditional NAT)
<draft-ietf-nat-traditional-04.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Preface
The NAT operation described in this document extends address
translation introduced in RFC 1631 and includes a new type
of network address and 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 method by which
IP addresses are mapped from one group to another, transparent to
end users. Network Address Port Translation, or NAPT is a method by
Srisuresh & Egevang [Page 1]
Internet-Draft Traditional NAT April 2000
which many network addresses and their TCP/UDP ports are translated
into a single network address and its TCP/UDP ports. Together,
these two operations, referred to as traditional NAT, provide a
mechanism to connect a realm with private addresses to an
external realm with globally unique registered addresses.
1. Introduction
The need for IP Address translation arises when a network's internal
IP addresses cannot be used outside the network either for privacy
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 users within the domain
by centralizing changes to a single address translation router.
Basic Address translation would (in many cases, except as noted in
RFC 2663 and section 6 of this document) allow hosts in a private
network to transparently access the external 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 scheme.
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 method. It is
mandatory that all requests and responses pertaining to a session
be routed via the same NAT router. One way to ascertain this would
be to have NAT based on a border router that is unique to a stub
domain, where all IP packets are either originated from the domain
or destined to the domain. There are other ways to ensure this
with multiple NAT devices. For example, a private domain could have
two distinct exit points to different providers and the session flow
from the hosts in a private network could traverse through whichever
NAT device has the best metric for an external host.
Srisuresh & Egevang [Page 2]
Internet-Draft Traditional NAT April 2000
Address translation is application independent and often accompanied
by application specific gateways (ALGs) to perform payload
monitoring and alterations. FTP is the most popular ALG resident on
NAT devices. Applications requiring ALG intervention must not have
their payload encoded, as doing that would effectively disables the
ALG, unless the ALG has the key to decrypt the the payload.
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. As a result, end-to-end IP network level
security assured by IPSec cannot be assumed to end hosts, with a
NAT device enroute. The advantage of this approach however is that
it can be installed without changes to hosts or routers.
The definition of terms used in this document may be found in "IP
Network Address Translator Terminology and Considerations" [REF1].
2. Overview of traditional NAT
The Address Translation operation presented in this document is
referred to as "Traditional NAT". There are other variations of
NAT that will not be explored in this document. Traditional NAT
would allow hosts within a private network to transparently
access hosts in the external network, in most cases. In a
traditional NAT, sessions are uni-directional, outbound from the
private network. Sessions in the opposite direction may be allowed
on an exceptional basis using static address maps for pre-selected
hosts. Basic NAT and NAPT are two variations of traditional NAT,
in that translation is Basic NAT is limited to IP addresses alone,
whereas translation in NAPT is extended to include IP address and
Transport identifier (such as TCP/UDP port or ICMP query ID).
Unless mentioned otherwise, Address Translation or NAT throughout
this document will pertain to traditional NAT, namely Basic NAT
as well as NAPT. Only the stub border routers as described in
figure 1 below may be configured to perform address translation.
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub border
Srisuresh & Egevang [Page 3]
Internet-Draft Traditional NAT April 2000
Figure 1: Traditional NAT Configuration
2.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 a global address to map to. Otherwise, nodes allowed to
have simultaneous access to external network are limited by the
number of addresses in global set. Individual local addresses may
be statically mapped to specific global addresses to ensure
guaranteed access to the outside or to allow access to the local
host from external hosts. Multiple simultaneous 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.
\ | /
+---------------+
|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
Srisuresh & Egevang [Page 4]
Internet-Draft Traditional NAT April 2000
Figure 2: Basic NAT Operation
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.
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 transparent to end hosts. Of course, this is just a simple
example. There are numerous issues to be explored.
2.2. Overview of NAPT
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.
Srisuresh & Egevang [Page 5]
Internet-Draft Traditional NAT April 2000
\ | /
+-----------------------+
|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
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 this 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
an 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.
Srisuresh & Egevang [Page 6]
Internet-Draft Traditional NAT April 2000
In addition to TCP/UDP sessions, ICMP messages, with the exception
of REDIRECT message type may also be monitored by NAPT router.
ICMP query type packets are translated similar to that of TCP/UDP
packets, in that the identifier field in ICMP message header will
be uniquely mapped to a query identifier of the registered IP
address. The identifier field in ICMP query messages is set by
Query sender and returned unchanged in response message from the
Query responder. So, the tuple of (Local IP address, local ICMP
query identifier) is mapped to a tuple of (registered IP address,
assigned ICMP query Identifier) by the NAPT router to uniquely
identify ICMP queries of all types from any of the local hosts.
Modifications to ICMP error messages are discussed in a later
section, as that involves modifications to ICMP payload as well
as the IP and ICMP headers.
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 TCP, UDP or ICMP query sessions
originated from itself versus those originated from the nodes on
local network. All inbound sessions (including TCP, UDP and ICMP
query 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.
Sessions other than TCP, UDP and ICMP query type are simply not
permitted from local nodes, serviced by a NAPT router.
3.0. Translation phases of a session.
The translation phases with traditional NAT are same as described in
[REF1]. The following sub-sections identify items that are specific
to traditional NAT.
3.1. Address binding:
With Basic NAT, a private address is bound to an external address,
when the first outgoing session is initiated from the private host.
Subsequent to that, all other outgoing sessions originating
from the same private address will use the same address binding for
packet translation.
In the case of NAPT, where many private addresses are mapped to a
single globally unique address, the binding would be from the
tuple of (private address, private TU port) to the tuple of
(assigned address, assigned TU port). As with Basic NAT, this
binding is determined when the first outgoing session is initiated
by the tuple of (private address, private TU port) on the private
Srisuresh & Egevang [Page 7]
Internet-Draft Traditional NAT April 2000
host. While not a common practice, it is possible to have an
application on private host establish multiple simultaneous
sessions originating from the same tuple of (private address,
private TU port). In such a case, a single binding for the tuple
of (private address, private TU port) may be used for translation
of packets pertaining to all sessions originating from the same
tuple on a host.
3.2. Address lookup and translation:
After an address binding or (address, TU port) tuple binding in
case of NAPT is established, a soft state may be maintained for
each of the connections using the binding. Packets belonging to
the same session will be subject to session lookup for translation
purposes. The exact nature of translation is discussed in the
follow-on section.
3.3. Address unbinding:
When the last session based on an address or (address, TU port)
tuple binding is terminated, the binding itself may be terminated.
4.0. Packet Translations
Packets pertaining to NAT managed sessions undergo translation
in either direction. Individual packet translation issues are
covered in detail in the following sub-sections.
4.1. IP, TCP, UDP and ICMP 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
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. As for ICMP Query
packets, no further changes in ICMP header are required as
the checksum in ICMP header does not cover IP addresses.
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
Srisuresh & Egevang [Page 8]
Internet-Draft Traditional NAT April 2000
packets and destination TU port for inbound packets) in the
TCP/UDP header. ICMP header in ICMP Query packets must also
be modified to replace the query ID and ICMP header checksum.
Private host query ID must be translated into assigned ID on
the outbound and the exact reverse on the inbound. ICMP header
checksum must be corrected to account for Query ID translation.
4.2. Checksum Adjustment
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 below 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.
Srisuresh & Egevang [Page 9]
Internet-Draft Traditional NAT April 2000
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;
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;
}
4.3. ICMP error packet modifications
Changes to ICMP error message will include changes to IP and
ICMP headers on the outer layer as well as changes to headers
of the packet embedded within the ICMP-error message payload.
In order for NAT to be transparent to end-host, the IP address
of the IP header embedded within the payload of ICMP-Error
message must be modified, the checksum field of the embedded
IP header must be modified, and lastly, the ICMP header
checksum must also be modified to reflect changes to payload.
In a NAPT setup, if the IP message embedded within ICMP happens
to be a TCP, UDP or ICMP Query packet, you will also need to
modify the appropriate TU port number within the TCP/UDP header
or the Query Identifier field in the ICMP Query header.
Lastly, the IP header of the ICMP packet must also be modified.
Srisuresh & Egevang [Page 10]
Internet-Draft Traditional NAT April 2000
4.4. FTP support
As noted in [REF1], one of the most popular applications,
"FTP" would require an ALG to monitor the control session
payload to determine the ensuing data session parameters.
FTP ALG is an integral part of most NAT implementations.
The FTP ALG would require a special table to correct the TCP
sequence and acknowledge numbers with source port FTP or
destination port FTP. The table entries should have source
address, destination address, 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
on the outbound and acknowledge numbers are decremented on the
inbound by this delta.
FTP payload translations are limited to private addresses and
their assigned external addresses (encoded as individual octets
in ASCII) for Basic NAT. For NAPT setup, however, the translations
must be extended to include the TCP port octets (in ASCII)
following the address octets.
4.5 DNS support
Considering that sessions in a traditional NAT are predominantly
outbound from a private domain, DNS ALG may be obviated from use in
conjunction with traditional NAT as follows. DNS server(s) internal
to the private domain maintain mapping of names to IP addresses for
internal hosts and possibly some external hosts. External DNS
servers maintain name mapping for external hosts alone and not for
any of the internal hosts. If the private network does not have an
internal DNS server, all DNS requests may be directed to external
DNS server to find address mapping for the external hosts.
4.6. IP option handling
An IP datagram with any of the IP options Record Route, Strict
Source Route or Loose Source Route would involve recording or
using IP addresses of intermediate routers. A NAT intermediate
router may choose not to support these options or leave
the addresses untranslated while processing the options. The
result of leaving the addresses untranslated would be that
private addresses along the source route are exposed end to
end. This should not jeopardize the traversal path of the
packet, per se, as each router is supposed to look at the
Srisuresh & Egevang [Page 11]
Internet-Draft Traditional NAT April 2000
next hop router only.
5. Miscellaneous issues
5.1. Partitioning of Local and Global Addresses
For NAT to operate as described in this draft, it is necessary
to partition the IP address space into two parts - the private
addresses used internal to stub domain, and the globally
unique addresses. Any given address must either be a private
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 private 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 private
addresses.
5.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.
5.3. Routing Across NAT
The router running NAT should not advertise the private 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.
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
Srisuresh & Egevang [Page 12]
Internet-Draft Traditional NAT April 2000
IP address fall within the range of NAT managed global address list)
to NAT router over WAN link.
5.4. Switch-over from Basic NAT to NAPT
In Basic NAT setup, when private network nodes outnumber global
addresses available for mapping (say, a class B private 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 ensure that hosts on private
network will have continued, uninterrupted access to the
external nodes and services for most applications. Note,
however, it could be confusing if some of the applications that
used to work with Basic NAT suddenly break due to the
switch-over to NAPT.
6.0. NAT limitations
[REF1] covers the limitations of all flavors of NAT, broadly
speaking. The following sub-sections identify limitations
specific to traditional NAT.
6.1. Privacy and Security
Traditional NAT can be viewed as providing a privacy mechanism
as sessions are uni-directional from private hosts and
the actual addresses of the private hosts are not visible to
external hosts.
The same characteristic that enhances privacy potentially makes
debugging problems (including security violations) more difficult.
If a host in private network is abusing the Internet in some way
(such as trying to attack another machine or even sending large
amounts of spam) it is more difficult to track the actual source
of trouble because the IP address of the host is hidden in a
NAT router.
6.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
Srisuresh & Egevang [Page 13]
Internet-Draft Traditional NAT April 2000
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 5.4 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.
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.
6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup
Translation of outbound TCP/UDP fragments (i.e., those originating
from private hosts) in NAPT setup are doomed to fail. The reason is
as follows. Only the first fragment contains the TCP/UDP header that
would be necessary to associate the packet to a session for
translation purposes. Subsequent fragments do not contain TCP/UDP
port information, but simply carry the same fragmentation identifier
specified in the first fragment. Say, two private hosts originated
fragmented TCP/UDP packets to the same destination host. And, they
happened to use the same fragmentation identifier. When the
target host receives the two unrelated datagrams, carrying same
fragmentation id, and from the same assigned host address, it
is unable to determine which of the two sessions the datagrams
belong to. Consequently, both sessions will be corrupted.
7.0. Current Implementations
Many commercial implementations are available in the industry that
adhere to the NAT description provided in this document. Linux
public domain software contains NAT under the name of "IP
masquerade". FreeBSD public domain software has NAPT implementation
running as a daemon. Note however that Linux source is covered
Srisuresh & Egevang [Page 14]
Internet-Draft Traditional NAT April 2000
under the GNU license and FreeBSD software is covered under the
UC Berkeley license.
Both Linux and FreeBSD software are free, so you can buy CD-ROMs
for these for little more than the cost of distribution. They are
also available on-line from a lot of FTP sites with the latest
patches.
8.0. Security Considerations
The security considerations described in [REF1] for all variations
of NATs are applicable to traditional NAT.
REFERENCES
[1] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT)
Terminology and Considerations", RFC 2663
[2] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and,
Lear, E. "Address Allocation for Private Internets", RFC 1918
[3] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700
[4] R. Braden, "Requirements for Internet Hosts -- Communication
Layers", RFC 1122
[5] R. Braden, "Requirements for Internet Hosts -- Application
and Support", RFC 1123
[6] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812
[7] J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)",
RFC 959
[8] "TRANSMISSION CONTROL PROTOCOL (TCP) SPECIFICATION", RFC 793
[9] J. Postel, "INTERNET CONTROL MESSAGE (ICMP) SPECIFICATION",
RFC 792
[10] J. Postel, "User Datagram Protocol (UDP)", RFC 768
[11] J. Mogul, J. Postel, "Internet Standard Subnetting Procedure",
RFC 950
[12] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address
Behaviour Today", RFC 2101
Srisuresh & Egevang [Page 15]
Internet-Draft Traditional NAT April 2000
Authors' Addresses
Pyda Srisuresh
Campio Communications
630 Alder Drive
Milpitas, CA 95035
U.S.A.
Voice: (408) 519-3849
EMail: srisuresh@yahoo.com
Kjeld Borch Egevang
Intel Denmark ApS
Voice: +45 44886556
Fax: +45 44886051
EMail: kjeld.egevang@intel.com
http: //www.freeyellow.com/members/kbe
Srisuresh & Egevang [Page 16]