rfc2766.txt

RFC 的详细文档！

   reflect the new payload size. A table is used by the FTP-ALG to
   correct the TCP sequence and acknowledgement numbers in the TCP
   header for control packets in both directions.

   The table entries should have the source address, source data port,
   destination address and destination data port for V4 and V6 portions
   of the session, sequence number delta for outbound control packets
   and sequence number delta for inbound control packets.




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


   The sequence number for an outbound control packet is increased by
   the outbound sequence number delta, and the acknowledgement number
   for the same outbound packet is decreased by the inbound sequence
   number delta.  Likewise, the sequence number for an inbound packet is
   increased by the inbound sequence number delta and the
   acknowledgement number for the same inbound packet is decreased by
   the outbound sequence number delta.

7. NAT-PT Limitations and Future Work

   All limitations associated to NAT [NAT-TERM] are also associated to
   NAT-PT.  Here are the most important of them in detail, as well as
   some unique to NAT-PT.

7.1 Topology limitations

   There are limitations to using the NAT-PT translation method. It is
   mandatory that all requests and responses pertaining to a session be
   routed via the same NAT-PT router. One way to guarantee this would be
   to have NAT-PT 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. This is a generic problem with NAT and it is
   fully described in [NAT-TERM].

   Note, this limitation does not apply to packets originating from or
   directed to dual-stack nodes that do not require packet translation.
   This is because in a dual-stack set-up, IPv4 addresses implied in a
   V6 address can be identified from the address format PREFIX::x.y.z.w
   and a dual-stack router can accordingly route a packet between v4 and
   dual-stack nodes without tracking state information.

   This should also not affect IPv6 to IPv6 communication and in fact
   only actually use translation when no other means of communication is
   possible.  For example NAT-PT may also have a native IPv6 connection
   and/or some kind of tunneled IPv6 connection. Both of the above
   connections should be preferred over translation when possible. The
   above makes sure that NAT-PT is a tool only to be used to assist
   transition to native IPv6 to IPv6 communication.

7.2 Protocol Translation Limitations

   A number of IPv4 fields have changed meaning in IPv6 and translation
   is not straightforward. For example, the option headers semantics and
   syntax have changed significantly in IPv6.  Details of IPv4 to IPv6
   Protocol Translation can be found in [SIIT].






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


7.3 Impact of Address Translation

   Since NAT-PT performs address translation, applications that carry
   the IP address in the higher layers will not work.  In this case
   Application Layer Gateways (ALG) need to be incorporated to provide
   support for those applications. This is a generic problem with NAT
   and it is fully described in [NAT-TERM].

7.4 Lack of end-to-end security

   One of the most important limitations of the NAT-PT proposal is the
   fact that end-to-end network layer security is not possible.  Also
   transport and application layer security may not be possible for
   applications that carry IP addresses to the application layer. This
   is an inherent limitation of the Network Address Translation
   function.

   Independent of NAT-PT, end-to-end IPSec security is not possible
   across different address realms. The two end-nodes that seek IPSec
   network level security must both support one of IPv4 or IPv6.

7.5 DNS Translation and DNSSEC

   The scheme described in section 4.2 involves translation of DNS
   messages.  It is clear that this scheme can not be deployed in
   combination with secure DNS.  I.e., an authoritative DNS name server
   in the V6 domain cannot sign replies to queries that originate from
   the V4 world.  As a result, an V4 end-node that demands DNS replies
   to be signed will reject replies that have been tampered with by
   NAT-PT.

   The good news, however, is that only servers in V6 domain that need
   to be accessible from the V4 world pay the price for the above
   limitation, as V4 end-nodes may not access V6 servers due to DNS
   replies not being signed.

   Also note that zone transfers between DNS-SEC servers within the same
   V6 network are not impacted.

   Clearly, with DNS SEC deployment in DNS servers and end-host
   resolvers, the scheme suggested in this document would not work.

8. Applicability Statement

   NAT-PT can be a valuable transition tool at the border of a stub
   network that has been deployed as an IPv6 only network when it is
   connected to an Internet that is either V4-only or a combination of
   V4 and V6.



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


   NAT-PT, in its simplest form, without the support of DNS-ALG,
   provides one way connectivity between an IPv6 stub domain and the
   IPv4  world meaning  that only sessions initialised by IPv6 nodes
   internal to the IPv6 stub domain can be translated, while sessions
   initiated by  IPv4 nodes  are dropped. This makes NAT-PT a useful
   tool to IPv6 only stub networks that need to be able to maintain
   connectivity with the  IPv4 world without the need to deploy servers
   visible to the IPv4 world.

   NAT-PT  combined  with a DNS-ALG provides bi-directional connectivity
   between the IPv6 stub domain and the IPv4 world allowing sessions  to
   be  initialised  by  IPv4  nodes  outside the IPv6 stub domain.  This
   makes NAT-PT useful for IPv6 only stub  networks that need to  deploy
   servers visible to the IPv4 world.

   Some applications count on a certain degree of address stability for
   their operation. Dynamic address reuse by NAT-PT might not be
   agreeable for these applications. For hosts running such address
   critical applications, NAT-PT may be configured to provide static
   address mapping between the host's V6 address and a specific V4
   address. This will ensure that address related changes by NAT-PT do
   not become a significant source of operational failure.

9. Security Considerations

   Section 7.4 of this document states that end-to-end network and
   transport layer security are not possible when a session is
   intercepted by a NAT-PT.  Also application layer security may not be
   possible for applications that carry IP addresses in the application
   layer.

   Section 7.5 of this document states that the DNS-ALG can not be
   deployed in combination with secure DNS.

   Finally, all of the security considerations described in [NAT-TERM]
   are applicable to this document as well.

10. REFERENCES

   [DNS-ALG]  Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
              Heffernan, "DNS extensions to Network Address Translators
              (DNS_ALG)", RFC 2694, September 1999.

   [DNSSEC]   Eastlake, D., "Domain Name System Security Extensions",
              RFC 2065, March 1999.

   [FTP-IPV6] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for
              IPv6 and NATs", RFC 2428, September 1998.



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


   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [NAT]      Egevang, K. and P. Francis, "The IP Network Address
              Translator (NAT)", RFC 1631, May 1994.

   [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", RFC
              2663, August 1999.

   [SIIT]     Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC
              2765, February 2000.

   [TRANS]    Gilligan, R. and  E. Nordmark, "Transition Mechanisms for
              IPv6 Hosts and Routers", RFC 1933, April 1996.

   [V6ADDR]   Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

Authors' Addresses

   George Tsirtsis
   Internet Futures
   B29 Room 129
   BT Adastral Park
   IPSWICH IP5 3RE
   England

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   EMail (alternative): [e-mail]


   Pyda Srisuresh
   630 Alder Drive
   Milpitas, CA 95035
   U.S.A.

   Phone: [phone]
   EMail: [e-mail]










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


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Tsirtsis & Srisuresh        Standards Track                    [Page 21]