[v4v6interim] [Fwd: [BEHAVE] Proposal for new BEHAVE charter]

[Magnus Westerlund <[e-mail]>]

The attached message was just sent to BEHAVE. Please send any comments
to BEHAVE.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

--- Begin Message ---

Hi,

Together with the chairs I have drafted a new BEHAVE charter that is on
the agenda for next weeks IESG telechat for decision if it should go for
formal review. However, I like to share it with you already now so that
you can comment on it early. The goal is to have this charter in place
before Minneapolis so that the Translation work can go forward.
Therefore, resolving comments early reduced the risk in hiccups in this
process.

To make this possible we have so far excluded any specific work items on
port-borrowing or other solutions to the dual stack lite problem. BEHAVE
will be home for this discussion until it has become clear on what we
really need to do here. At that point we will make a new recharter
action to where that work would fit. It is after all likely that part of
that work belongs in other WGs.

So please provide your view on the draft charter!


Draft charter proposal submitted to IESG

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 that is usable with both IPv4 and
IPv6, and capable of relaying between the two IP versions.

The goal of this work is to encourage migration to IPv6 and compliance
with the UNSAF [RFC 3424] considerations. 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 with the V6ops WG in this work.

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

1. MY IPv6 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 MY IPv4, 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 services is intended to service a specific IPv4 network
   using either private or public IPv4 addresses. Because this scenario
   has different constraints compared to (1), the WG should attempt to
   design a simpler solution with less impact on applications.

3. MY IPv4 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 MY IPv6, 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.

All translation solutions shall be capable of handling flows using TCP,
UDP, DCCP, and SCTP. The fundamental parts of ICMP are also required to
work. Additional protocols directly on top of IP may be supported.
Translation mechanisms must handle 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.

Milestones:

Done	Submit BCP that defines unicast UDP behavioral requirements for
        NATs to IESG
Done	Submit a BCP that defines TCP behavioral requirements 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 08	Submit standards-track relay protocol to IESG

Dec 08	Submit BCP document for SCTP NAT behavior

Jan 09  Determine relative prioritization of the four translation cases.

Mar 09	Submit standards-track document for relaying of a TCP bytestream

Mar 09	Submit standard-track document of an IPv6 relay protocol to IESG

Mar 09  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.

Sep 09  Target for first solution to be submitted to IESG.


-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave

--- End Message ---

_______________________________________________
v4v6interim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v4v6interim