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) Ietfdbh@xxxxxxxxxxx +1-603-828-1401 On 5/25/12 6:30 PM, "Cullen Jennings" <fluffy@xxxxxx> wrote: > >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 (iesg@xxxxxxxx) by Tuesday, May >>22, 2012. >> >> Behavior Engineering for Hindrance Avoidance (behave) >> ----------------------------------------------------- >> Current Status: Active >> Last updated: 2012-05-10 >> >> Chairs: >> Dan Wing <dwing@xxxxxxxxx> >> Dave Thaler <dthaler@xxxxxxxxxxxxx> >> >> Transport Area Directors: >> Wesley Eddy <wes@xxxxxxxxxxxxxxx> >> Martin Stiemerling <martin.stiemerling@xxxxxxxxx> >> >> Transport Area Advisor: >> Wesley Eddy <wes@xxxxxxxxxxxxxxx> >> >> Mailing Lists: >> General Discussion: behave@xxxxxxxx >> 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) > >_______________________________________________ >Behave mailing list >Behave@xxxxxxxx >https://www.ietf.org/mailman/listinfo/behave