Quiong, Clarifying what is meant by "stateless" in different contexts is highly desirable.
The objective of the 4rd address mapping is - no "per customer" state in provider nodes (BR, AFTR...) - direct customer-customer paths made possible The 'Lightweight 4over6' proposal has in my understanding a different objective: flexible port sets assignable to each individual customer. It can therefore coexist with one or both "per-sustomer-stateless" solution(s) (with encapsulation and/or double-translation). Hope it helps. Regards, RD Le 2 août 2011 à 08:11, Qiong a écrit : > Hi Lee, > > Thank you very much for your interests on 'lightweight 4over6'. > > In our consideration, lightweight AFTR is not doing port-range routing. In > this lightweight AFTR, it would firstly lookup a mapping table (recording > [IPv6 address, IPv4 address, Port set]) for a downstream IPv4 packet. Then > after IPv4 packet has been encapsulated into IPv6 packet, it will do IPv6 > routing based on different IPv6 addresses. So, lightweight AFTR does not need > to distribute port-set info into FIB and there is no impact on existing > routing architecture between B4 and AFTR. > > Actually, the basic idea behind 'lightweight 4over6' is to include addressing > sharing for 'public 4over6', and to enhance DS-Lite for better scalability. > It is a lightweight solution which only keeps customer-based state in AFTR > compared to DS-Lite. And there is also no IPv6 address format restriction and > no IPv6 routing impact on existing network infrastructure. We have > implemented a prototype in our commercial network and find it easy to deploy > in practice. > > With regard to so much stateful/stateless discussion, I think actually there > is no solution with totally stateless in the address sharing world. It is > only a matter of fact where to keep the states, either distributed in CPE or > centralized in the core CGN. Given the fact that most existing CPEs can > support NAT already, our solution is to keep less states in the Core CGN, > while keeping the simplicity of IPv6 addressing and routing. > > Sorry to make the discussion even more complicated. Your comments are more > than welcome. > > Thanks in advance. > > Best wishes > > > On Tue, Aug 2, 2011 at 1:18 AM, Lee, Yiu <[email protected]> wrote: > In this case, > http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt > could be (modified here) controversial because it will turn AFTR a PRR. > > On 8/1/11 7:07 AM, "Satoru Matsushima" <[email protected]> wrote: > > >If you imagine dynamic port ranges within stateless, it sounds like port > >range aware routing. I think that it would be controversial. > > _______________________________________________ > 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
