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" <[email protected]> wrote: > Hi Brian, > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Brian E Carpenter >> Sent: Wednesday, October 06, 2010 3:10 PM >> To: Ole Troan >> Cc: Softwires; [email protected] >> 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 > [email protected] > >> (Except for the idea in draft-lee-softwire-6rd-udp of a tiny >> relay plugged into the customer LAN.) >> >> 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
