Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Network Address Translator (NAT)-Friendly Application Design Guidelines (RFC3235)

IP.com Disclosure Number: IPCOM000006753D
Original Publication Date: 2002-Jan-01
Included in the Prior Art Database: 2002-Jan-30
Document File: 14 page(s) / 30K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Senie: AUTHOR

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).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 11% of the total text.

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...