rfc3027.txt

RFC3027:Protocol Complications with the IP Network Address Translator

RFC 3027            Protocol Complications with NAT         January 2001


   domain context and can hence operate independent of the specific
   managed object types being accessed.  The proxy solution will require
   the external management application to be aware of the proxy
   forwarder and the individual nodes being managed will need to be
   configured to direct their SNMP traffic (notifications and requests)
   to the proxy forwarder.

5.0 Protocols designed explicitly to work with NAT enroute

5.1 Activision Games

   Activision Games were designed to be NAT-friendly so as not to
   require an ALG for the games to work transparently through
   traditional NAT devices.  Game players within a private domain can
   play with other players in the same domain or external domain.
   Activision gaming protocol is proprietary and is based on UDP.  The
   address server uses UDP port number 21157 and is expected to be
   located in the global address realm.

   Game players connect to the address server first, and send their
   private IP address information (such as private IP address and UDP
   port number) in the initial connect message.  The server notes
   private address information from the connect message and external
   address information from the IP and UDP headers.  The server then
   sends both the private and external address information of the game
   player to all the other peer players.  At this point, each game
   player knows the private and public address information of every
   other peer.  Subsequent to this, each client opens up symmetrical
   direct connection to each other and uses whichever address (private
   or external) works first.

   Now, the clients can have a session directly with other clients (or)
   they can have session with other clients via the gaming server.  The
   key is to allow reuse of the same (global address, assigned UDP port)
   tuple used for initial connection to the game server for all
   subsequent connections to the client.  A game player is recognized by
   one of (private address, UDP port) or (global address, assigned UDP
   port) by all other peer players.  So, the binding between tuples
   should remain unchanged on NAT, so long as the gaming player is in
   session with one or multiple other players.

   Opening a connection to a game server in external realm from a
   private host is no problem.  All NAT would have to do is provide
   routing transparency and retain the same private-to-external address
   binding so long as there is a minimum of one gaming session with an
   external node.  But, an NAPT configuration must allow multiple
   simultaneous UDP connections on the same assigned global
   address/port.



Holdrege & Srisuresh         Informational                     [Page 16]

RFC 3027            Protocol Complications with NAT         January 2001


   The above approach has some problems.  For example, a client could
   try contacting a private address, but that private address could be
   in use locally, when the private address at some other realm is
   meant. If the node that was contacted wrongfully has some other
   service or no service registered for the UDP port, the Activision
   connect messages are expected to be simply dropped.  In the unlikely
   event, a registered application chooses to interpret the message, the
   results can be unpredictable.

   The readers may refer to Activision for the proprietary, detailed
   information on the function and design of this protocol.

6.0 Acknowledgements

   The authors would like to express sincere thanks to Bernard Aboba,
   Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine,
   Jeffrey Altman, Keith Moore, Thomas Narten, Vernon Shryver and others
   that had provided valuable input in preparing this document.  Special
   thanks to Dan Kegel for sharing the Activision games design
   methodology.

7.0 Security Considerations

   The security considerations outlined in [NAT-TERM] are relevant to
   all NAT devices.  This document does not warrant additional security
   considerations.

8.0 References

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

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

   [H.323]      ITU-T SG16 H.323, Intel white paper, "H.323 and
                Firewalls", Dave Chouinard, John Richardson, Milind
                Khare (with further assistance from Jamie Jason).

   [SNMP-ALG]   Raz, D., Schoenwaelder, J. and B. Sugla, "An SNMP
                Application Level Gateway for Payload Address
                Translation", RFC 2962, October 2000.

   [SNMP-APPL]  Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",
                RFC 2573, April 1999.




Holdrege & Srisuresh         Informational                     [Page 17]

RFC 3027            Protocol Complications with NAT         January 2001


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

   [SMTP]       Postel, J., "Simple Mail Transfer Protocol", STDl 10,
                RFC 821, August 1982.

   [FTP]        Postel, J. and J. Reynolds, "File Transfer Protocol
                (FTP)", STD 9, RFC 959, October 1985.

   [SIP]        Handley, M., Schulzrinne, H., Schooler, E. and J.
                Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
                March 1999.

   [X Windows]  Scheifler, B., "FYI on the X Window System", FYI 6, RFC
                1198, January 1991.

   [RSVP]       Braden, R., Zhang. L., Berson. S., Herzog, S. and S.
                Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
                1 Functional Specification", RFC 2205, September 1997.

   [DNS-TERMS]  Mockapetris, P., "Domain Names - Concepts and
                Facilities", STD 13, RFC 1034, November 1987.

   [DNS-IMPL]   Mockapetris, P., "Domain Names - Implementation and
                Specification", STD 13, RFC 1035, November 1987.

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

   [IPsec]      Kent, S. and R. Atkinson, "Security Architecture for the
                Internet Protocol", RFC 2401, November 1998.

   [IPsec-ESP]  Kent, S. and R. Atkinson, "IP Encapsulating Security
                Payload (ESP)", RFC 2406, November 1998.

   [IPsec-AH]   Kent, S. and R. Atkinson, "IP Authentication Header",
                RFC 2402, November 1998.

   [IPsec-DOCS] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
                Document Roadmap", RFC 2411, November 1998.

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

   [PRIV-ADDR]  Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot,
                and E. Lear, "Address Allocation for Private Internets",
                BCP 5, RFC 1918, February 1996.



Holdrege & Srisuresh         Informational                     [Page 18]

RFC 3027            Protocol Complications with NAT         January 2001


   [ADDR-BEHA]  Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4
                Address Behaviour Today", RFC 2101, February 1997.

Authors' Addresses

   Matt Holdrege
   ipVerse
   223 Ximeno Ave.
   Long Beach, CA 90803

   EMail: [e-mail]


   Pyda Srisuresh
   Jasmine Networks, Inc.
   3061 Zanker Road, Suite B
   San Jose, CA 95134
   U.S.A.

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






























Holdrege & Srisuresh         Informational                     [Page 19]

RFC 3027            Protocol Complications with NAT         January 2001


Full Copyright Statement

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



















Holdrege & Srisuresh         Informational                     [Page 20]