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

[Rémi Després <[e-mail]>]

Le 7 oct. 2010 à 05:21, Olivier Vautrin a écrit :

> 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.

One problem of Teredo is that, between two valid Teredo addresses, it can break with some NAT behaviors.
6a44 avoids that.

> There is no mechanism in 6a44 to check the data path connectivity.

For hosts that are on LANs behind NAT44-CPEs, there is no more IPv6 connectivity to be checked than between two any pair of hosts having native IPv6 addresses.

Yet, there seems to be be something to add about customer sites having internally cascaded NATs, something like: 
NATs that are cascaded behind CPE NATs should disable the 6a44 well-nown port W for incoming packets.
This can be done by a port mapping to an address that doesn't belong to the set of DHCP assigned addresses.
  

> 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.

Do you mean ALL ISPs? If yes, it isn't a practical solution.
Besides, do you suggest that IPv6 sensor devices that need the incoming connectivity that IPv6 can restore would have to support Teredo?

> Which is basically what they will do with 6a44.

The point of 6a44 is that each ISP can incrementally deploy the solution (like 6rd, or also the 4rd that both of us proposed ;-))

> 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/

It shouldn't be long to developer who knows 6to4 under Linux to implement 6a44. 
It's a new protocol, yes, but a very simple one to implement and to operate.

Regards,
RD

> 
> /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
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires