RFC 3424: IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
In plain English — editorial summary, not part of the RFC
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. This memo provides information for the Internet community.
Document record
- Document ID
- RFC3424
- Published
- November 2002
- Authors
- L. Daigle; IAB
- Status
- INFORMATIONAL
- Stream
- IAB
- Area
- —
- Pages
- 9
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 5902IAB Thoughts on IPv6 Network Address TranslationCurrent
July 2010
- RFC 3519Mobile IP Traversal of Network Address Translation (NAT) DevicesCurrent
May 2003
- RFC 3304Middlebox Communications (midcom) Protocol RequirementsCurrent
August 2002
- RFC 3257Stream Control Transmission Protocol Applicability StatementCurrent
April 2002
- RFC 3605Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)Current
October 2003
- RFC 3726Requirements for Signaling ProtocolsCurrent
April 2004
- RFC 3105Finding an RSIP Server with SLPCurrent
October 2001
- RFC 3104RSIP Support for End-to-end IPsecCurrent
October 2001
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?