RFC 3424 (rfc3424) - Page 2 of 9

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

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;
      how does an UNSAF client find an appropriate UNSAF server to
      reflect its address?  (See Appendix C).






Daigle & IAB                 Informational