WIll the IPFIX and MIB work also be usable by v4 to v4 NATs?
On May 15, 2012, at 11:53 AM, IESG Secretary 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 (i...@ietf.org) by Tuesday, May 22, 2012. > > Behavior Engineering for Hindrance Avoidance (behave) > ----------------------------------------------------- > Current Status: Active > Last updated: 2012-05-10 > > Chairs: > Dan Wing <dw...@cisco.com> > Dave Thaler <dtha...@microsoft.com> > > Transport Area Directors: > Wesley Eddy <w...@mti-systems.com> > Martin Stiemerling <martin.stiemerl...@neclab.eu> > > Transport Area Advisor: > Wesley Eddy <w...@mti-systems.com> > > Mailing Lists: > General Discussion: beh...@ietf.org > 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)
