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

 Charter
 Last Modified: 2010-09-02

 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>
     Wesley Eddy  <wes@mti-systems.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 working group creates documents to enable NATs to function in as 
deterministic a fashion as possible.

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.

BEHAVE will adopt additional work items to finish four scenarios:
An IPv6 network to IPv4 Internet, IPv6 Internet to an IPv4 network, 
An IPv6 network to an IPv4 network, and An IPv4 network to an 
IPv6 network.  These additional work items include suggestions to
application developers to improve application interactions with
those translation scenarios.

The following scenario remains in scope for discussion, and new
milestones can be created to address this scenario:

* An IPv4 application running on an IPv6-only connected host to the
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 embedded
in the IPv4 host.

The following scenarios remain in scope for discussion, but creating
new milestones will require re-chartering:

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

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

* multicast translation, including control traffic (IGMP and MLD), 
Single Source Multicast (SSM) and Any Source Multicast (ASM).

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.

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.

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. 

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

   Done         Submit to IESG: relay protocol (std) 

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

   Done         Submit to IESG: IPv6 relay protocol (std) 

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

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

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

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

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

   Done         Determine need and scope of multicast 6/4 translation 

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

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

   Feb 2011       Submit to IESG: Analysis of NAT-PT considerations with 
                IPv6/IPv4 translation (info) 

   Apr 2011       Submit to IESG: avoiding NAT64 with dual-stack host for local 
                networks (std) 

   Apr 2011       Submit to IESG: SCTP NAT behavior (BCP) 

   Apr 2011       Submit to IESG: NAT64 load balancing (std/info) 

   Apr 2011       Submit to IESG: host-based NAT46 translation for IPv4-only 
                applications to access IPv6-only servers (std) 


 Internet-Drafts:

Posted Revised         I-D Title   <Filename>
------ ------- --------------------------------------------
Oct 2008 Dec 2010   <draft-ietf-behave-sctpnat-04.txt>
                Stream Control Transmission Protocol (SCTP) Network Address 
                Translation 

Dec 2009 May 2011   <draft-ietf-behave-ftp64-09.txt>
                An FTP ALG for IPv6-to-IPv4 translation 

Oct 2010 Apr 2011   <draft-ietf-behave-v4v6-bih-04.txt>
                Dual Stack Hosts Using "Bump-in-the-Host" (BIH) 

Oct 2010 Mar 2011   <draft-ietf-behave-lsn-requirements-01.txt>
                Common requirements for IP address sharing schemes 

Jan 2011 May 2011   <draft-ietf-behave-64-analysis-02.txt>
                Analysis of 64 Translation 

 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 

RFC6052 PS   Oct 2010    IPv6 Addressing of IPv4/IPv6 Translators 

RFC6062 PS   Nov 2010    Traversal Using Relays around NAT (TURN) Extensions for 
                       TCP Allocations 

RFC6144 I    Apr 2011    Framework for IPv4/IPv6 Translation 

RFC6145 PS   Apr 2011    IP/ICMP Translation Algorithm 

RFC6146 PS   Apr 2011    Stateful NAT64: Network Address and Protocol Translation 
                       from IPv6 Clients to IPv4 Servers 

RFC6147 PS   Apr 2011    DNS64: DNS extensions for Network Address Translation 
                       from IPv6 Clients to IPv4 Servers 

RFC6156 PS   Apr 2011    Traversal Using Relays around NAT (TURN) Extension for 
                       IPv6