doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc3022.txt b/doc/rfc/rfc3022.txt
new file mode 100644
index 0000000..0af1c1f
--- /dev/null
+++ b/doc/rfc/rfc3022.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                       P. Srisuresh
+Request for Comments: 3022                              Jasmine Networks
+Obsoletes: 1631                                               K. Egevang
+Category: Informational                                Intel Corporation
+                                                            January 2001
+
+
+      Traditional IP Network Address Translator (Traditional NAT)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+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
+   which many network addresses and their TCP/UDP (Transmission Control
+   Protocol/User Datagram Protocol) 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
+
+
+
+Srisuresh & Egevang          Informational                      [Page 1]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+   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
+   [NAT-TERM] 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.  When one of the NAT
+   routers fail, the other could route traffic for all the connections.
+   There is however a caveat with this approach, in that, rerouted flows
+   could fail at the time of switchover to the new NAT router.  A way to
+   overcome this potential problem is that the routers share the same
+   NAT configuration and exchange state information to ensure a fail-
+   safe backup for each other.
+
+   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 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
+
+
+
+Srisuresh & Egevang          Informational                      [Page 2]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+   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.
+
+   Definition of terms such as "Address Realm", "Transparent Routing",
+   "TU Ports", "ALG" and others, used throughout the document, may be
+   found in [NAT-TERM].
+
+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 in 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
+
+            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 the set of private addresses
+   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
+
+
+
+Srisuresh & Egevang          Informational                      [Page 3]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+   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 via a fixed public address.  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.
+
+   For instance, in the example of figure 2, both stubs A and B
+   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 block
+   198.76.28.0/24.  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
+
+
+
+
+
+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 host
+   10.81.13.22, it uses the globally unique address 198.76.28.4 as
+   destination, and sends the packet to its 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 in most cases.  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 the 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 block 10.0.0.0/8.  The stub router's WAN interface is
+   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|
+                         +------------------+
+                           |
+                           |  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 the subnet 138.76.0.0/16 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 well known TU port service [RFC 1700] on
+   the stub router to be directed to a specific node in the private
+   network.
+
+
+
+
+
+Srisuresh & Egevang          Informational                      [Page 6]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+   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
+   [NAT-TERM].  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 host.  While not
+   a common practice, it is possible to have an application on private
+   host establish multiple simultaneous sessions originating from the
+
+
+
+Srisuresh & Egevang          Informational                      [Page 7]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+   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 ([TCP]) and UDP ([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 ([ICMP]),
+   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 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
+
+
+
+
+
+Srisuresh & Egevang          Informational                      [Page 8]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+   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.
+
+   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;
+   }
+
+
+
+
+
+Srisuresh & Egevang          Informational                      [Page 9]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+4.3. ICMP error packet modifications
+
+   Changes to ICMP error message ([ICMP]) 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.
+
+4.4. FTP support
+
+   One of the most popular applications, "FTP" ([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
+
+
+
+Srisuresh & Egevang          Informational                     [Page 10]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+   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 next hop router only.
+
+5. Miscellaneous issues
+
+5.1. Partitioning of Local and Global Addresses
+
+   For NAT to operate as described in this document, 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
+
+   [RFC 1918] 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
+
+
+
+
+Srisuresh & Egevang          Informational                     [Page 11]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+   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 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
+
+   [NAT-TERM] 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
+
+
+
+Srisuresh & Egevang          Informational                     [Page 12]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+   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 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.
+
+
+
+Srisuresh & Egevang          Informational                     [Page 13]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+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 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 [NAT-TERM] for all
+   variations of NATs are applicable to traditional NAT.
+
+References
+
+   [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
+              Translator (NAT) Terminology and Considerations", RFC
+              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, RFC
+              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",  RFC
+              1812, June 1995.
+
+   [FTP]      Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL
+              (FTP)", STD 9, RFC 959, October 1985.
+
+   [TCP]      Defense Advanced Research Projects Agency Information
+              Processing Techniques Office, "TRANSMISSION CONTROL
+              PROTOCOL (TCP) SPECIFICATION", STD 7, RFC 793, September
+              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, RFC
+              768, August 1980.
+
+   [RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
+              Behaviour Today", RFC 2101, February 1997.
+
+Authors' Addresses
+
+   Pyda Srisuresh
+   Jasmine Networks, Inc.
+   3061 Zanker Road, Suite B
+   San Jose, CA 95134
+   U.S.A.
+
+   Phone: (408) 895-5032
+   EMail: srisuresh@yahoo.com
+
+
+   Kjeld Borch Egevang
+   Intel Denmark ApS
+
+   Phone: +45 44886556
+   Fax:   +45 44886051
+   EMail: kjeld.egevang@intel.com
+   http:  //www.freeyellow.com/members/kbe
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Srisuresh & Egevang          Informational                     [Page 15]
+
+RFC 3022                    Traditional NAT                 January 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Srisuresh & Egevang          Informational                     [Page 16]
+