Considerations for Selection of Techniques for NAT Traversal
draft-iab-nat-traversal-considerations-00

Document Type Expired Internet-Draft
Last updated 2015-10-14 (latest revision 2005-02-13)
Stream IAB
Intended RFC status Informational
Formats
Expired & archived
plain text pdf html bibtex
Stream IAB state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-iab-nat-traversal-considerations-00.txt

Abstract

There are many protocols designed and deployed on the Internet today which do not naturally traverse Network Address Translators (NAT). In order to allow these protocols to work in the presence of NAT, additional logic needs to be added to the network. This logic modifies the behavior of the protocol in some way. There are choices where this logic can be placed in the network. It can reside in the NATs themselves, transparently altering the protocol; when this occurs, it is called an Application Layer Gateway (ALG). It can reside in server components, hiding the changes from NATs and clients alike, it can reside in the clients, or it can reside in a combination thereof. The choice of the placement of this logic typically has implications on many aspects of the protocol, including security, deployability, manageability and availability. This document provides a set of considerations that should be taken into account by protocol and network designers when making this choice.

Authors

Jonathan Rosenberg (jdrosen@cisco.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)