Re: [v4v6interim] Proposal for new BEHAVE charter

[Margaret Wasserman <[e-mail]>]

I support this work, and I think the behave WG is the right place to  
do it.

I have  few comments in-line...

On Oct 17, 2008, at 4:58 AM, Magnus Westerlund wrote:
>
> 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.

Is there a draft available on which this work will be based?  I'm not  
suggesting that you mention it in the charter, I'd just like to know  
which draft I should be reading for this item.

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

I think it should be made clearer here whether the translation  
documents will be written in the v6ops WG or behave.  I _think_ this  
is intended to say that the documents will be written in behave, and  
that the behave WG will get input and review regarding operational   
requirements and deployability from the v6ops WG, but I'd like to see  
that made clearer.

> 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

"MY" should be expanded or explained before it is first used.

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

I would also like to us write (at least) two NAT-related documents that
aren't listed here:

(1) A document that offers advice on how/when to deploy these  
translation
mechanisms vs. other choices.  I think this document would cover topics
such as:

	- If the infrastructure will support dual stack and you are running out
           of IPv4 addresses, NAT IPv4 and leave IPv6 alone.
	- The advantages of placing NATs closer to the edges of the network

(2) An explanation of how to do IPv6 <=> IPv6 NAT.  It am convinced that
there are some people who will choose to do this for the same reasons  
that
people with plenty of IPv4 addresses choose to use IPv4 <=> IPv4 NATs
today.  I think we could write a document that says something like:   
IPv6
<=> IPv6 NATs are not really necessary, don't provide any concrete  
advantages
that can't be obtained through less disruptive means, and are not  
recommended
by the IETF, but if you are planning to do this anyway, please do it  
right (don't
include port translation, use algorithmic address mapping if possible,  
instead
of state tables, etc.).

> 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
>
> _______________________________________________
> v4v6interim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v4v6interim

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