Agree because 6a44 address schema won't generate a prefix shorter than /64. Let's put the technology aside. The ultimate question is: "Will O/S vendors be willing to consider to implement another tunnel protocol on the host?"
On 10/6/10 6:10 PM, "Brian E Carpenter" <[email protected]> wrote: > On 2010-10-06 19:57, Ole Troan wrote: >> Brian, >> >>>> Draft-despres-softwire-6a44-00, coauthored with Brian and Sheng, has just >>>> been posted (http://tools.ietf.org/html/draft-despres-softwire-6a44-00). >>>> It describes a solution for ISPs to offer native IPv6 across IPv4-only CPEs >>>> (NAT44 CPEs). >>>> >>>> It results from convergence discussion between authors of >>>> draft-carpenter-6man-sample-00 and draft-despres-softwire-6rdplus-00, >>>> taking into account comments made by authors of >>>> draft-lee-softwire-6rd-udp-01, and those made other Softwire WG >>>> participants since IETF 78. >>>> >>>> It is submitted to become, after discussion in the WG, a Softwire I-D. >>> By the way, we do discuss in the draft why it's a useful alternative to >>> both tunnel brokers (such as Hexago and SixXs) or Teredo. We don't >>> explicitly discuss why we think it's also a useful alternative to an L2TP >>> solution, but the arguments are, I think, similar to those for the tunnel >>> brokers (apart from our "hobbyist" comment). >> >> perhaps you could also add some deployment considerations with regards to >> host tunneling versus "network" tunneling? > > OK, if there is enough interest to continue this work. Of course, in the > context of legacy CPE, there is no alternative to host tunnels. > (Except for the idea in draft-lee-softwire-6rd-udp of a tiny > relay plugged into the customer LAN.) > > Brian > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
