Le 19 août 2011 à 17:11, Mark Townsley a écrit : > > On Aug 19, 2011, at 5:17 AM, Rémi Després wrote: > >> Also, one of his slides has "4rd aka Stateless DS-lite". He knows, as you >> know, that I had expressed strong opposition to this badly reductive view >> (DS lite is hub and spoke, has no NAT in CPE's, ...). > > Let me fill you in on some history. > > The term "Dual Stack Lite" came into being during a discussion at a cafe > between Alain Durand and I. It was June 2008, and Alain was in Paris for the > ICANN meeting while still working for Comcast. We had been discussing the > various pros and cons of tunneling vs. dual-translation for a while. Alain > was emphasizing that what was of most importance to him as an ISP, was that > he not be burdened with provisioning IPv4 within the ISP network itself. > However, in all cases the service to the subscriber was intended to be > dual-stack. So: "Dual-stack" service but "lighter" on the ISP in terms of > management and provisioning. Thus the term "dual-stack lite" was born.
That's a good clarification. But in the mean time, DS-lite got specified in an RFC that won't change. RFC6333 says: - "Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT)." - "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)," - etc. > From the beginning the "lite" term was about having less IPv4 in the access > network for the operator to manage and provision, while still providing > dual-stack service to the subscriber. 4rd fits that, as does RFC 6333. The > solution details are just that - details. The devil is in details. Too bad 4rd wasn't invented before DS-lite. It would have better deserved the "lite" qualifier, but that's not how things happened. Because of what RFC6333 says, suggesting NOW that solutions that don't need NATs are variants of DS-lite is a sure way to confuse people. I do hope this discussion will now stop: there are so many technical "details" that need to reach common understanding, and agreement. In any case thank you for the really interesting explanation on history. Cheers. RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
