Hi Peng,
2011/4/20 Peng Wu <[email protected]>: > Hi Satoru, > > About the item DS-Lite with no NAT or NAT on the B4, it's DS-lite without CGN > on the AFTR. > Generally B4 will get public IPv4 address allocated from the ISP and use it > for IPv4 access. The AFTR will only need to maintain IPv6-IPv4 address > mapping without port information. > Doing this the addressing and routing between IPv6 and IPv4 are still > independent. It's a protocol extenstion to DS-lite, and it can work along > with DS-lite. So you mean that your 4over6 document is a B4NAT document, isn't it? But I don't find any B4NAT definition in your document though. On the other hand, I understand that you propose another 4over6 deployment model, which you don't need to use ds-lite terminology. You already define 4over6 initiator and concentrator, etc., So I think that using "B4NAT" makes confusion. > > We've already present it in last three IETF meetings. See > http://tools.ietf.org/html/draft-cui-softwire-host-4over6-04. The general > idea is out there, and the only confusion is that the mechanism name hasn't > matched yet. > We'll come up with a new version with evolvement before next IETF for WG > adoption. I'm confused because current ds-lite document clearly define as follow in section 4.2: "A DS-Lite CPE SHOULD NOT operate a NAT function between an internal interface and a B4 interface, as the NAT function will be performed by the AFTR in the service provider's network. That will avoid accidentally operating in a double NAT environment." And section 5.1 describes as follow: "5. B4 element 5.1. Definition The B4 element is a function implemented on a dual-stack capable node, either a directly connected device or a CPE, that creates a tunnel to an AFTR." These mean that B4 is equal to CPE, so that B4 cannot has NAT function. Is that correct? Best regards, --satoru > > > ------------------ > Peng Wu > PhD candidate > Department of Computer Science & Technology > Tsinghua University, Beijing, China > > ------------------------------------------------------------- > From:Satoru Matsushima > Date:2011-04-20 14:33:47 > To:iesg > CC:softwires; cuiyong > Subject:Re: [Softwires] WG Review: Recharter of Softwires (softwire) > >>Hello, >> >>I have some comments for the recharter text. >> >>> 4. Developments for stateless legacy IPv4 carried over IPv6 >> >>What does "legacy" mean? >>I think that no adjective needs to what IPv4 is. >> >>> - develop a solution motivation document to be published as an >>> RFC >>> - develop a protocol specification response to the solution >>> motivation >>> document; this work item will not be taken through WG last call >>> until the solution motivation document has been published >> >>It is unclear for the milestone to indicate this item. I think that >>the milestone should explicitly include the schedule for both solution >>motivation document and protocol specification for stateless solution. >>Here's one proposal: >> >>Jul 2011 Submit solution motivation document for Stateless IPv4 over >>IPv6 for Informational >>Jul 2011 Adopt Stateless IPv4 over IPv6 protocol specification as WG document >>Nov 2011 Submit Stateless IPv4 over IPv6 protocol specification for >>Proposed Standard >> >>> Sep 2011 Submit B4NAT for Informational >> >>I don't understand what B4NAT is. Is there any discussion about B4NAT >>in softwires WG so far? >>If not, it hasn't appropriate yet that the charter includes B4NAT as an item. >> >> >>Best regards, >>--satoru >> >> >>2011/4/20 IESG Secretary <[email protected]>: >>> 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, April 26, 2011. >>> >>> >>> Softwires (softwire) >>> **DRAFT 2011-04-14** (v03) >>> -------------------- >>> Current Status: Active >>> >>> 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 >>> - MIB module >>> >>> 4. Developments for stateless legacy IPv4 carried over IPv6 >>> - develop a solution motivation document to be published as an >>> RFC >>> - develop a protocol specification response to the solution >>> motivation >>> document; this work item will not be taken through WG last call >>> until the solution motivation document has been published >>> >>> 5. 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 > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
