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