[MIB-DOCTORS] FW: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave)

["Romascanu, Dan (Dan)" <dromasca at avaya.com>]

-----Original Message-----
From: iesg-bounces at ietf.org [mailto:iesg-bounces at ietf.org] On Behalf Of
IESG Secretary
Sent: Tuesday, September 29, 2009 6:30 PM
To: ietf-announce at ietf.org
Cc: behave at ietf.org; dthaler at microsoft.com; dwing at cisco.com
Subject: WG Review: Recharter of Behavior Engineering for Hindrance
Avoidance (behave) 

A modified charter has been submitted for the Behavior Engineering for
Hindrance Avoidance (behave) working group in the Transport Area of the
IETF.  The IESG has not made any determination as yet.  The modified
charter is provided below for informational purposes only.  Please send
your comments to the IESG mailing list (iesg at ietf.org) by Tuesday,
October 6, 2009.

Behavior Engineering for Hindrance Avoidance (behave)
-----------------------------------------------------
Current Status: Active Working Group
Last Modified: 2009-09-09

Current Status: Active Working Group

Additional information is available at tools.ietf.org/wg/behave
Chair(s):

    * Dan Wing <dwing at cisco.com>
    * Dave Thaler <dthaler at microsoft.com>

Transport Area Director(s):

    * Magnus Westerlund <magnus.westerlund at ericsson.com>
    * Lars Eggert <lars.eggert at nokia.com>

Transport Area Advisor:

    * Magnus Westerlund <magnus.westerlund at ericsson.com>

Mailing Lists:
  General Discussion: behave at ietf.org
  To Subscribe: behave-request at 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
Dec 2009  Submit to IESG: SCTP NAT behavior (BCP)
Done      Submit to IESG: relay protocol (std)
Done      Determine relative prioritization of the four translation 
cases. Documented in IETF74 minutes.
Sep 2009  Submit to IESG: relaying of a TCP bytestream (std) Dec 2009
Submit to IESG: IPv6 relay protocol (std)
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:  TURN-URI document (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)