Please see in line. Le 21 mars 2011 à 22:29, IESG Secretary a écrit :
> A modified charter has been submitted for the Softwires (softwire) > working group in the Internet 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 protected]) by Tuesday, March 29, 2011. > > Softwires (softwire) > --------------------------------------------------- > Current Status: Active Working Group > > Chairs: > Alain Durand <[email protected]> > Yong Cui <[email protected]> > > Internet Area Directors: > Ralph Droms <[email protected]> > Jari Arkko <[email protected]> > > Internet Area Advisor: > Ralph Droms <[email protected]> > > Mailing Lists: > General Discussion: [email protected] > To Subscribe: [email protected] > Archive: > http://www.ietf.org/mail-archive/web/softwires/current/maillist.html > > Description of Working Group: > > The Softwires Working Group is specifying the standardization of > discovery, control and encapsulation methods for connecting IPv4 > networks across IPv6 networks and IPv6 networks across IPv4 networks > in a way that will encourage multiple, inter-operable > implementations. > > For various reasons, native IPv4 and/or IPv6 transport may not be > available in all cases, and there is a need to tunnel IPv4 in IPv6 > or IPv6 in IPv4 to cross a part of the network which is not IPv4 or > IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies > two distinct topological scenarios that the WG will provide > solutions for: "Hubs and Spokes" and "Mesh." In the former case, > hosts or "stub" networks are attached via individual, > point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a > centralized Softwire Concentrator. In the latter case (Mesh), > network islands of one Address Family (IPv4 or IPv6) are connected > over a network of another Address Family via point to multi-point > softwires among Address family Border Routers (AFBRs). > > The WG will reuse existing technologies as much as possible and only > when necessary, create additional protocol building blocks. > > For generality, all base Softwires encapsulation mechanisms should > support all combinations of IP versions over one other (IPv4 over > IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 > translation mechanisms (NAT-PT), new addressing schemes, and block > address assignments are out of scope. DHCP options developed in this > working group will be reviewed jointly with the DHC WG. RADIUS > attributes developed in this working group will be reviewed jointly > with the RADEXT WG. The MIB Doctors directorate will be asked to > review any MIB modules developed in the SOFTWIRE working group. BGP > and other routing and signaling protocols developed in this group > will be reviewed jointly with the proper working groups and other > workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, > etc). > > The specific work areas for this working group are: > > 1. Developments for Mesh softwires topology; the Mesh topology work > will be reviewed in the l3vpn and idr WGs > - multicast > - MIB module > > 2. Developments for 6rd: > - multicast > - operational specification > - RADIUS option for 6rd server > - MIB module > > 3. Developments for Dual-Stack Lite (DS-Lite): > - multicast > - operational specification > - RADIUS option for AFTR > - proxy extensions; GI-DS-Lite; > DS-Lite with no NAT or NAT on the B4 element The DS-lite draft is clear that "the dual-stack lite model is built on IPv4-in-IPv6 tunnels to cross the network to reach a carrier-grade IPv4-IPv4 NAT (the AFTR)" "DS-Lite with no NAT or NAT on the B4 element" is therefore a self-contradiction. IMHO, these confusing words should be deleted from the new charter. Note that with 4rd included in the charter (a complement having received substantial support), the solution space does include a CGN-less solution. Regards, RD > - MIB module > > 4. Finalize discovery and configuration mechanisms for a gateway to > use DS-Lite or 6rd; these discovery and configuration mechanisms > must take into a account other operating environments such as > dual-stack and tunneling mechanisms not defined by the softwire > WG. Development of new mechanisms will involve the dhc and/or > v6ops WGs as appropriate > > Other work items would require WG approval and rechartering. > > Goals and Milestones: > Apr 2011 Submit DS-lite RADIUS option for Proposed Standard > Apr 2011 Adopt DS-lite operational document as WG document > Jul 2011 Submit 6rd RADIUS option for Proposed Standard > Jul 2011 Submit GI DS-lite for Proposed Standard > Jul 2011 Adopt B4NAT as WG document > Aug 2011 Adopt 6rd operational document as WG document > Aug 2011 Adopt Multicast extensions document as WG document > Aug 2011 Submit DS-lite operational document for Informational > Sep 2011 Submit B4NAT for Informational > Nov 2011 Submit Multicast extensions document for Informational > Nov 2011 Submit 6rd operational document for Informational > Nov 2011 Adopt 6rd MIB module as WG document > Nov 2011 Adopt DS-lite MIB module as WG document > Nov 2011 Adopt Mesh topology MIB module as WG document > Nov 2012 Submit 6rd MIB module for Proposed Standard > Nov 2012 Submit DS-lite MIB module for Proposed Standard > Nov 2012 Submit Mesh topology MIB module for Proposed Standard > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
