rfc2766.txt

RFC 的详细文档！

Network Working Group                                         G. Tsirtsis
Request for Comments: 2766                                             BT
Category: Standards Track                                    P. Srisuresh
                                                    Campio Communications
                                                            February 2000


      Network Address Translation - Protocol Translation (NAT-PT)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document specifies an IPv4-to-IPv6 transition mechanism, in
   addition to those already specified in [TRANS]. This solution
   attempts to provide transparent routing, as defined in [NAT-TERM], to
   end-nodes in V6 realm trying to communicate with end-nodes in V4
   realm and vice versa. This is achieved using a combination of Network
   Address Translation and Protocol Translation. The scheme described
   does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol
   support) or special purpose routing requirements (such as requiring
   tunneling support) on end nodes. This scheme is based on a
   combination of address translation theme as described in [NAT-TERM]
   and V6/V4 protocol translation theme as described in [SIIT].

Acknowledgements

   Special thanks to Pedro Marques for reviewing an earlier version of
   this memo.  Also, many thanks to Alan O'Neill and Martin Tatham, as
   the mechanism described in this document was initially developed
   through discussions with them.










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


Table of Contents

   1. Introduction..................................................  2
   2. Terminology...................................................  3
      2.1 Network Address Translation (NAT).........................  4
      2.2 NAT-PT flavors............................................  4
         2.2.1 Traditional-NAT-PT...................................  4
         2.2.2 Bi-directional-NAT-PT................................  5
      2.3 Protocol Translation (PT).................................  5
      2.4 Application Level Gateway (ALG)...........................  5
      2.5 Requirements..............................................  5
   3. Traditional-NAT-PT operation (V6 to V4).......................  6
      3.1 NAT-PT Outgoing Sessions..................................  6
      3.2 NAPT-PT Outgoing Sessions.................................  7
   4. Use of DNS-ALG for Address assignment.........................  8
      4.1 V4 Address Assignment for Incoming Connections (V4 to V6).  9
      4.2 V4 Address Assignment for Outgoing Connections (V6 to V4). 11
   5. Protocol Translation Details.................................. 12
      5.1 Translating IPv4 Headers to IPv6 Headers.................. 13
      5.2 Translating IPv6 Headers to IPv4 Headers.................. 13
      5.3 TCP/UDP/ICMP Checksum Update.............................. 13
   6. FTP Application Level Gateway (FTP-ALG) Support............... 14
      6.1 Payload modifications for V4 originated FTP sessions...... 15
      6.2 Payload modifications for V6 originated FTP sessions...... 16
      6.3 Header updates for FTP control packets.................... 16
   7. NAT-PT Limitations and Future Work............................ 17
      7.1 Topology Limitations...................................... 17
      7.2 Protocol Translation Limitations.......................... 17
      7.3 Impact of Address Translation............................. 18
      7.4 Lack of End-to-End Security............................... 18
      7.5 DNS Translation and DNSSEC................................ 18
   8. Applicability Statement....................................... 18
   9. Security Considerations....................................... 19
   10. References................................................... 19
   Authors' Addresses............................................... 20
   Full Copyright Statement......................................... 21

1. Introduction

   IPv6 is a new version of the IP protocol designed to modernize IPv4
   which was designed in the 1970s. IPv6 has a number of advantages over
   IPv4 that will allow for future Internet growth and will simplify IP
   configuration and administration. IPv6 has a larger address space
   than IPv4, an addressing model that promotes aggressive route
   aggregation and a powerful autoconfiguration mechanism.  In time, it
   is expected that Internet growth and a need for a plug-and-play
   solution will result in widespread adoption of IPv6.




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


   There is expected to be a long transition period during which it will
   be necessary for IPv4 and IPv6 nodes to coexist and communicate.  A
   strong, flexible set of IPv4-to-IPv6 transition and coexistence
   mechanisms will be required during this transition period.

   The SIIT proposal [SIIT] describes a protocol translation mechanism
   that allows communication between IPv6-only and IPv4-only nodes via
   protocol independent translation of IPv4 and IPv6 datagrams,
   requiring no state information for the session. The SIIT proposal
   assumes that V6 nodes are assigned a V4 address for communicating
   with V4 nodes, and does not specify a mechanism for the assignment of
   these addresses.

   NAT-PT uses a pool of V4 addresses for assignment to V6 nodes on a
   dynamic basis as sessions are initiated across V4-V6  boundaries. The
   V4 addresses are assumed to be globally unique. NAT-PT with private
   V4 addresses is outside the scope of this document and for further
   study.  NAT-PT binds addresses in V6 network with addresses in V4
   network and vice versa to provide transparent routing [NAT-TERM] for
   the datagrams traversing between address realms. This requires no
   changes to end nodes and IP packet routing is completely transparent
   [NAT-TERM] to end nodes. It does, however, require NAT-PT to track
   the sessions it supports and mandates that inbound and outbound
   datagrams pertaining to a session traverse the same NAT-PT router.
   You will note that the topology restrictions on NAT-PT are the same
   with those described for V4 NATs in [NAT-TERM]. Protocol translation
   details specified in [SIIT] would be used to extend address
   translation with protocol syntax/semantics translation. A detailed
   applicability statement for NAT-PT may be found at the end of this
   document in section 7.

   By combining SIIT protocol translation with the dynamic address
   translation capabilities of NAT and appropriate ALGs, NAT-PT provides
   a complete solution that would allow a large number of commonly used
   applications to interoperate between IPv6-only nodes and IPv4-only

   A fundamental assumption for NAT-PT is only to be use when no other
   native IPv6 or IPv6 over IPv4 tunneled means of communication is
   possible. In other words the aim is to only use translation between
   IPv6 only nodes and IPv4 only nodes, while translation between IPv6
   only nodes and the IPv4 part of a dual stack node should be avoided
   over other alternatives.

2. Terminology

   The majority of terms used in this document are borrowed almost as is
   from [NAT-TERM]. The following lists terms specific to this document.




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


2.1 Network Address Translation (NAT)

   The term NAT in this document is very similar to the IPv4 NAT
   described in [NAT-TERM], but is not identical. IPv4 NAT translates
   one IPv4 address into another IPv4 address. In this document, NAT
   refers to translation of an IPv4 address into an IPv6 address and
   vice versa.

   While the V4 NAT [NAT-TERM] provides routing between private V4 and
   external V4 address realms, NAT in this document provides routing
   between a V6 address realm and an external V4 address realm.

2.2 NAT-PT flavors

   Just as there are various flavors identified with V4 NAT in [NAT-
   TERM], the following NAT-PT variations may be identified in this
   document.

2.2.1 Traditional NAT-PT

   Traditional-NAT-PT would allow hosts within a V6 network to access
   hosts in the V4 network. In a traditional-NAT-PT, sessions are uni-
   directional, outbound from the V6 network.  This is in contrast with
   Bi-directional-NAT-PT, which permits sessions in both inbound and
   outbound directions.

   Just as with V4 traditional-NAT, there are two variations to
   traditional-NAT-PT, namely Basic-NAT-PT and NAPT-PT.

   With Basic-NAT-PT, a block of V4 addresses are set aside for
   translating addresses of V6 hosts as they originate sessions to the
   V4 hosts in external domain. For packets outbound from the V6 domain,
   the source IP address and related fields such as IP, TCP, UDP and
   ICMP header checksums are translated.  For inbound packets, the
   destination IP address and the checksums as listed above are
   translated.

   NAPT-PT extends the notion of translation one step further by also
   translating transport identifier (e.g., TCP and UDP port numbers,
   ICMP query identifiers). This allows the transport identifiers of a
   number of V6 hosts to be multiplexed into the transport identifiers
   of a single assigned V4 address.  NAPT-PT allows a set of V6 hosts to
   share a single V4 address. Note that NAPT-PT can be combined with
   Basic-NAT-PT so that a pool of external addresses are used in
   conjunction with port translation.






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


   For packets outbound from the V6 network, NAPT-PT would translate the
   source IP address, source transport identifier and related fields
   such as IP, TCP, UDP and ICMP header checksums. Transport identifier
   can be one of TCP/UDP port or ICMP query ID. For inbound packets, the
   destination IP address, destination transport identifier and the IP
   and transport header checksums are translated.

2.2.2  Bi-Directional-NAT-PT

   With Bi-directional-NAT-PT, sessions can be initiated from hosts in
   V4 network as well as the V6 network. V6 network addresses are bound
   to V4 addresses, statically or dynamically as connections are
   established in either direction.  The name space (i.e., their Fully
   Qualified Domain Names) between hosts in V4 and V6 networks is
   assumed to be end-to-end unique.  Hosts in V4 realm access V6-realm
   hosts by using DNS for address resolution. A DNS-ALG [DNS-ALG] must
   be employed in conjunction with Bi-Directional-NAT-PT to facilitate
   name to address mapping.  Specifically, the DNS-ALG must be capable
   of translating V6 addresses in DNS Queries and responses into their
   V4-address bindings, and vice versa, as DNS packets traverse between
   V6 and V4 realms.

2.3 Protocol Translation (PT)

   PT in this document refers to the translation of an IPv4 packet into
   a semantically equivalent IPv6 packet and vice versa.  Protocol
   translation details are described in [SIIT].

2.4 Application Level Gateway (ALG)

   Application Level Gateway (ALG) [NAT-TERM] is an application specific
   agent that allows a V6 node to communicate with a V4 node and vice
   versa. Some applications carry network addresses in payloads. NAT-PT
   is application unaware and does not snoop the payload. ALG could work
   in conjunction with NAT-PT to provide support for many such
   applications.

2.5 Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [KEYWORDS].









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


3. Traditional-NAT-PT Operation (V6 to V4)

   NAT-PT offers a straight forward solution based on transparent
   routing [NAT-TERM] and address/protocol translation, allowing a large
   number of applications in V6 and V4 realms to inter-operate without
   requiring any changes to these applications.

   In the following paragraphs we describe the operation of
   traditional-NAT-PT and the way that connections can be initiated from