Re: [v4tov6transition] [Softwires] ISP support of Native IPv6 across NAT44 CPEs - Proposed 6a44 Specification

[Brian E Carpenter <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Brian E Carpenter
>> Sent: Tuesday, October 05, 2010 9:51 PM
>> To: Softwires
>> Cc: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires