Hi all, very interesting draft. I think it would be worthwhile to elaborate a bit more in the draft why Teredo is not viable and thus an alternative is needed.
In this draft, I see 2 issues described for Teredo: 1) "clients sometimes believing that they have Teredo connectivity when in fact they don't" Clients could have the same issue in 6a44 AFAIK. There is no mechanism in 6a44 to check the data path connectivity. I think the real issue here is lack of reliable teredo relay or lack of reliable data path (MTU issues). 2) "Teredo server and relay being very remote" Both issues can be fixed if ISPs deploy their own Teredo server/relay. Which is basically what they will do with 6a44. So, I don't really see the issues described in the paper as important enough to create another protocol. I do think there are other issues with Teredo: 1) Use of a WK prefix instead of an ISP prefix. This means the return path can be broken as with 6to4. 2) Most client Teredo implementation need a full cone NAT on the CPE. Most CPE use symmetric NAT. so a CPE upgrade could be needed. 3) Most OS still prefer IPv4 over Teredo. This means it does not increase the Ipv6 traffic. 4) On vista, it seems that traffic is sent to a Teredo tunnel only if another Ipv6@ is created (I didn't check this though). Source: http://yorickdowne.wordpress.com/2008/01/26/ipv6-at-home-part-1-overview-teredo/ /Olivier > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Brian E Carpenter > Sent: Tuesday, October 05, 2010 9:51 PM > To: Softwires > Cc: [email protected] > Subject: Re: [Softwires] ISP support of Native IPv6 across NAT44 CPEs - > Proposed 6a44 Specification > > On 2010-10-05 22:26, Rémi Després wrote: > > Hi all, > > > > 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). > > 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
