On 9/28/10 4:28 AM, Brian E Carpenter wrote: > On 2010-09-28 15:09, Yiu L. Lee wrote: >> Hi Washam, >> >> Don't forget there are also Softwire Hub-and-Spoke (L2TPv2 based) and 6rd+. >> So far, we don't hear much response to support this work in the operator's >> community. > > One reason is that the smaller, more agile ISPs with problems > in this area are simply figuring out how to deal with Teredo, > e.g. with Tui boxes, http://www.braintrust.co.nz/tui/
Oh yeah, that one too. > > IMNSHO, cumbersome solutions like L2TPv2 will only appeal to telco-like > operators. L2TP is often the NNI which allows a challenger ISP to setup service to subscribers where the "telco-like" incumbent owns the physical layer (in particular for remote locations where co-location might not be a reasonable option). So, it ends up in a lot of different types of ISPs, even those that do not have PPP anywhere else. The one place where it almost never ends up is at a DOCSIS cable operator, which is where I hear most of the resistance to its introduction. L2TP would and should lose a beauty contest with a brand new protocol created today (surely we would have learned something in 15 years!). However, on the concentrator side, virtually every SP vendor has an LNS offering, alongside open source options if you want to go that route. On the client side, it is in a number of RGs, pretty much every host OS, not to mention your iPhone, iPad, Android... It's everywhere. Why not just use it? PPP isn't *that* hard. - Mark > > Brian > >> >> Regards, >> Yiu >> >> >> On 9/27/10 9:49 PM, "WashamFan" <[email protected]> wrote: >> >>> Hi, >>> >>> Please see inline. >>> >>> ----- Original Message ----- >>> From: Brian E Carpenter <[email protected]> >>> Date: Tuesday, September 28, 2010 4:17 am >>> Subject: Re: [Softwires] comments on draft-carpenter-softwire-sample-00 >>> To: WashamFan <[email protected]> >>> Cc: [email protected] >>> >>> >>>> Hi, >>>> >>>> On 2010-09-27 21:05, WashamFan wrote: >>>>> Hi, >>>>> >>>>> It says, >>>>> >>>>> The SAMPLE server will act as an IPv6 router. In the simplest case, >>>>> it will forward all IPv6 packets to a default route, except those >>>>> whose destination address lies within the PSAMPLE prefix, which >>>> will >>>>> be encapsulated and sent towards the host (CPE) and port >>>> indicated by >>>>> the V4ADDR and PN values. >>>>> >>>>> >>>>> I think it is not appropriate to assume NAT traversal without >>>>> relay can be always successful. >>>> >>>> I don't understand your comment. If you have a NAT that you cannot >>>> traverse with UDP, you have many other problems, not just a lack >>>> of IPv6 connectivity. >>> I misunderstood. I thought the text implies direct tunnels established >>> instead of hairpinning via SAMPLE server when SAMPLE client to >>> SAMPLE client communication occurs . >>> >>>>> Hairpinning might be always used >>>>> for simplicity. >>>> >>>> Yes, that is the SAMPLE model. And it's a discussion for the >>>> community whether or not this is acceptable. >>>> >>>>> I'd like to know the status of the draft, is the WG pursuing this >>>>> work? >>>> >>>> There are three drafts aiming at the same problem, SAMPLE, >>>> draft-lee-softwire-6rd-udp, and draft-despres-softwire-6rdplus. >>>> Please hold your breath, there's hope of a joint proposal >>>> from several authors within a few days. >>> Is it possible to combine all these efforts? I see 2 major >>> difference between draft-carpenter-softwire-sample-00 >>> and draft-lee-softwire-6rd-udp-02 at least: >>> >>> 1. According to the IPv6 address assignment, SAMPLE >>> is to connect isolated IPv6 hosts but 6rd-udp is to connect >>> both isolated IPv6 hosts and LANs. >>> >>> 2. They are different in terms of IPv6 address assignment >>> procedure. SAMPLE uses ND but 6rd-udp might use RADIUS, >>> let's say. >>> >>> Personally, I think it is meaningful to work on tunneling >>> IPv6 traversing NAT, but I think we should justify the work >>> by clarifying how bad Teredo did the job before we reinvent >>> the wheel. >>> >>> THanks, >>> washam >>> >>> >>>> 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
