IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
draft-iab-unsaf-considerations-02
This document is an Internet-Draft (I-D) that has been submitted to the Internet Architecture Board (IAB) stream.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3424.
|
|
---|---|---|---|
Authors | IAB , Leslie Daigle | ||
Last updated | 2020-01-21 (Latest revision 2002-07-02) | ||
RFC stream | Internet Architecture Board (IAB) | ||
Intended RFC status | Informational | ||
Formats | |||
Stream | IAB state | (None) | |
Consensus boilerplate | Unknown | ||
IAB shepherd | (None) |
draft-iab-unsaf-considerations-02
A new Request for Comments is now available in online RFC libraries. RFC 3424 Title: IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation Author(s): L. Daigle, Ed., IAB Status: Informational Date: November 2002 Mailbox: iab@iab.org Pages: 9 Characters: 18165 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-iab-unsaf-considerations-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3424.txt 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 document is a product of the Internet Architecture Board. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information.