Olivier, Rémi has mainly answered you. In particular, the operational problems caused by missing Teredo servers don't just harm the customers of the ISP concerned; like missing 6to4 relays, they also harm customers of *other* ISPs. 6a44 doesn't have this problem.
> 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. I believe that a separate draft on "operational problems with Teredo" would be useful (in v6ops, most likely). Personally, I'd rather keep the 6a44 draft more focussed. Regards Brian On 2010-10-07 16:21, Olivier Vautrin wrote: > 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: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On >> Behalf Of Brian E Carpenter >> Sent: Tuesday, October 05, 2010 9:51 PM >> To: Softwires >> Cc: v4tov6transit...@ietf.org >> 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 >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
