datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Behavior Engineering for Hindrance Avoidance
charter-ietf-behave-06

Snapshots: 06 06-00 07
Snapshot of Charter for "Behavior Engineering for Hindrance Avoidance" (behave) WG
WG State: Concluded
Charter State:
Responsible AD: none

Send notices to: none
Last updated: 2004-09-27

Other versions: plain text

Charter charter-ietf-behave-06

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.