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
