Le 7 oct. 2010 à 02:56, Yiu L. Lee a écrit : > 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.
Indeed. We need some reliable and easily deployable solutions for IPv6 use to become widespread, including in hosts behind legacy CPEs. Whether some more complex and more powerful models can be designed next is an open issue. IMHO, it MUST NOT delay in any way adoption of the simple scheme. RD > This double tunneling tech seems scary. > > Thanks, > Yiu > > > On 10/6/10 7:21 PM, "Templin, Fred L" <fred.l.temp...@boeing.com> wrote: > >> Hi Brian, >> >>> -----Original Message----- >>> From: softwires-boun...@ietf.org >>> [mailto:softwires-boun...@ietf.org] On Behalf Of Brian E Carpenter >>> Sent: Wednesday, October 06, 2010 3:10 PM >>> To: Ole Troan >>> Cc: Softwires; v4tov6transit...@ietf.org >>> 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 >> fred.l.temp...@boeing.com >> >>> (Except for the idea in draft-lee-softwire-6rd-udp of a tiny >>> relay plugged into the customer LAN.) >>> >>> 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 > > _______________________________________________ > v4tov6transition mailing list > v4tov6transit...@ietf.org > https://www.ietf.org/mailman/listinfo/v4tov6transition _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
