As per Relevance of the word traditional, we have this rfc below:
Network Working Group P.
Request for Comments: 3022 Jasmine
Obsoletes: 1631 K.
Category: Informational Intel
January 2001
Traditional IP Network Address Translator (Traditional NAT
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
The NAT operation described in this document extends
translation introduced in RFC 1631 and includes a new type of
address and TCP/UDP port translation. In addition, this
corrects the Checksum adjustment algorithm published in RFC 1631
attempts to discuss NAT operation and limitations in detail
Basic Network Address Translation or Basic NAT is a method by
IP addresses are mapped from one group to another, transparent to
users. Network Address Port Translation, or NAPT is a method
which many network addresses and their TCP/UDP (Transmission
Protocol/User Datagram Protocol) ports are translated into a
network address and its TCP/UDP ports. Together, these
operations, referred to as traditional NAT, provide a mechanism
connect a realm with private addresses to an external realm
globally unique registered addresses
1.
The need for IP Address translation arises when a network's
IP addresses cannot be used outside the network either for
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
Srisuresh & Egevang Informational [Page 1]
RFC 3022 Traditional NAT January 2001
with time, address assignment for nodes within the local domain
also change to reflect the external changes. Changes of this
can be hidden from users within the domain by centralizing changes
a single address translation router
Basic Address translation would (in many cases, except as noted
[NAT-TERM] and section 6 of this document) allow hosts in a
network to transparently access the external network and
access to selective local hosts from the outside. Organizations
a network setup predominantly for internal use, with a need
occasional external access are good candidates for this scheme
Many Small Office, Home Office (SOHO) users and
employees have multiple Network nodes in their office,
TCP/UDP applications, but have a single IP address assigned to
remote access router by their service provider to access
networks. This ever increasing community of remote access
would be benefited by NAPT, which would permit multiple nodes in
local network to simultaneously access remote networks using
single IP address assigned to their router
There are limitations to using the translation method. It
mandatory that all requests and responses pertaining to a session
routed via the same NAT router. One way to ascertain this would
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
destined to the domain. There are other ways to ensure this
multiple NAT devices. For example, a private domain could have
distinct exit points to different providers and the session flow
the hosts in a private network could traverse through whichever
device has the best metric for an external host. When one of the
routers fail, the other could route traffic for all the connections
There is however a caveat with this approach, in that, rerouted
could fail at the time of switchover to the new NAT router. A way
overcome this potential problem is that the routers share the
NAT configuration and exchange state information to ensure a fail
safe backup for each other
Address translation is application independent and often
by application specific gateways (ALGs) to perform payload
and alterations. FTP is the most popular ALG resident on
devices. Applications requiring ALG intervention must not have
payload encoded, as doing that would effectively disables the ALG
unless the ALG has the key to decrypt the payload
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. As a result, end-to-end IP network
Srisuresh & Egevang Informational [Page 2]
RFC 3022 Traditional NAT January 2001
security assured by IPSec cannot be assumed to end hosts, with a
device enroute. The advantage of this approach however is that
can be installed without changes to hosts or routers
Definition of terms such as "Address Realm", "Transparent Routing",
"TU Ports", "ALG" and others, used throughout the document, may
found in [NAT-TERM].
2. Overview of traditional
The Address Translation operation presented in this document
referred to as "Traditional NAT". There are other variations of
that will not be explored in this document. Traditional NAT
allow hosts within a private network to transparently access hosts
the external network, in most cases. In a traditional NAT,
are uni-directional, outbound from the private network. Sessions
the opposite direction may be allowed on an exceptional basis
static address maps for pre-selected hosts. Basic NAT and NAPT
two variations of traditional NAT, in that translation in Basic
is limited to IP addresses alone, whereas translation in NAPT
extended to include IP address and Transport identifier (such
TCP/UDP port or ICMP query ID).
Unless mentioned otherwise, Address Translation or NAT
this document will pertain to traditional NAT, namely Basic NAT
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|---
+---------------+ . +-----------------+\
. | \
. |
. ---------------
Stub
Figure 1: Traditional NAT
2.1 Overview of Basic
Basic NAT operation is as follows. A stub domain with a set
private network addresses could be enabled to communicate
external network by dynamically mapping the set of private
to a set of globally valid network addresses. If the number of
nodes are less than or equal to addresses in the global set,
local address is guaranteed a global address to map to. Otherwise
nodes allowed to have simultaneous access to external network
Srisuresh & Egevang Informational [Page 3]
RFC 3022 Traditional NAT January 2001
limited by the number of addresses in global set. Individual
addresses may be statically mapped to specific global addresses
ensure guaranteed access to the outside or to allow access to
local host from external hosts via a fixed public address.
simultaneous sessions may be initiated from a local node, using
same address mapping
Addresses inside a stub domain are local to that domain and not
outside the domain. Thus, addresses inside a stub domain can
reused by any other stub domain. For instance, a single Class
address could be used by many stub domains. At each exit
between a stub domain and backbone, NAT is installed. If there
more than one exit point it is of great importance that each NAT
the same translation table
For instance, in the example of figure 2, both stubs A and
internally use class A private address block 10.0.0.0/8 [RFC 1918].
Stub A's NAT is assigned the class C address block 198.76.29.0/24,
and Stub B's NAT is assigned the class C address
198.76.28.0/24. The class C addresses are globally unique no
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
Srisuresh & Egevang Informational [Page 4]
RFC 3022 Traditional NAT January 2001
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 its 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
address 10.33.96.5 of the IP header to the globally
198.76.29.7 before the packet is forwarded. Likewise, IP packets
the return 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
transparent to end hosts in most cases. Of course, this is just
simple example. There are numerous issues to be explored
2.2. Overview of
Say, an organization has a private IP network and a WAN link to
service provider. The private network's stub router is assigned
globally valid address on the WAN link and the remaining nodes in
organization have IP addresses that have only local significance.
such a case, nodes on the private network could be
simultaneous access to the external network, using the
registered IP address with the aid of NAPT. NAPT would allow
of tuples of the type (local IP addresses, local TU port number)
tuples of the type (registered IP address, assigned TU port number).
This model fits the requirements of most Small Office Home
(SOHO) groups to access external network using a single
provider assigned IP address. This model could be extended to
inbound access by statically mapping a local node per each service
port of the registered IP address
In the example of figure 3 below, stub A internally uses class
address block 10.0.0.0/8. The stub router's WAN interface
assigned an IP address 138.76.28.4 by the service provider
Srisuresh & Egevang Informational [Page 5]
RFC 3022 Traditional NAT January 2001
\ | /
+-----------------------+
|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
+------------------+
|
|
--------------------------------------------
| ^{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)
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,
sends the packet to it's primary router. The stub router has
static route for the subnet 138.76.0.0/16 so the packet is
to the WAN-link. However, NAPT translates the tuple of
address 10.0.0.10 and source TCP port 3017 in the IP and TCP
into the globally unique 138.76.28.4 and a uniquely assigned
port, say 1024, before the packet is forwarded. Packets on
return path go through similar address and TCP port translations
the target IP address and target TCP port. Once again, notice
this requires no changes to hosts or routers. The translation
completely transparent
In this setup, only TCP/UDP sessions are allowed and must
from the local network. However, there are services such as DNS
demand inbound access. There may be other services for which
organization wishes to allow inbound session access. It is
to statically configure a well known TU port service [RFC 1700]
the stub router to be directed to a specific node in the
network
Srisuresh & Egevang Informational [Page 6]
RFC 3022 Traditional NAT January 2001
In addition to TCP/UDP sessions, ICMP messages, with the exception
REDIRECT message type may also be monitored by NAPT router.
query type packets are translated similar to that of TCP/UDP packets
in that the identifier field in ICMP message header will be
mapped to a query identifier of the registered IP address.
identifier field in ICMP query messages is set by Query sender
returned unchanged in response message from the Query responder. So
the tuple of (Local IP address, local ICMP query identifier)
mapped to a tuple of (registered IP address, assigned ICMP
Identifier) by the NAPT router to uniquely identify ICMP queries
all types from any of the local hosts. Modifications to ICMP
messages are discussed in a later section, as that
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
address of the stub router WAN interface, the router has to be
to make distinction between TCP, UDP or ICMP query
originated from itself versus those originated from the nodes
local network. All inbound sessions (including TCP, UDP and
query sessions) are assumed to be directed to the NAT router as
end node, unless the target service port is statically mapped to
different node in the local network
Sessions other than TCP, UDP and ICMP query type are simply
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
[NAT-TERM]. The following sub-sections identify items that
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
same private address will use the same address binding for
translation
In the case of NAPT, where many private addresses are mapped to
single globally unique address, the binding would be from the
of (private address, private TU port) to the tuple of (
address, assigned TU port). As with Basic NAT, this binding
determined when the first outgoing session is initiated by the
of (private address, private TU port) on the private host. While
a common practice, it is possible to have an application on
host establish multiple simultaneous sessions originating from
Srisuresh & Egevang Informational [Page 7]
RFC 3022 Traditional NAT January 2001
same tuple of (private address, private TU port). In such a case,
single binding for the tuple of (private address, private TU port
may be used for translation of packets pertaining to all
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
of NAPT is established, a soft state may be maintained for each
the connections using the binding. Packets belonging to the
session will be subject to session lookup for translation purposes
The exact nature of translation is discussed in the follow-
section
3.3. Address unbinding
When the last session based on an address or (address, TU port)
binding is terminated, the binding itself may be terminated
4.0. Packet
Packets pertaining to NAT managed sessions undergo translation
either direction. Individual packet translation issues are
in detail in the following sub-sections
4.1. IP, TCP, UDP and ICMP Header
In Basic NAT model, the IP header of every packet must be modified
This modification includes IP address (source IP address for
packets and destination IP address for inbound packets) and the
checksum
For TCP ([TCP]) and UDP ([UDP]) sessions, modifications must
update of checksum in the TCP/UDP headers. This is because TCP/
checksum also covers a pseudo header which contains the source
destination IP addresses. As an exception, UDP headers with 0
checksum should not be modified. As for ICMP Query packets ([ICMP]),
no further changes in ICMP header are required as the checksum
ICMP header does not cover IP addresses
In NAPT model, modifications to IP header are similar to that
Basic NAT. For TCP/UDP sessions, modifications must be extended
include translation of TU port (source TU port for outbound
and destination TU port for inbound packets) in the TCP/UDP header
ICMP header in ICMP Query packets must also be modified to
the query ID and ICMP header checksum. Private host query ID must
Srisuresh & Egevang Informational [Page 8]
RFC 3022 Traditional NAT January 2001
translated into assigned ID on the outbound and the exact reverse
the inbound. ICMP header checksum must be corrected to account
Query ID translation
4.2. Checksum
NAT modifications are per packet based and can be very
intensive, as they involve one or more checksum modifications
addition to simple field translations. Luckily, we have an
below, which makes checksum adjustment to IP, TCP, UDP and
headers very simple and efficient. Since all these headers use
one's complement sum, it is sufficient to calculate the
difference between the before-translation and after-
addresses and add this to the checksum. The algorithm below
applicable only for even offsets (i.e., optr below must be at an
offset from start of header) and even lengths (i.e., olen and
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
- 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 & 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
}
Srisuresh & Egevang Informational [Page 9]
RFC 3022 Traditional NAT January 2001
4.3. ICMP error packet
Changes to ICMP error message ([ICMP]) will include changes to IP
ICMP headers on the outer layer as well as changes to headers of
packet embedded within the ICMP-error message payload
In order for NAT to be transparent to end-host, the IP address of
IP header embedded within the payload of ICMP-Error message must
modified, the checksum field of the embedded IP header must
modified, and lastly, the ICMP header checksum must also be
to reflect changes to payload
In a NAPT setup, if the IP message embedded within ICMP happens to
a TCP, UDP or ICMP Query packet, you will also need to modify
appropriate TU port number within the TCP/UDP header or the
Identifier field in the ICMP Query header
Lastly, the IP header of the ICMP packet must also be modified
4.4. FTP
One of the most popular applications, "FTP" ([FTP]) would require
ALG to monitor the control session payload to determine the
data session parameters. FTP ALG is an integral part of most
implementations
The FTP ALG would require a special table to correct the TCP
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
timestamp. New entries are created only when FTP PORT commands
PASV responses are seen. The sequence number delta may be
or decreased for every FTP PORT command or PASV response.
numbers are incremented on the outbound and acknowledge numbers
decremented on the inbound by this delta
FTP payload translations are limited to private addresses and
assigned external addresses (encoded as individual octets in ASCII
for Basic NAT. For NAPT setup, however, the translations must
extended to include the TCP port octets (in ASCII) following
address octets
4.5 DNS
Considering that sessions in a traditional NAT are
outbound from a private domain, DNS ALG may be obviated from use
conjunction with traditional NAT as follows. DNS server(s)
to the private domain maintain mapping of names to IP addresses
Srisuresh & Egevang Informational [Page 10]
RFC 3022 Traditional NAT January 2001
internal hosts and possibly some external hosts. External
servers maintain name mapping for external hosts alone and not
any of the internal hosts. If the private network does not have
internal DNS server, all DNS requests may be directed to external
server to find address mapping for the external hosts
4.6. IP option
An IP datagram with any of the IP options Record Route, Strict
Route or Loose Source Route would involve recording or using
addresses of intermediate routers. A NAT intermediate router
choose not to support these options or leave the
untranslated while processing the options. The result of leaving
addresses untranslated would be that private addresses along
source route are exposed end to end. This should not jeopardize
traversal path of the packet, per se, as each router is supposed
look at the next hop router only
5. Miscellaneous
5.1. Partitioning of Local and Global
For NAT to operate as described in this document, it is necessary
partition the IP address space into two parts - the private
used internal to stub domain, and the globally unique addresses.
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
wished to send packets to a host in stub B, but the global
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
address of stub B from its own private addresses
5.2. Private address space
[RFC 1918] has recommendations on address space allocation
private networks. Internet Assigned Numbers Authority (IANA)
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,
first block is nothing but a single class A network number, while
second block is a set of 16 contiguous class B networks, and
third block is a set of 256 contiguous class C networks
An organization that decides to use IP addresses in the address
defined above can do so without any coordination with IANA or
Internet registry. The address space can thus be used privately
Srisuresh & Egevang Informational [Page 11]
RFC 3022 Traditional NAT January 2001
many independent organizations at the same time, with NAT
enabled on their border routers
5.3. Routing Across
The router running NAT should not advertise the private 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
Typically, the NAT stub router will have a static route configured
forward all external traffic to service provider router over
link, and the service provider router will have a static
configured to forward NAT packets (i.e., those whose destination
address fall within the range of NAT managed global address list)
NAT router over WAN link
5.4. Switch-over from Basic NAT to
In Basic NAT setup, when private network nodes outnumber
addresses available for mapping (say, a class B private
mapped to a class C global address block), external network access
some of the local nodes is abruptly cut off after the last
address from the address list is used up. This is very
and constraining. Such an incident can be safely avoided
optionally allowing the Basic NAT router to switch over to NAPT
for the last global address in the address list. Doing this
ensure that hosts on private network will have continued
uninterrupted access to the external nodes and services for
applications. Note, however, it could be confusing if some of
applications that used to work with Basic NAT suddenly break due
the switch-over to NAPT
6.0. NAT
[NAT-TERM] covers the limitations of all flavors of NAT,
speaking. The following sub-sections identify limitations
to traditional NAT
6.1. Privacy and
Traditional NAT can be viewed as providing a privacy mechanism
sessions are uni-directional from private hosts and the
addresses of the private hosts are not visible to external hosts
The same characteristic that enhances privacy potentially
debugging problems (including security violations) more difficult.
a host in private network is abusing the Internet in some way (
Srisuresh & Egevang Informational [Page 12]
RFC 3022 Traditional NAT January 2001
as trying to attack another machine or even sending large amounts
spam) it is more difficult to track the actual source of
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
NAT must be enabled only on border routers of a stub domain.
examples provided in the document to illustrate Basic NAT and
have maintained a WAN link for connection to external router (i.e.,
service provider router) from NAT router. However, if the WAN
were to be replaced by a LAN connection and if part or all of
global address space used for NAT mapping belongs to the same
subnet as the LAN segment, the NAT router would be expected
provide ARP support for the address range that belongs to the
subnet. Responding to ARP requests for the NAT mapped
addresses with its own MAC address is a must in such a situation
Basic NAT setup. If the NAT router did not respond to
requests, there is no other node in the network that has ownership
these addresses and hence will go unresponded
This scenario is unlikely with NAPT setup except when the
address used in NAPT mapping is not the interface address of the
router (as in the case of a switch-over from Basic NAT to
explained in 5.4 above, for example).
Using an address range from a directly connected subnet for
address mapping would obviate static route configuration on
service provider router
It is the opinion of the authors that a LAN link to a
provider router is not very common. However, vendors may
interested to optionally support proxy ARP just in case
6.3. Translation of outbound TCP/UDP fragmented packets in NAPT
Translation of outbound TCP/UDP fragments (i.e., those
from private hosts) in NAPT setup are doomed to fail. The reason
as follows. Only the first fragment contains the TCP/UDP header
would be necessary to associate the packet to a session
translation purposes. Subsequent fragments do not contain TCP/
port information, but simply carry the same fragmentation
specified in the first fragment. Say, two private hosts
fragmented TCP/UDP packets to the same destination host. And,
happened to use the same fragmentation identifier. When the
host receives the two unrelated datagrams, carrying
fragmentation id, and from the same assigned host address, it
unable to determine which of the two sessions the datagrams
to. Consequently, both sessions will be corrupted
Srisuresh & Egevang Informational [Page 13]
RFC 3022 Traditional NAT January 2001
7.0. Current
Many commercial implementations are available in the industry
adhere to the NAT description provided in this document.
public domain software contains NAT under the name of "
masquerade". FreeBSD public domain software has NAPT
running as a daemon. Note however that Linux source is covered
the GNU license and FreeBSD software is covered under the
Berkeley license
Both Linux and FreeBSD software are free, so you can buy CD-ROMs
these for little more than the cost of distribution. They are
available on-line from a lot of FTP sites with the latest patches
8.0. Security
The security considerations described in [NAT-TERM] for
variations of NATs are applicable to traditional NAT
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network
Translator (NAT) Terminology and Considerations",
2663, August 1999.
[RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
1700, October 1994.
[RFC 1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers",
1812, June 1995.
[FTP] Postel, J. and J. Reynolds, "FILE TRANSFER
(FTP)", STD 9, RFC 959, October 1985.
[TCP] Defense Advanced Research Projects Agency
Processing Techniques Office, "TRANSMISSION
PROTOCOL (TCP) SPECIFICATION", STD 7, RFC 793,
1981.
Srisuresh & Egevang Informational [Page 14]
RFC 3022 Traditional NAT January 2001
[ICMP] Postel, J., "INTERNET CONTROL MESSAGE (ICMP
SPECIFICATION", STD 5, RFC 792, September 1981.
[UDP] Postel, J., "User Datagram Protocol (UDP)", STD 6,
768, August 1980.
[RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4
Behaviour Today", RFC 2101, February 1997.
Authors'
Pyda
Jasmine Networks, Inc
3061 Zanker Road, Suite
San Jose, CA 95134
U.S.A
Phone: (408) 895-5032
EMail: srisuresh@yahoo.
Kjeld Borch
Intel Denmark
Phone: +45 44886556
Fax: +45 44886051
EMail: kjeld.egevang@intel.
http: //www.freeyellow.com/members/
Srisuresh & Egevang Informational [Page 15]
RFC 3022 Traditional NAT January 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Srisuresh & Egevang Informational [Page 16]
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
