Behavior Engineering for Hindrance Avoidance (behave)
-----------------------------------------------------

 Charter
 Last Modified: 2007-12-26

 Current Status: Active Working Group

 Chair(s):
     Dan Wing  <dwing@cisco.com>

 Transport Area Director(s):
     Magnus Westerlund  <magnus.westerlund@ericsson.com>
     Lars Eggert  <lars.eggert@nokia.com>

 Transport Area Advisor:
     Magnus Westerlund  <magnus.westerlund@ericsson.com>

 Mailing Lists: 
     General Discussion:behave@ietf.org
     To Subscribe:      behave-request@ietf.org
         In Body:       In Body: subscribe
     Archive:           http://www1.ietf.org/mail-archive/web/behave/current/index.html

Description of Working Group:

Given the current near-universal deployment of NATs (Network Address
Translators) in the public Internet, the lack of standards for NAT 
behavior has given rise to a crisis. While it is widely acknowledged 
that NATs create problems for numerous Internet applications, our 
inability to describe precisely what a NAT is or how it behaves leaves 
us few solutions for compensating for the presence of NATs.

The behavior of NATs varies dramatically from one implementation to 
another. As a result it is very difficult for applications to predict 
or discover the behavior of these devices. Predicting and/or 
discovering the behavior of NATs is important for designing 
application protocols and NAT traversal techniques that work reliably 
in existing networks. This situation is especially problematic for end-
to-end interactive applications such as multiuser games and 
interactive multimedia.

NATs continue to proliferate and have seen an increasing rate of 
deployment. IPv6 deployments can eliminate this problem, but there is 
a significant interim period in which applications will need to work 
both in IPv4 NAT environments and with the IPv6 to IPv4 transition 
mechanisms.

This working group proposes to generate requirements documents and best
current practices to enable NATs to function in as deterministic a 
fashion as possible. It will consider what is broken by these devices 
and document approaches for characterizing and testing them. The NAT 
behavior practices will be application independent.

The group will also advise on how to develop applications that 
discover and reliably function in environments with NATs that follow 
the best current practices identified by this working group. This will 
include the development of protocol-independent toolkits usable by 
application protocols for NAT traversal. This will include a revision 
of RFC 3489 for NAT binding discovery and a relay protocol that 
focuses on security.

The work will be done with the goal of encouraging eventual migration 
to IPv6 and compliance with the UNSAF [RFC 3424] considerations. It 
will not encourage the proliferation of NATs.

The behavior that will be considered includes IP fragmentation and
parameters that impact ICMP, UDP, TCP, IGMP, MLD, and multicast. The
proposed WG will coordinate with v6ops, midcom and nsis. The work is 
largely limited to examining various approaches that are already in 
use today and providing suggestions about which ones are likely to 
work best in the internet architecture.

 Goals and Milestones:

   Done         Submit BCP that defines unicast UDP behavioral requirements for 
                NATs to IESG 

   Done         Submit a BCP that defines TCP behavioral requireents for NATs 
                to IESG 

   Done         Submit IPv6 relay protocol to IESG 

   Done         Submit a BCP that defines ICMP behavioral requirements for NATs 
                to IESG 

   Done         Submit informational that discusses current NAT traversal 
                techniques used by applications 

   Done         Submit BCP that defines multicast UDP 

   Done         Submit revision of RFC 3489 to IESG behavioral requirements for 
                NATs to IESG 

   Jan 2008       Submit informational document for rfc3489bis test vectors 

   Jan 2008       Submit experimental document that describes how an application 
                can determine the type of NAT it is behind 

   Jul 2008       Submit standards-track document for media relaying of TCP 

   Jul 2008       Submit BCP document for DCCP NAT behavior 

   Dec 2008       Submit BCP document for SCTP NAT behavior 

   Dec 2008       Close working group or recharter 


 Internet-Drafts:

Posted Revised         I-D Title   <Filename>
------ ------- --------------------------------------------
Oct 2004 Nov 2007   <draft-ietf-behave-rfc3489bis-13.txt>
                Session Traversal Utilities for (NAT) (STUN) 

May 2005 Nov 2007   <draft-ietf-behave-multicast-12.txt>
                IP Multicast Requirements for a Network Address (and port) 
                Translator (NAT) 

Feb 2006 Apr 2007   <draft-ietf-behave-tcp-07.txt>
                NAT Behavioral Requirements for TCP 

Mar 2006 Nov 2007   <draft-ietf-behave-turn-05.txt>
                Traversal Using Relays around NAT (TURN): Relay Extensions to 
                Session Traversal Utilities for NAT (STUN) 

Mar 2006 Jul 2007   <draft-ietf-behave-turn-ipv6-03.txt>
                Extension to the Simple Traversal Underneath NAT (STUN) Relay 
                Usage for IPv4/IPv6 Transition 

May 2006 Oct 2007   <draft-ietf-behave-nat-icmp-06.txt>
                NAT Behavioral Requirements for ICMP protocol 

Oct 2006 Nov 2007   <draft-ietf-behave-p2p-state-06.txt>
                State of Peer-to-Peer(P2P) Communication Across Network Address 
                Translators(NATs) 

Feb 2007 Nov 2007   <draft-ietf-behave-nat-behavior-discovery-02.txt>
                NAT Behavior Discovery Using STUN 

Nov 2007 Nov 2007   <draft-ietf-behave-turn-tcp-00.txt>
                Traversal Using Relays around NAT (TURN) Extensions for TCP 
                Allocations 

Dec 2007 Dec 2007   <draft-ietf-behave-stun-test-vectors-00.txt>
                Test vectors for STUN 

 Request For Comments:

  RFC   Stat Published     Title
------- -- ----------- ------------------------------------
RFC4787BCP  Jan 2007    Network Address Translation (NAT) Behavioral 
                       Requirements for Unicast UDP