Subject: RE: [Softwires] Notes and Consensus from Interim Meeting in Hong Kong

From: "Bill Storer \(bstorer\)" <[email-masked]>
Date: Wed, 15 Mar 2006 08:54:46 -0800

To summarize here:

1. None of the proposed solutions are supported by standard issue "out of the box" Microsoft Windows.  All of the solutions will require loading extra software on Windows.  
2. L2TP is closest in the above sense as it is supported by standard Windows XP for IPv4/IPv4 tunneling.   
3. GPL code is available for L2TP.
4. L2TP has been implemented in Windows by NTT and SixXs.  
5. Most importantly, L2TP is widely supported by the major concentrator vendors.

Bill

> -----Original Message-----
> From: Maria A. Dos Santos (mariados) 
> Sent: Saturday, March 11, 2006 12:02 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Softwires] Notes and Consensus from Interim 
> Meeting in Hong Kong
> 
> Jordi,
> 
> We googled "l2tp client" and found SixXs release note mentioned
> 
>  "L2TP Support (Yes, even under Windows one can do IPv6 in 
> PPP in L2TP :)"
> 
> a window client that will have l2tp capability.  
> 
> Bill queried Jeroen Massar at SixXs and confirmed that the 
> l2tp capability 
> will probably be available in 2 months to the public.
> 
> http://www.sixxs.net/tools/aiccu/history/
> 
> Just one example...
> 
> alice
> 
> > -----Original Message-----
> > From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
> > Sent: Friday, 10 March, 2006 9:30
> > To: [email-masked]
> > Subject: Re: [Softwires] Notes and Consensus from Interim 
> > Meeting in Hong Kong
> > 
> > Hi David,
> > 
> > I think the main discussion here has been related to the lack 
> > of IPv6 support for L2TP in XP (and I guess is the same in 
> > W2003). Unless I misread the link that you provided, I think 
> > doesn't mention IPv6 support at all.
> > 
> > I also recall having checked with Microsoft a couple of times 
> > and they confirmed that will be only available in Vista. Of 
> > course, this can change, and that will be great actually !
> > 
> > Regards,
> > Jordi
> > 
> > 
> > 
> > 
> > > De: David Ward <[email-masked]>
> > > Responder a: <[email-masked]>
> > > Fecha: Fri, 10 Mar 2006 11:12:36 -0600
> > > Para: David Ward <[email-masked]>, "[email-masked]" 
> > > <[email-masked]>, "Durand, Alain" 
> > <[email-masked]>
> > > Conversación: [Softwires] Notes and Consensus from Interim 
> > Meeting in 
> > > Hong Kong
> > > Asunto: Re: [Softwires] Notes and Consensus from Interim 
> Meeting in 
> > > Hong Kong
> > > 
> > > Although I am sitting back allowing folks to discuss 
> > various issues, I 
> > > had to step in w/ the results of a 5 min google search as 
> > there hasn't 
> > > been much information presented on the list wrt what is actually 
> > > available vs
> > > conjecture:
> > > 
> > > 
> > >> From Microsoft on L2TP clients:
> > > 
> > > Explains how to get L2TP on XP and earlier versions of 
> > windows (yes, I 
> > > wrote "XP").
> > > 
> > > http://support.microsoft.com/default.aspx?scid=kb;en-us;818043
> > > 
> > > Alice has already sent out how to turn off IPsec.
> > > 
> > > 
> > > Clients for POSIX OS:
> > > 
> > > http://sourceforge.net/projects/rp-l2tp/
> > > 
> > > 
> > > A quick google gave this information on L2TP as well:
> > > 
> > > 0) Cisco support since 2000
> > > 
> > > 1) Juniper:
> > > 
> > > http://www.juniper.net/products/junose/105016.html
> > > 
> > > The ERX now supports IPv6 for BRAS (PPP & L2TP)
> > > 
> > > (Since at least September 2003)
> > > 
> > > 2) Laurel (now ECI):
> > > 
> > > 
> > 
> http://www.convergedigest.com/PacketSystems/packetsysarticle.asp?ID=11
> > > 350
> > > 
> > > Laurel is also releasing new system software that adds non-stop 
> > > sessions,
> > > IPv6  and LAC (L2TP Access Concentrator) functionality.
> > > http://www.laurelnetworks.com
> > > 
> > > Since at least 07-Jun-04
> > > 
> > > 3) Nortel:
> > > 
> > > 
> > 
> http://www.nortelnetworks.com/products/library/collateral/66014.25-10-
> > > 01.pdf
> > > 
> > > "Nortel Networks GGSN acts as an L2TP Access Concentrator (LAC). 
> > > Address allocation, L2TP Network Server (LNS) and ipv6 
> routing can 
> > > take place within those corporate administrative domains.
> > > 
> > > (Posted October 2001)
> > > 
> > > It appears that both client and servers are available for 
> > desired OS 
> > > and interoperability from various commercial vendors.
> > > 
> > > -DWard
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Softwires mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/softwires
> > > 
> > 
> > 
> > 
> > 
> > **********************************************
> > The IPv6 Portal: http://www.ipv6tf.org
> > 
> > Barcelona 2005 Global IPv6 Summit
> > Slides available at:
> > http://www.ipv6-es.com
> > 
> > This electronic message contains information which may be 
> > privileged or confidential. The information is intended to be 
> > for the use of the individual(s) named above. If you are not 
> > the intended recipient be aware that any disclosure, copying, 
> > distribution or use of the contents of this information, 
> > including attached files, is prohibited.
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Softwires mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/softwires
> > 
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/softwires
> 

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: JF Tremblay <[email-masked]>
Date: Wed, 15 Mar 2006 13:17:39 -0500

> To summarize here:

Bill,
Let me add on this.

> 1. None of the proposed solutions are supported by standard issue
> "out of the box" Microsoft Windows.  All of the solutions will
> require loading extra software on Windows.

Right. However, we should differentiate between a simple application 
(like a TSP client) and something that requires integration with the OS 
such as a new network driver. The level of complexity involved is 
different.

TSP uses existing host resources, that makes a huge difference for the 
time-to-market requirement.

> 2. L2TP is closest in
> the above sense as it is supported by standard Windows XP for
> IPv4/IPv4 tunneling.

TSP also uses standard tunneling in Windows XP for IPv6 in IPv4. (btw, 
did you mean IPv6/IPv4 in the above statement?)

> 3. GPL code is available for L2TP.

Idem for TSP. There are also plan to license the client under a BSD 
license.

> 4. L2TP has been implemented in Windows by NTT and SixXs.

L2TP is not yet implemented by the SixXS client, from what I 
understand. TSP has been implemented on a wide range of OS and by CPE 
manufacturers such as NEC, Draytek and Panasonic. It is also 
implemented on the SixXS client.

> 5. Most importantly, L2TP is widely supported by the major

Most importantly, how many vendors actually support L2TP within the 
softwires context? How many vendors offer L2TP for IPv6 access? How 
many can support tunneling IPv4 over a native IPv6 network?

The current deployment of L2TP is indeed a factor to consider. But we 
have to consider deployment within the softwires context. The current 
deployment of L2TP specific to IPv6 transition is small.

And I'd like to add:
6. TSP is used and deployed now by several ISPs, reserach networks and 
US DoD agencies for IPv6 access. How many end customers actually use 
L2TP for IPv6 access now?

Based on the above information, it's clear that L2TP and TSP are both 
very close to the solution we are looking for, with TSP having an edge 
in actual deployment for IPv6 transition.

IMHO, the question naturally stemming from this is could we possible 
consider two protocols to be standardized for softwires? If we don't, 
then we should debate modifying the existing criteria list (possibly to 
include a clear reference to time-to-market) and then debate the merits 
of each protocols in details (i.e. not with wild guesses).

JF

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Mar 2006 19:56:51 +0100

Hi Bill,

See below, in-line.

Regards,
Jordi

> De: "Bill Storer (bstorer)" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 15 Mar 2006 08:54:46 -0800
> Para: "Maria A. Dos Santos (mariados)" <[email-masked]>,
> <[email-masked]>, <[email-masked]>
> Conversación: [Softwires] Notes and Consensus from Interim Meeting in Hong
> Kong
> Asunto: RE: [Softwires] Notes and Consensus from Interim Meeting in Hong Kong
> 
> To summarize here:
> 
> 1. None of the proposed solutions are supported by standard issue "out of the
> box" Microsoft Windows.  All of the solutions will require loading extra
> software on Windows.

I'm not sure if this was a requirement, not in my opinion. It will be ideal,
but we know is difficult for old OSs.

> XP for IPv4/IPv4 tunneling.

With a small trick to disable IPsec, but I guess it could be automated.

> 3. GPL code is available for L2TP.

Same as other solutions.

> 4. L2TP has been implemented in Windows by NTT and SixXs.

It will be by SixXS, but agree, within a good timing in my opinion (actually
shorter timing that I will say is the required one, but that's a different
discussion).

> 5. Most importantly, L2TP is widely supported by the major concentrator

Yes, for two main router/concentrator vendors, should be ok.

Now, if you compare L2TP with TSP (I'm not advocating for one or the other,
just trying to analyze the situation), TSP seems better to integrate from
the client perspective and no need to play tricks in any OS. However has
less support from the server side.

So the question is again, IF we want to have a fair comparison:
1) Technical detailed comparison of different aspects among both of them,
pros and cons (i.e., overhead, prefix delegation, DNS, etc.).

2) How much time it will take for router/concentrator vendors to implement
TSP, and if it will happen in case we choose it.

3) How much weight we give to the support in routers vs. the support in
clients.

Not easy ...

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: David Ward <[email-masked]>
Date: Wed, 15 Mar 2006 18:25:43 -0600

Jordi -

Just a quick note -

On 3/15/06 12:56 PM, "JORDI PALET MARTINEZ" <[email-masked]>
wrote:

...snip...

> pros and cons (i.e., overhead, prefix delegation, DNS, etc.).

The items given as examples above do not appear to be points of contention
as recently discussed on the list. I think the technical aspects of the
solutions are well represented in the interim meeting notes and references
given by the presenters. Our PS focuses on completeness of solution
(signaling, encapsulation variants, OAM including MIBs, failure detection,
etc) and ability for a protocol to solve the H&S scenarios. The recent
discussion on the list is also not focused on what is in the PS but, on the
availability of an XP client for host based softwire initiation/termination
as it is related to TTM.

> TSP, and if it will happen in case we choose it.

This question isn't within our problem statement. Others have given examples
of TSP and L2TP (supporting V6) router/concentrator support. We cannot make
any statements about effort, time or other resources necessary to implement
foo vs bar in any environment we are not familiar. I propose that we attempt
to use the lists of current known and/or soon to be released (announced)
implementations.

> 3) How much weight we give to the support in routers vs. the support in

This is a good question. We did not address in our interim meeting. We did
not discuss weighting the proposed solutions for their ability to solve host
vs "CPE" based softwire initiation/termination in the H&S scenarios.
Although I believe it has been shown that both proposed solutions solve and
are deployed in both scenarios.

Thanks

-DWard

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 16 Mar 2006 18:29:01 +0100

Hi David,

Please, see below, in-line. Anyway, I think JF summarized very well the
situation in his email yesterday.

Regards,
Jordi

> Responder a: <[email-masked]>
> Fecha: Wed, 15 Mar 2006 18:25:43 -0600
> Para: <[email-masked]>, "[email-masked]" <[email-masked]>,
> David Ward <[email-masked]>
> Asunto: Re: [Softwires] Notes and Consensus from Interim Meeting in Hong Kong
> 
> 
> Jordi -
> 
> Just a quick note -
> 

I agree that some of those aren't to be resolved by softwires, but in our
analysis of what is available to match our TTM, it should be there, or it
should be clear that is being worked out already (typically by some other
WG).

> to use the lists of current known and/or soon to be released (announced)

Same, we should not make any statements about that, but if we are trying to
determine TTM, then we need to at least "foresee" what can be the situation
for each possible choice.

> are deployed in both scenarios.

No, what I meant here is more regarding the TTM. Again, defining a concrete
TTM "wish" for our analysis, will make everything much more easy !