Subject: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave)

From: IESG Secretary <[email-masked]>
Date: Tue, 15 May 2012 10:53:24 -0700

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 ([email-masked]) by Tuesday, May 22, 2012.

Behavior Engineering for Hindrance Avoidance (behave)
-----------------------------------------------------
Current Status: Active
Last updated: 2012-05-10

 Chairs:
     Dan Wing <[email-masked]>
     Dave Thaler <[email-masked]>

 Transport Area Directors:
     Wesley Eddy <[email-masked]>
     Martin Stiemerling <[email-masked]>

 Transport Area Advisor:
     Wesley Eddy <[email-masked]>

 Mailing Lists:
     General Discussion: [email-masked]
     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. 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 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 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 
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) 
Jul 2012  Submit to IESG: large scale NAT requirements (BCP) 
Done	Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 
        translation (info)
Jul 2012  Submit to IESG: avoiding NAT64 with dual-stack host for 
          local networks (std) 
Done    Submit to IESG: host-based NAT46 translation for IPv4-only 
        applications to access IPv6-only servers (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)

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 16 May 2012 10:16:01 -0400

Doing a visual diff from the 25 Feb 2012 charter. . .

> The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function
> in as deterministic a fashion as possible.

That's a new sentence.  We now have two WGs chartered to work on NAT44: BEHAVE and
sunset4.  How do I know what kind of contribution should go to which group?

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

Good.

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

So we can talk about them, as long as we don't try to solve problems?
Where does problem-solving happen, then?  Again, I'm just confused about the scope here.

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

This language is better than the old version.

> If the WG deems it necessary, BEHAVE will revise RFCs previously published by
> BEHAVE.
>
> Goals and Milestones
...
> Jul 2012  Submit to IESG: large scale NAT requirements (BCP)

I guess sunset4 better hurry up with the review in its charter, then.

> Nov 2012  Submit to IESG: IPFIX information elements (std)

Lee

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 25 May 2012 16:30:47 -0600

WIll the IPFIX and MIB  work also be usable by v4 to v4 NATs?

---

From: David Harrington <[email-masked]>
Date: Sat, 26 May 2012 01:00:29 -0400

Hi Cullen,

I would assume the MIB module would be written in a way to be IP version
agnostic.
But I'm not sure the NAT technologies are version agnostic.
And I'm not sure that the current NAT-MIB can support the version-agnostic
addressing textual conventions (I haven't looked yet).

I have similar expectations regarding ipfix IEs.

--
David Harrington
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401

On 5/25/12 6:30 PM, "Cullen Jennings" <[email-masked]> wrote:

>> 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 ([email-masked]) by Tuesday, May
>>22, 2012.
>> 
>_______________________________________________
>Behave mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/behave

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 May 2012 09:35:18 -0400

> WIll the IPFIX and MIB  work also be usable by v4 to v4 NATs?

Speaking as an author of draft-ietf-behave-nat-mib, our intent is to 
support all kinds of NAT, but it isn't clear yet whether it will be done 
in multiple drafts or a single one. There is stuff that is common to all 
NAT no matter the IP version, and there stuff that is IP version specific.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca