RFC 3424 on IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
rfc-editor@rfc-editor.org Wed, 20 November 2002 01:46 UTC
Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23483; Tue, 19 Nov 2002 20:46:32 -0500 (EST)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id UAA05938 for ietf-123-outbound.10@ietf.org; Tue, 19 Nov 2002 20:45:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id UAA05786 for <all-ietf@loki.ietf.org>; Tue, 19 Nov 2002 20:21:55 -0500 (EST)
Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22943 for <all-ietf@ietf.org>; Tue, 19 Nov 2002 20:19:16 -0500 (EST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gAK1LrD04284; Tue, 19 Nov 2002 17:21:53 -0800 (PST)
Message-Id: <200211200121.gAK1LrD04284@gamma.isi.edu>
To: IETF-Announce:;
Subject: RFC 3424 on IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
Cc: rfc-editor@rfc-editor.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Tue, 19 Nov 2002 17:21:53 -0800
Sender: rfc-ed@ISI.EDU
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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs.