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
