IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
RFC 3424

Document Type RFC - Informational (November 2002; Errata)
Last updated 2015-10-14
Stream IAB
Formats plain text pdf html bibtex
Stream IAB state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
Network Working Group                                     L. Daigle, Ed.
Request for Comments: 3424                   Internet Architecture Board
Category: Informational                                              IAB
                                                           November 2002

     IAB Considerations for UNilateral Self-Address Fixing (UNSAF)
                   Across Network Address Translation

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

   As a result of the nature of Network Address Translation (NAT)
   Middleboxes, communicating endpoints that are separated by one or
   more NATs do not know how to refer to themselves using addresses that
   are valid in the addressing realms of their (current and future)
   peers.  Various proposals have been made for "UNilateral Self-Address
   Fixing (UNSAF)" processes.  These are processes whereby some
   originating endpoint attempts to determine or fix the address (and
   port) by which it is known to another endpoint - e.g. to be able to
   use address data in the protocol exchange, or to advertise a public
   address from which it will receive connections.

   This document outlines the reasons for which these proposals can be
   considered at best as short term fixes to specific problems and the
   specific issues to be carefully evaluated before creating an UNSAF
   proposal.

1. Introduction

   As a result of the nature of Network Address (and port) Translation
   (NAT) Middleboxes, communicating endpoints that are separated by one
   or more NATs do not know how to refer to themselves using addresses
   that are valid in the addressing realms of their (current and future)
   peers - the address translation is locked within the NAT box.  For
   some purposes, endpoints need to know the addresses (and/or ports) by
   which they are known to their peers.  There are two cases: 1) when
   the client initiates communication, starting the communication has
   the side effect of creating an address binding in the NAT device and

Daigle & IAB                 Informational                      [Page 1]
RFC 3424        IAB Considerations for UNSAP Across NAT    November 2002

   allocating an address in the realm that is external to the NAT box;
   and 2) a server will be accepting connections from outside, but
   because it does not initiate communication, no NAT binding is
   created.  In such cases, a mechanism is needed to fix such a binding
   before communication can take place.

   "UNilateral Self-Address Fixing (UNSAF)" is a process whereby some
   originating process attempts to determine or fix the address (and
   port) by which it is known - e.g. to be able to use address data in
   the protocol exchange, or to advertise a public address from which it
   will receive connections.

   There are only heuristics and workarounds to attempt to achieve this
   effect; there is no 100% solution.  Since NATs may also dynamically
   reclaim or readjust translations, "keep-alive" and periodic re-
   polling may be required.  Use of these workarounds MUST be considered
   transitional in IETF protocols, and a better architectural solution
   is being sought.  The explicit intention is to deprecate any such
   workarounds when sound technical approaches are available.

2. Architectural issues affecting UNSAF Systems

   Generally speaking, the proposed workarounds are for cases where a
   standard protocol communication is to take place between two
   endpoints,  but in order for this to occur, a separate step of
   determining (or fixing) the perceived address of an endpoint in the
   other endpoint's addressing realm is required.  Proposals require
   that an endpoint seeking to "fix" its address contact a participating
   service (in a different address realm) to determine (reflect) its
   address.  Thus, there is an "UNSAF client" partnering with some form
   of "UNSAF service" that may or may not be associated with the target
   endpoint of the actual desired communication session.  Throughout
   this memo, the terms "UNSAF server" and "UNSAF service" should be
   understood to generically refer to whatever process is participating
   in the UNSAF address determination for the originating process (the
   UNSAF client).

   Any users of these workarounds should be aware that specific
   technical issues that impede the creation of a general solution
   include:

   o  there *is* no unique "outside" to a NAT - it may be impossible to
      tell where the target endpoint is with respect to the initiator;
Show full document text