* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Behave Status Pages

Behavior Engineering for Hindrance Avoidance (Concluded WG)
Tsv Area: Mirja K├╝hlewind, Magnus Westerlund | 2004-Sep-29 — 2013-Oct-17 
Chairs
 
 


2013-08-22 charter

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

 Charter

 Current Status: Active

 Chairs:
     Dan Wing <dwing@cisco.com>
     Dave Thaler <dthaler@microsoft.com>

 Transport Area Directors:
     Spencer Dawkins <spencerdawkins.ietf@gmail.com>
     Martin Stiemerling <mls.ietf@gmail.com>

 Transport Area Advisor:
     Spencer Dawkins <spencerdawkins.ietf@gmail.com>

 Mailing Lists:
     General Discussion: behave@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/behave
     Archive:            http://www.ietf.org/mail-archive/web/behave

Description of Working Group:

  The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4
  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.  BEHAVE will coordinate on this topic
  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 finish four scenarios: (1) An IPv6 network to IPv4
  Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network
  to an IPv4 network, and (4) an IPv4 network to an IPv6 network.

  Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be
  consistent with the management aspects of its IPv6/IPv4 NAT solutions,
  and specify IPFIX information elements to meet logging requirements,
  reusing existing elements, if possible.

  In addition, when a NAT (such as a NAT64 in the "An IPv6 network to
  IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber
  fairness issues arise.  As such, BEHAVE will complete its work on
  Carrier Grade NAT requirements for such scenarios, and update the NAT
  MIB as needed to meet such requirements.  BEHAVE will not, however,
  standardize IPv4-specific behavioral mechanisms.

  The following scenarios remain in scope for discussion, but will not be
  solved by BEHAVE:

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

  This group will also provide reviews of any work by the MBoneD WG on
  multicast translation, including control traffic (IGMP and MLD),  Single
  Source Multicast (SSM) and Any Source Multicast (ASM).

  If the WG deems it necessary, BEHAVE will revise RFCs previously
  published by BEHAVE.


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
  Done     - Submit to IESG:  FTP ALG for IPv6/IPv4 translation (std)
  Done     - Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 translation (info)
  Done     - Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std)
  Jul 2012 - Submit to IESG:  large scale NAT requirements (BCP)
  Jul 2012 - Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std)
  Nov 2012 - Submit to IESG: updates to NAT MIB for NAT64 (std)
  Nov 2012 - Submit to IESG: updates to NAT MIB for CGNs (std)
  Nov 2012 - Submit to IESG: IPFIX information elements (std)


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/behave/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -