RFC 3424 (rfc3424) - Page 2 of 9
IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
Alternative Format: Original Text Document
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