rfc3022.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

                           |  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.