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

 Charter
 Last Modified: 2010-07-13

 Current Status: Active Working Group

 Chair(s):
     Dan Wing  <dwing@cisco.com>
     Dave Thaler  <dthaler@microsoft.com>

 Transport Area Director(s):
     David Harrington  <ietfdbh@comcast.net>
     Lars Eggert  <lars.eggert@nokia.com>

 Transport Area Advisor:
     David Harrington  <ietfdbh@comcast.net>

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

Description of Working Group:

The behavior of NATs varies 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 applications where one or both
end-points are behind a NAT, such as multiuser games, interactive
multimedia and P2P download.

The working group documents best current practices to enable NATs to 
function in as deterministic a fashion as possible. The NAT behavior 
practices will be application independent. This has already completed 
for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any 
additional protocol deemed necessary to handle. The WG has documented 
approaches for characterizing and testing NAT devices.

BEHAVE will develop protocol-independent toolkits usable by application 
protocols for NAT traversal. The WG has already produced an update of 
the binding discovery protocol STUN. It will now produce a relay 
protocol that focuses on security and is usable with both IPv4 and IPv6, 
and capable of relaying between the two IP versions.

Due to the WG's experience with translators and their behavior it has 
been given the following tasks to help encourage migration to IPv6. To 
support deployments where communicating hosts require using different 
address families (IPv4 or IPv6), address family translation is 
needed to establish communication. In BEHAVE's specification work on 
this topic it will coordinate with the V6ops WG on requirements and 
operational considerations.

"An IPv4 network" or "an IPv6 network" in the descriptions below refer 
to a network with a clearly identifiable administrative domain (e.g., an 
enterprise campus network, a mobile operator's cellular network, a 
residential subscriber network, etc.). It will also be that network that 
deploys the necessary equipment for translation.

The BEHAVE WG will design solutions for the following six translation
scenarios; other scenarios are out of scope:

1. An IPv6 network to IPv4 Internet, i.e. perform translation between 
IPv4 and IPv6 for packets in uni- or bi-directional flows that are 
initiated from an IPv6 host towards an IPv4 host. The translator 
function is intended to service a specific IPv6 network of arbitary 
size. Port translation is necessary on the IPv4 side for efficient IPv4 
address usage.

2. IPv6 Internet to an IPv4 network, i.e. perform translation between 
IPv4 and IPv6 for packets in uni- or bi-directional flows that are 
initiated from an IPv6 host towards an IPv4 host. The translator 
function is intended to service a specific IPv4 network using either 
private or public IPv4 addresses. This scenario has different 
constraints compared to (1), e.g. the IPv4 hosts that are to be 
reachable over IPv6 can be enumerated. Therefore, the WG should attempt 
to design a simpler solution with less impact on applications.

3. An IPv4 network to IPv6 Internet, i.e. perform translation between 
IPv4 and IPv6 for packets in uni- or bi-directional flows that are 
initiated from an IPv4 host towards an IPv6 host. The translator 
function is intended to service a specific IPv4 network using either 
public or private IPv4 address space.

4. IPv4 Internet to an IPv6 network, i.e. perform translation between 
IPv4 and IPv6 for packets in uni- or bi-directional flows that are 
initiated from an IPv4 host towards an IPv6 host. The translator 
function is intended to service a specific IPv6 network where selected 
IPv6 hosts and services are to be reachable.

5. An IPv6 network to an IPv4 network, i.e., perform translation between 
IPv6 and IPv4 for packets in uni- or bi-directional flows that are 
initiated from an IPv6 host towards an IPv4 host.  The translation 
function is intended to service a specific IPv6 network of arbitrary 
size and a specific IPv4 network of arbitrary size (neither of which are 
the Internet).

6. An IPv4 network to an IPv6 network, i.e., perform translation between 
IPv4 and IPv6 for packets in uni- or bi-directional flows that are 
initiated from an IPv4 host towards an IPv6 host.  The translation 
function is intended to service a specific IPv6 network of arbitrary 
size and a specific IPv4 network of arbitrary size (neither of which are 
the Internet).

All translation solutions shall be capable of handling flows using TCP, 
UDP, DCCP, and SCTP, unless they prevent a timely completion of the work 
item. The parts of ICMP that can be translated are also required to work 
across a translation solution.  Additional protocols directly on top of 
IP may be supported. Translation mechanisms must handle IP 
fragmentation.

The translators should support multicast traffic and its control traffic 
(IGMP and MLD) across them, both Single Source Multicast (SSM) and Any 
Source Multicast (ASM). However, the WG may determine that it becomes 
too complex or too difficult to realize with maintained functionality, 
for some or all cases of multicast functionality.

Translation mechanisms cannot transparently support protocols that embed 
network addresses within their protocol messages without application 
level gateways (ALGs). Because ALGs have security issues (like blocking 
usage of TLS), are error prone and brittle, and hinder application 
development, the usage of ALGs in the defined translators should be 
avoided. Instead application developers will need to be aware and use 
mechanisms that handle the address family translation. ALGs may be 
considered only for the most crucial of legacy applications.

DNS is a crucial part in making a large number of applications work 
across a translator. Thus the solution to the above translation cases 
shall include recommendations for DNS. If additional DNS functionality 
is needed, it may be developed. Any DNS extensions must be developed 
together with the DNSEXT WG, including issuing a joint WG last call for 
any documents.

The WG needs to determine the best method for providing address space to 
a translator in the different deployment cases and documenting the pros 
and cons of the suggested approaches. The WG is to seek input from the 
Routing, Operations and Internet areas.

Solutions may solve more than one of the cases, however timely delivery
is more important than a unified solution.

 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 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 

   Done         Submit informational document for rfc3489bis test vectors 

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

   Done         Submit BCP document for DCCP NAT behavior 

   Done         Determine relative prioritization of the four translation 
                cases. Documented in IETF74 minutes. 

   Done         Determine what solutions(s) and components are needed to solve 
                each of the four cases. Create new milestones for the 
                solution(s) and the components. Documented in IETF74 minutes. 

   Sep 2009       Submit to IESG: relaying of a TCP bytestream (std) 

   Done         Submit to IESG: relay protocol (std) 

   Done         Submit to IESG: TURN-URI document (std) 

   Dec 2009       Submit to IESG: SCTP NAT behavior (BCP) 

   Dec 2009       Submit to IESG: IPv6 relay protocol (std) 

   Dec 2009       Submit to IESG: framework for IPv6/IPv4 translation (info) 

   Dec 2009       Submit to IESG: stateless IPv6/IPv4 translation (std) 

   Dec 2009       Submit to IESG: stateful IPv6/IPv4 translation (std) 

   Dec 2009       Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) 

   Jan 2010       Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) 

   Jan 2010       Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) 

   Mar 2010       Submit to IESG: large scale NAT requirements (BCP) 


 Internet-Drafts:

Posted Revised         I-D Title   <Filename>
------ ------- --------------------------------------------
Mar 2006 Jul 2010   <draft-ietf-behave-turn-ipv6-11.txt>
                Traversal Using Relays around NAT (TURN) Extension for IPv6 

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

Oct 2008 Jun 2010   <draft-ietf-behave-sctpnat-03.txt>
                Stream Control Transmission Protocol (SCTP) Network Address 
                Translation 

Jun 2009 Aug 2010   <draft-ietf-behave-v6v4-xlate-21.txt>
                IP/ICMP Translation Algorithm 

Jul 2009 Jul 2010   <draft-ietf-behave-dns64-10.txt>
                DNS64: DNS extensions for Network Address Translation from IPv6 
                Clients to IPv4 Servers 

Jul 2009 Jul 2010   <draft-ietf-behave-v6v4-xlate-stateful-12.txt>
                Stateful NAT64: Network Address and Protocol Translation from 
                IPv6 Clients to IPv4 Servers 

Jul 2009 Aug 2010   <draft-ietf-behave-v6v4-framework-10.txt>
                Framework for IPv4/IPv6 Translation 

Aug 2009 Aug 2010   <draft-ietf-behave-address-format-10.txt>
                IPv6 Addressing of IPv4/IPv6 Translators 

Dec 2009 Jul 2010   <draft-ietf-behave-ftp64-04.txt>
                IPv6-to-IPv4 translation FTP considerations 

 Request For Comments:

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

RFC5135BCP  Feb 2008    IP Multicast Requirements for a Network Address 
                       Translator (NAT) and a Network Address Port Translator 
                       (NAPT) 

RFC5128 I    Mar 2008    State of Peer-to-Peer(P2P) Communication Across Network 
                       Address Translators(NATs) 

RFC5382BCP  Oct 2008    NAT Behavioral Requirements for TCP 

RFC5389 PS   Oct 2008    Session Traversal Utilities for NAT (STUN) 

RFC5508BCP  Apr 2009    NAT Behavioral Requirements for ICMP 

RFC5597BCP  Sep 2009    Network Address Translation (NAT) Behavioral 
                       Requirements for the Datagram Congestion Control 
                       Protocol 

RFC5766 PS   Apr 2010    Traversal Using Relays around NAT (TURN): Relay 
                       Extensions to Session Traversal Utilities for NAT (STUN) 

RFC5769 I    Apr 2010    Test Vectors for Session Traversal Utilities for NAT 
                       (STUN) 

RFC5780 E    May 2010    NAT Behavior Discovery Using Session Traversal Utilities 
                       for NAT (STUN) 

RFC5928 PS   Aug 2010    Traversal Using Relays around NAT (TURN) Resolution 
                       Mechanism