rfc2766.txt

RFC 的详细文档！

   the v6 domain contains the mapping for external V4 nodes, the DNS
   queries will not cross the V6 domain and that would obviate the need
   for DNS-ALG intervention. Otherwise, the queries will cross the V6
   domain and are subject to DNS-ALG intervention.  We recommend
   external DNS servers in the V4 domain cache name mapping for external
   nodes (i.e., V4 nodes) only. Zone transfers across IPv4 - IPv6
   boundaries are strongly discouraged.

   In the case of NAPT-PT, a TCP/UDP source port is assigned from the
   registered V4 address upon detection of each new outbound session.

   We saw that a V6 node that needs to communicate with a V4 node needs
   to use a specific prefix (PREFIX::/96) in front of the IPv4 address
   of the V4 node. The above technique allows the use of this PREFIX
   without any configuration in the nodes.

   To create another example from Figure 2 say Node-A wants to set up a
   session with Node-C. For this Node-A starts by making a name look-up
   ("AAAA" or "A6" record) for Node-C.

   Since Node-C may have IPv6 and/or IPv4 addresses, the DNS-ALG on the
   NAT-PT device forwards the original AAAA/A6 query to the external DNS
   system unchanged, as well as an A query for the same node. If an
   AAAA/A6 record exists for the destination, this will be returned to



Tsirtsis & Srisuresh        Standards Track                    [Page 11]

RFC 2766                         NAT-PT                    February 2000


   NAT-PT which will forward it, also unchanged, to the originating
   host.

   If there is an A record for Node-C the reply also returns to the
   NAT-PT. The DNS-ALG then, translates the reply adding the appropriate
   PREFIX and forwards it to the originating device with any IPv6
   addresses that might have learned. So, if the reply is

      NodeC    A     132.146.243.30, it is translated to
      NodeC   AAAA   PREFIX::132.146.243.30 or to
      NodeC    A6    PREFIX::132.146.243.30

   Now Node A can use this address like any other IPv6 address and the
   V6 DNS server can even cache it as long as the PREFIX does not
   change.

   An issue here is how the V6 DNS server in the V6 stub domain talks to
   the V4 domain outside the V6 stub domain. Remember that there are no
   dual stack nodes here. The external V4 DNS server needs to point to a
   V4 address, part of the V4 pool of addresses, available to NAT-PT.
   NAT-PT keeps a one-to-one mapping between this V4 address and the V6
   address of the internal V6 DNS server. In the other direction, the V6
   DNS server points to a V6 address formed by the IPv4 address of the
   external V4 DNS servers and the prefix (PREFIX::/96) that indicates
   non IPv6 nodes.  This mechanism can easily be extended to accommodate
   secondary DNS servers.

   Note that the scheme described in this section impacts DNSSEC. See
   section 7.5 of this document for details.

5. Protocol Translation Details

   The IPv4 and ICMPv4 headers are similar to their V6 counterparts but
   a number of field are either missing, have different meaning or
   different length. NAT-PT SHOULD translate all IP/ICMP headers from v4
   to v6 and vice versa in order to make end-to-end IPv6 to IPv4
   communication possible. Due to the address translation function and
   possible port multiplexing, NAT-PT SHOULD also make appropriate
   adjustments to the upper layer protocol (TCP/UDP) headers. A separate
   section on FTP-ALG describes the changes FTP-ALG would make to FTP
   payload as an FTP packet traverses from V4 to V6 realm or vice versa.

   Protocol Translation details are described in [SIIT], but there are
   some modifications required to SIIT because of the fact that NAT-PT
   also performs Network Address Translation.






Tsirtsis & Srisuresh        Standards Track                    [Page 12]

RFC 2766                         NAT-PT                    February 2000


5.1 Translating IPv4 headers to IPv6 headers

   This is done exactly the same as in SIIT apart from the following
   fields:

      Source Address:
         The low-order 32 bits is the IPv4 source address. The high-
         order 96 bits is the designated PREFIX for all v4
         communications. Addresses using this PREFIX will be routed
         to the NAT-PT gateway (PREFIX::/96)

      Destination Address:
         NAT-PT retains a mapping between the IPv4 destination
         address and the IPv6 address of the destination node. The
         IPv4 destination address is replaced by the IPv6 address
         retained in that mapping.

5.2 Translating IPv6 headers to IPv4 headers

   This is done exactly the same as in SIIT apart from the Source
   Address which should be determined as follows:

      Source Address:
         The NAT-PT retains a mapping between the IPv6 source address
         and an IPv4 address from the pool of IPv4 addresses
         available. The IPv6 source address is replaced by the IPv4
         address retained in that mapping.

      Destination Address:
         IPv6 packets that are translated have a destination address
         of the form PREFIX::IPv4/96. Thus the low-order 32 bits of
         the IPv6 destination address is copied to the IPv4
         destination address.

5.3 TCP/UDP/ICMP Checksum Update

   NAT-PT retains mapping between IPv6 address and an IPv4 address from
   the pool of IPv4 addresses available. This mapping is used in the
   translation of packets that go through NAT-PT.

   The following sub-sections describe TCP/UDP/ICMP checksum update
   procedure in NAT-PT, as packets are translated from V4 to V6 and vice
   versa.








Tsirtsis & Srisuresh        Standards Track                    [Page 13]

RFC 2766                         NAT-PT                    February 2000


5.3.1 TCP/UDP/ICMP Checksum Update from IPv4 to IPv6

   UDP checksums, when set to a non-zero value, and TCP checksum SHOULD
   be recalculated to reflect the address change from v4 to v6. The
   incremental checksum adjustment algorithm may be borrowed from [NAT].
   In the case of NAPT-PT, TCP/UDP checksum should be adjusted to
   account for the address and TCP/UDP port changes, going from V4 to V6
   address.

   When the checksum of a V4 UDP packet is set to zero, NAT-PT MUST
   evaluate the checksum in its entirety for the V6-translated UDP
   packet. If a V4 UDP packet with a checksum of zero arrives in
   fragments, NAT-PT MUST await all the fragments until they can be
   assembled into a single non-fragmented packet and evaluate the
   checksum prior to forwarding the translated V6 UDP packet.

   ICMPv6, unlike ICMPv4, uses a pseudo-header, just like UDP and TCP
   during checksum computation. As a result, when the ICMPv6 header
   checksum is computed [SIIT], the checksum needs to be adjusted to
   account for the additional pseudo-header. Note, there may also be
   adjustments required to the checksum due to changes in the source and
   destination addresses (and changes in TCP/UDP/ICMP identifiers in the
   case of NAPT-PT) of the payload carried within ICMP.

5.3.2 TCP/UDP/ICMP Checksum Update from IPv6 to IPv4

   TCP and UDP checksums SHOULD be recalculated to reflect the address
   change from v6 to v4. The incremental checksum adjustment algorithm
   may be borrowed from [NAT]. In the case of NAPT-PT, TCP/UDP checksums
   should be adjusted to account for the address and TCP/UDP port
   changes, going from V6 to V4 addresses. For UDP packets, optionally,
   the checksum may simply be changed to zero.

   The checksum calculation for a V4 ICMP header needs to be derived
   from the V6 ICMP header by running the checksum adjustment algorithm
   [NAT] to remove the V6 pseudo header from the computation. Note, the
   adjustment must additionally take into account changes to the
   checksum as a result of updates to the source and destination
   addresses (and transport ports in the case of NAPT-PT) made to the
   payload carried within ICMP.

6. FTP Application Level Gateway (FTP-ALG) Support

   Because an FTP control session carries, in its payload, the IP
   address and TCP port information for the data session, an FTP-ALG is
   required to provide application level transparency for this popular
   Internet application.




Tsirtsis & Srisuresh        Standards Track                    [Page 14]

RFC 2766                         NAT-PT                    February 2000


   In the FTP application running on a legacy V4 node, arguments to the
   FTP PORT command and arguments in PASV response(successful) include
   an IP V4 address and a TCP port, both represented in ASCII as
   h1,h2,h3,h4,p1,p2. However, [FTP-IPV6] suggests EPRT and EPSV command
   extensions to FTP, with an intent to eventually retire the use of
   PORT and PASV commands. These extensions may be used on a V4 or V6
   node. FTP-ALG, facilitating transparent FTP between V4 and V6 nodes,
   works as follows.

6.1 Payload modifications for V4 originated FTP sessions

   A V4 host may or may not have the EPRT and EPSV command extensions
   implemented in its FTP application. If a V4 host originates the FTP
   session and uses PORT or PASV command, the FTP-ALG will translate
   these commands into EPRT and EPSV commands respectively prior to
   forwarding to the V6 node. Likewise, EPSV response from V6 nodes will
   be translated into PASV response prior to forwarding to V4 nodes.
   The format of EPRT and EPSV commands and EPSV response may be
   specified as follows[FTP-IPV6].

      EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
      EPSV<space><net-prt>
            (or)
      EPSV<space>ALL

      Format of EPSV response(Positive): 229 <text indicating
      extended passive mode> (<d><d><d><tcp-port><d>)

   PORT command from a V4 node is translated into EPRT command, by
   setting the protocol <net-prt> field to AF #2 (IPV6) and translating
   the V4 host Address (represented as h1,h2,h3,h4) into its NAT-PT
   assigned V6 address in string notation, as defined in [V6ADDR] in the
   <net-addr> field.  TCP port represented by p1,p2 in PORT command must
   be specified as a decimal <tcp-port> in the EPRT command. Further,
   <tcp-port> translation may also be required in the case of NAPT-PT.
   PASV command from a V4 node is be translated into a EPSV command with
   the <net-prt> argument set to AF #2.  EPSV response from a V6 node is
   translated into PASV response prior to forwarding to the target V4
   host.

   If a V4 host originated the FTP session and was using EPRT and EPSV
   commands, the FTP-ALG will simply translate the parameters to these
   commands, without altering the commands themselves. The protocol
   Number <net-prt> field will be translated from AF #1 to AF #2.
   <net-addr> will be translated from the V4 address in ASCII to its
   NAT-PT assigned V6 address in string notation as defined in [V6ADDR].
   <tcp-port> argument in EPSV response requires translation only in the
   case of NAPT-PT.



Tsirtsis & Srisuresh        Standards Track                    [Page 15]

RFC 2766                         NAT-PT                    February 2000


6.2 Payload modifications for V6 originated FTP sessions

   If a V6 host originates the FTP session, however, the FTP-ALG has two
   approaches to pursue. In the first approach, the FTP-ALG will leave
   the command strings "EPRT" and "EPSV" unaltered and simply translate
   the <net-prt>, <net-addr> and <tcp-port> arguments from V6 to its
   NAT-PT (or NAPT-PT) assigned V4 information. <tcp-port> is translated
   only in the case of NAPT-PT. Same goes for EPSV response from V4
   node. This is the approach we recommend to ensure forward support for
   RFC 2428.  However, with this approach, the V4 hosts are mandated to
   have their FTP application upgraded to support EPRT and EPSV
   extensions to allow access to V4 and V6 hosts, alike.

   In the second approach, the FTP-ALG will translate the command
   strings "EPRT" and "EPSV" and their parameters from the V6 node into
   their equivalent NAT-PT assigned V4 node info and attach to "PORT"
   and "PASV" commands prior to forwarding to V4 node.  Likewise, PASV
   response from V4 nodes is translated into EPSV response prior to
   forwarding to the target V6 nodes.  However, the FTP-ALG would be
   unable to translate the command "EPSV<space>ALL" issued by V6 nodes.
   In such a case, the V4 host, which receives the command, may return
   an error code indicating unsupported function. This error response
   may cause many RFC 2428 compliant FTP applications to simply fail,
   because EPSV support is mandated by RFC 2428. The benefit of this
   approach, however, is that is does not impose any FTP upgrade
   requirements on V4 hosts.

6.3 Header updates for FTP control packets

   All the payload translations considered in the previous sections are
   based on ASCII encoded data.  As a result, these translations may
   result in a change in the size of packet.

   If the new size is the same as the previous, only the TCP checksum
   needs adjustment as a result of the payload translation.  If the new
   size is different from the previous, TCP sequence numbers should also
   be changed to reflect the change in the length of the FTP control
   session payload. The IP packet length field in the V4 header or the
   IP payload length field in the V6 header should also be changed to