rfc3235.txt

RFC 的详细文档！

   Protocols other than TCP and UDP can work with Traditional NAT in
   many cases, provided they are not carrying addressing information.
   For NAPT implementations use of any protocols other than TCP and UDP
   will be problematic unless or until such protocols are programmed
   into the implementations.

   It's important to note that NAPT deployments are based on the
   assumption of a client-server application model, with the clients in
   the private realm.

3.2.5. IP Fragmentation

   Applications should attempt to avoid fragmentation when packets pass
   over NAPT devices.  While not always practical or possible, there are
   failures that can occur with NAPT.  Specifically, if two stations in
   the private realm pick matching fragmentation identifiers, and talk
   to the same remote host, it may be impossible to determine which
   fragments belong to which session.  A clever NAPT implementation
   could track fragmentation identifiers and map those into a unique
   space, though it is not clear how many do so.







Senie                        Informational                      [Page 7]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002


   Ideally, applications should limit packet size, use Path MTU
   Discovery or both.  Unfortunately, at least some firewall/NAT devices
   block Path MTU Discovery, apparently believing all ICMP packets are
   evil.

   Some implementations of NAT may implement fragment reassembly prior
   to Forwarding, however many do not.  Application designers are
   advised to design assuming the devices do not reassemble fragments.

3.3 Issues and recommendations for Basic NAT

   If only Basic NAT implementations are involved, not NAPT, then many
   of the issues above do not apply.  This is not to say that this form
   of NAT is better or worse than NAPT.  Application designers may think
   they could just specify users must use Basic NAT, and many
   application issues would go away.  This is unrealistic, however, as
   many users have no real alternative to NAPT due to the way their
   providers sell service.

   Many of the issues raised earlier still apply to Basic NAT, and many
   protocols will not function correctly without assistance.

3.3.1. Use IP and TCP/UDP Headers Alone

   Applications that use only the information in the IP and TCP or UDP
   headers for communication (in other words, do not pass any additional
   addressing information in the payload of the packets), are clearly
   easier to support in a NAT environment.  Where possible, applications
   designers should try to limit themselves in this area.

   This comes back to the same recommendation made for NAPT, that being
   to use a single connection whenever possible.

   The X windowing system, for example, uses fixed port numbers to
   address X servers.  With X, the server (display) is addressed via
   ports 6000 through 6000 + n.  These map to hostname:0 through
   hostname:n server displays.  Since only the address and port are
   used, the NAT administrator could map these ports to one or more
   private addresses, yielding a functioning solution.

   The X example, in the case of NAPT, requires configuration of the NAT
   implementation.  This results in the ability for no more than one
   station inside the NAT gateway to use such a protocol.  This approach
   to the problem is thus OK for NAT but not recommended for NAPT
   environments.






Senie                        Informational                      [Page 8]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002


3.3.2. Avoid Addressing In Payload

   As with NAPT, transporting IP address and/or port number information
   in the payload is likely to cause trouble.  As stated earlier, load
   balancers and similar platforms may well map the same IP address and
   port number to a completely different system.  Thus it is problematic
   to assume an address or port number which is valid in the realm on
   one side of a NAT is valid on the other side.

3.4 Bi-directional NAT

   Bi-directional NAT makes use of DNS mapping of names to point
   sessions originating outside the private realm to servers in the
   private realm.  Through use of a DNS-ALG [RFC2694], lookups are
   performed to find the proper host and packets are sent to that host.

   Requirements for applications are the same as for Basic NAT.
   Addresses are mapped one-to-one to servers.  Unlike Traditional NAT
   devices, Bi-directional NAT devices (in conjunction with DNS-ALG) are
   amenable to peer-to-peer applications.

3.5 Twice NAT

   Twice NAT is address translation where both source and destination IP
   addresses are modified due to addressing conflicts between two
   private realms.  Two bi-directional NAT boxes connected together
   would essentially perform the same task, though a common address
   space that is not otherwise used by either private realm would be
   required.

   Requirements for applications to work in the Twice NAT environment
   are the same as for Basic NAT.  Addresses are mapped one to one.

3.6 Multi-homed NAT

   Multi-homed NAT is the use of multiple NAT implementations to provide
   redundancy.  The multiple implementations share configuration
   information so that sessions might continue in the event of a fail-
   over.  Unless the multiple implementations share the same external
   addresses, sessions will have to restart regardless.

   Requirements for multi-homed NAT are the same as for Basic NAT or
   NAPT, depending on how the multi-homed NAT is implemented and
   configured.







Senie                        Informational                      [Page 9]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002


3.7 Realm Specific IP (RSIP)

   Realm Specific IP is described in [RFC2663] and defined in [RSIP] and
   related documents.  Clients within a private realm using RSIP are
   aware of the delineation between private and public, and access a
   server to allocate address (and optionally port) information for use
   in conversing with hosts in the public realm.  By doing this, clients
   create packets that need not be altered by the RSIP server on their
   way to the remote host.  This technique can permit IPSec to function,
   and potentially makes any application function as if there were no
   special processing involved at all.

   RSIP uses a view of the world in which there are only two realms, the
   private and public.  This isn't always the case.  Situations with
   multiple levels of NAT implementations are growing.  For example,
   some ISPs are handing out [RFC1918] addresses to their dialup users,
   rather than obtaining real addresses.  Any user of such an ISP who
   also uses a NAT implementation will see two levels of NAT, and the
   advantages of RSIP will have been wasted.

3.8 Performance Implications of Address Translation Implementations

   Resource utilization on the NAT gateway should be considered.  An
   application that opens and closes many TCP connections, for example,
   will use up more resources on the NAT router than an application
   performing all transfers over a single TCP connection.  HTTP 1.0
   opened a connection for each object on a web page, whereas HTTP 1.1
   permits the TCP session to be held open for additional objects that
   may need to be transferred.  Clearly the latter imposes a lower
   overhead on the NAT gateway, as it is only maintaining state on a
   single connection instead of multiple connections.

   New session establishment will typically remain a software function
   even in implementations where the packet-by-packet translation work
   is handled by hardware forwarding engines.  While high-performance
   NAT boxes may be built, protocols that open many sessions instead of
   multiplexing will be slower than those that do not.

   Applications with different types of data, such as interactive
   conferencing, require separate streams for the different types of
   data.  In such cases the protocol needs of each stream must be
   optimized.  While the goal of multiplexing over a single session is
   preferred, clearly there are cases where this is impractical.

   The latency of NAT translation overhead is implementation dependent.
   On a per-packet basis, for established sessions only the source or
   destination IP address is replaced, the source or destination port
   (for NAPT) and the checksums for IP, and TCP or UDP are recalculated.



Senie                        Informational                     [Page 10]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002


   The functionality can be efficiently implemented in hardware or
   software.

4. Security Considerations

   Network Address Translators have implications for IPSec, as noted
   above.  When application developers are considering whether their
   applications function with NAT implementations, care should be given
   to selection of security methodology.  Transport Layer Security (TLS)
   [RFC2246] operates across translation boundaries.  End-to-end IPSec
   will prove problematic in many cases.

5. References

   [RFC1579]   Bellovin, S., "Firewall Friendly FTP", RFC 1579, February
               1994.

   [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, January 1999.

   [RFC2993]   Hain, T., "Architectural Implications of NAT", RFC 2993,
               November 2000.

   [RFC3027]   Holdrege, M. and P. Srisuresh, "Protocol Complications
               with the IP Network Address Translator (NAT)", RFC 3027,
               January 2001.

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

   [RFC2709]   Srisuresh, P., "Security Model with Tunnel-mode IPsec for
               NAT Domains", RFC 2709, October 1999.

   [RFC3102]   Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
               "Realm Specific IP: Framework", RFC 3102, October 2001.

   [RFC3022]   Srisuresh, P. and K. Egevang, "Traditional IP Network
               Address Translator (Traditional NAT)", RFC 3022, January
               2001.

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







Senie                        Informational                     [Page 11]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002


6. Acknowledgements

   I'd like to thank Pyda Srisuresh for his invaluable input and
   feedback, and Keith Moore for his extensive comments.

7. Author's Address

   Daniel Senie
   Amaranth Networks Inc.
   324 Still River Road
   Bolton, MA 01740

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





































Senie                        Informational                     [Page 12]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002


8.  Full Copyright Statement

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



















Senie                        Informational                     [Page 13]