Network Address Translator (NAT)-Friendly Application Design Guidelines
RFC 3235

Document Type RFC - Informational (January 2002; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 3235 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           D. Senie
Request for Comments: 3235                        Amaranth Networks Inc.
Category: Informational                                     January 2002

               Network Address Translator (NAT)-Friendly
                     Application Design Guidelines

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document discusses those things that application designers might
   wish to consider when designing new protocols.  While many common
   Internet applications will operate cleanly in the presence of Network
   Address Translators, others suffer from a variety of problems when
   crossing these devices.  Guidelines are presented herein to help
   ensure new protocols and applications will, to the extent possible,
   be compatible with NAT (Network Address Translation).

1. Introduction

   Other documents that describe Network Address Translation (NAT)
   discuss the Terminology and Considerations [RFC2663] and Protocol
   Issues [RFC3022], [RFC3027] or discuss the implications of NAT
   [RFC2993].  All of those relate to various issues with the NAT
   mechanism, effects on protocols and effects upon general Internet
   architecture.

   It is the focus of this document to provide recommendations to
   authors of new protocols about the effects to consider when designing
   new protocols such that special handling is not required at NAT
   gateway points.

   When a protocol is unable to pass cleanly through a NAT, the use of
   an Application Level Gateway (ALG) may still permit operation of the
   protocol.  Depending on the encoding used in a protocol, an ALG may
   be difficult or easy to construct, though in some cases it may not be
   possible at all.  While adjunct to NAT, the formulation of protocols
   that cannot directly operate through NAT should be considered such

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

   that the ALG design may be simple and automated.  ALGs typically
   operate inside small routers along with the NAT component.  Ideally,
   the ALG should be simple and not require excessive computation or
   state storage.

   Many of the same issues in application design that create issues for
   NAT (and thus can require ALG support) are also issues for firewalls.
   An application designer would do well to keep this in mind, as any
   protocol that does require special handling by NAT or firewall
   products will be more difficult to deploy than those that require no
   special handling.

2. Discussion

   Network Address Translation presents a challenge to some existing
   applications.  In many cases, it should be possible for developers of
   new applications to avoid problems if they understand the issues.
   This document aims to provide the application designer with
   information on what things they can do and what to avoid when trying
   to build applications that are able to function across NAT.

   The proliferation of NAT, especially in homes and small offices
   cannot be dismissed.  The marketing of these technologies to homes
   and small businesses is often focused on a single-computer
   environment, and thus providers only give out a single IP address to
   each user.  NAT has become a popular choice for connecting more than
   a single system per location.

   Clearly the most common problem associated with NAT implementations
   is the passing of addressing data between stations.  Where possible,
   applications should find alternatives to such schemes.  Studying a
   few existing protocols will serve to highlight the different
   approaches possible.

   Two common forms of Traditional NAT exist.  With Basic NAT, only the
   IP addresses of packets are altered by the NAT implementation.  Many
   applications will operate correctly with Basic NAT.  The other common
   form is Network Address Port Translation.  With NAPT, both the IP
   addresses and the source and destination ports (for TCP and UDP) are
   potentially altered by the gateway.  As such, applications passing
   only port number information will work with Basic NAT, but not with
   NAPT.

   Application designers should strive for compatibility with NAPT, as
   this form of NAT is the most widely deployed.  This is also the form
   of NAT that will likely see the greatest penetration in homes and
   small offices.  Not all applications lend themselves to the
   architectural model imposed by NAPT.

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

3. Recommendations and Examples

   Application designers who work within the constraints of NAT, and who
Show full document text