Document Action: 'NAT Behavior Discovery Using STUN' to Experimental RFC
The IESG <iesg-secretary@ietf.org> Mon, 07 December 2009 15:56 UTC
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 662F93A6A45; Mon, 7 Dec 2009 07:56:51 -0800 (PST)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: 'NAT Behavior Discovery Using STUN' to Experimental RFC
Message-Id: <20091207155651.662F93A6A45@core3.amsl.com>
Date: Mon, 07 Dec 2009 07:56:51 -0800
Cc: Internet Architecture Board <iab@iab.org>, behave mailing list <behave@ietf.org>, behave chair <behave-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 15:56:51 -0000
The IESG has approved the following document: - 'NAT Behavior Discovery Using STUN ' <draft-ietf-behave-nat-behavior-discovery-08.txt> as an Experimental RFC This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-08.txt Technical Summary This specification defines an experimental usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server. Working Group Summary The original intent was to publish this specification as Informational, but the working group decided Experimental would be a better track in order to more clearly convey the risky nature of attempting to determine a NAT's behavior. Document Quality Two vendors are known to implement it. The IETF last call draw a number of comments about its applicability and a number of details. My review of them looks like they have been resolved in a reasonable way. Personnel Dan Wing, dwing@cisco.com is the WG shepherd and Magnus Westerlund, magnus.westerlund@ericsson.com the responsible AD. RFC Editor Note Section 1, second and third paragraph: OLD: The primary uses envisioned for the STUN attributes included in this draft are diagnostics and real-time tuning of applications. The techniques possible with this usage are powerful diagnostic tools in the hands of a network administrator or system programmer trying to determine the causes of network failure; particularly when behavior varies by load, destination, or other factors that may be related to NAT behavior. This draft also proposes experimental usage of these attributes for real-time optimization of parameters for protocols in situations where a publicly accessible rendezvous service is not available. Such a use of these techniques is only possible when the results are applied as an optimization and a reliable fallback is available in case the NAT's behavior becomes more restrictive than determined by the Behavior Discovery tests. One possible application is role selection in P2P networks based on statistical experience with establishing direct connections and diagnosing NAT behavior with a variety of peers. The experimental question is whether such a test is useful. If a node trying to join an overlay as a full peer when its NAT prevents sufficient connectivity and then withdrawing is expensive or leads to unreliable or poorly performing operation, then even if the behavior discovery check is only "correct" 75% of the time, its relative cheapness may make it very useful for optimizing the behavior of the overlay network. Section 2.2 describes this experimental application in more detail and discusses how to evaluate its success or failure. NEW: The uses envisioned for the STUN attributes included in this document are diagnostics and real-time tuning of applications. For example determine what may work and should be tried first compared to more expensive methods. The attributes can also be used to observe behaviors that causes an application's communication to fail, thus enabling better selection of methods of recovery. The STUN attributes could also be a basis for a network technican's diagnostics tool to observe NAT behavior. This draft proposes experimental usage of these attributes for ^ real-time optimization of parameters for protocols in situations where a publicly accessible rendezvous service is not available. Such a use of these techniques is only possible when the results are applied as an optimization and a reliable fallback is available in case the NAT's behavior becomes more restrictive than determined by the Behavior Discovery tests. One possible application is role selection in P2P networks based on statistical experience with establishing direct connections and diagnosing NAT behavior with a variety of peers. The experimental question is whether such a test is useful. If a node trying to join an overlay as a full peer when its NAT prevents sufficient connectivity and then withdrawing is expensive or leads to unreliable or poorly performing operation, then even if the behavior discovery check is only "correct" 75% of the time, its relative cheapness may make it very useful for optimizing the behavior of the overlay network. Section 2.2 describes this experimental application in more detail and discusses how to evaluate its success or failure. Section 2.3: Section title OLD: Experimental Success NEW: Experimental Goals