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

["Yiu L. Lee" <[e-mail]>]

Hi Fred,

This is an interesting idea, but I will argue this is as complex as L2TP
softwire. When Brian, Remi and I discussed, we would like to have a simple
and cost effective technology that could be deployed by SP w/o upgrading the
CPE. This double tunneling tech seems scary.

Thanks,
Yiu


On 10/6/10 7:21 PM, "Templin, Fred L" <[e-mail]> wrote:

> Hi Brian, 
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Brian E Carpenter
>> Sent: Wednesday, October 06, 2010 3:10 PM
>> To: Ole Troan
>> Cc: Softwires; [e-mail]
>> Subject: Re: [Softwires] ISP support of Native IPv6 across
>> NAT44 CPEs -Proposed 6a44 Specification
>> 
>> 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.
> 
> I agree that the tunnel endpoint device in the end user
> network needs to configure the 6a44 tunnel interface as a
> host interface, but if the device also configures another
> tunnel over *that* then the inner tunnel could be used as
> a router interface.
> 
> If you can bear with me for a moment (*), consider the 6a44
> tunnel as an underlying interface over which the tunnel
> endpoint device configures an IRON tunnel. Yes, that would
> make for nested encapsulations - in particular, the nesting
> would be IPv6-in-IPv6-in-UDP-in-IPv4. But, the inner tunnel
> could be used as a router interface to service a PI IPv6
> prefix. This would work even if the inner tunnel was
> configured over multiple underlying 6a44 tunnels - one
> each for each ISP the end user network connects to.
> 
> (*) Of course, the sticking point once again is the pesky
> tunnel MTU issue. 6a44 appears to be punting on MTU yet
> again and setting a static 1280 MTU. That means that there
> is not enough available MTU to configure another tunnel
> over the 6a44 tunnel without fragmentation. If 6a44 is
> already implementing a control message protocol as per
> the I-D, however, it could also add a 6a44 "Packet Too
> Big" control message and use the IRON/SEAL method for
> reporting fragmentation as a means for supporting path
> MTU discovery. If you'd like a more detailed discussion
> of this idea, let me know.
> 
> Thanks - Fred
> [e-mail]
> 
>> (Except for the idea in draft-lee-softwire-6rd-udp of a tiny
>> relay plugged into the customer LAN.)
>> 
>>      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