Subject: RE: [Softwires] Technical Comparison between L2TPv2 and TSP

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Sun, 19 Mar 2006 20:29:53 -0800

Jordi, just cut-and-paste the relevants and responses
come after each:

> >         - TSP is a relatively new draft:
> >           draft-blanchet-v6ops-tunnelbroker-tsp-03.txt
> 
> I'm not sure when it was the first version, but is not so new 
> as I may seem.

JF already updated me, that the tsp was proposed in 2001...

> >              Native Microsoft Windows client:
> >                 ipv4 over ipv4 client:
> >                    on all windows OSs (IPsec optional)
> 
> This is not a requirement, so isn't an issue.
> 
> I will be more worried by the support of IPv6 in IPv6 client 
> (also the concentrator part).
> 
> >                 ipv6 over ipv4 client (with PPPv6 and DHCPv6):
> >                    available on Vista / Longhorn
> >                    (now in beta testing, to be released end of 2006)
> 
> We are also missing the IPv4 in IPv6 client (also the 
> concentrator part).
> This is a requirement.

This is back to TTM issue, for L2TPv2 IPv6 transport support.
I will let the chairs respond to this...

> Last, but not least, in my opinion requiring UDP 
> encapsulation is not ideal.
> Anyway, I understand that this is not longer a need in 
> L2TPv3, for our phase 2.

NAT traversal is a requirement and L2TPv2 over UDP satisfies it.
But UDP-bypass is not a requirement.  But I agree, this is not the 
most efficient encap, and that's why we think l2tpv3 will bring 
in quite a bit of improvement to the solution.

> >         - TSP embeds it's own prefix DP, meaning extra support is
> >           required for TSP in addition to the standards, i.e. DHCP.
> > 
> 
> I consider this a good thing, because otherwise we are 
> requiring necessarily
> DHCPv6 support in all kind of devices, and it was noted 
> already that some have no plans for supporting it.
> 
> DHCPv6 can also be used anyway.

I agree and disagree, based on my understanding, I may be wrong.
For devices that don't support dhcp, yes, they simply get the 
prefix via tsp.  But for devices that prefer to use dhcp, if the
SC sends the prefix via the tsp, the device (SI) either has to 
just take it from tsp (eventhough it prefers dhcp), or somehow
rejects/ignores the tsp value and perform dhcp later.  Is this 
possible?

> > 9) NAT traversial
> > 
> >  * l2tpv2 runs over UDP
> 
> As indicated above, this is a must here, no option for 
> proto-41 forwarding, which in my opinion is a disadvantage.

sorry, I don't get this comment.  Do you mean no option to bypass
UDP and run over IP?  I agree that this is not efficient, but this 
is not violating the requirement either.

cheers,
alice

> -----Original Message-----
> From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
> Sent: Sunday, 19 March, 2006 19:32
> To: [email-masked]
> Subject: Re: [Softwires] Technical Comparison between L2TPv2 and TSP
> 
> Hi Maria,
> 
> Just a few notes below, in-line, to complete some of the 
> comparison details.
> 
> Regards,
> Jordi
> 
> 
> 
> 
> > De: "Maria A. Dos Santos (mariados)" <[email-masked]> 
> Responder a: 
> > <[email-masked]>
> > Fecha: Fri, 17 Mar 2006 19:51:30 -0800
> > Para: <[email-masked]>
> > Conversación: Technical Comparison between L2TPv2 and TSP
> > Asunto: [Softwires] Technical Comparison between L2TPv2 and TSP
> > 
> > All,
> > 
> > We have seen a lot of discussions comparing L2TP and TSP on 
> the list, 
> > focusing on the TTM requirement.  But what is missing in the 
> > comparison is the technical aspect.  The following lists 
> out all the 
> > technical categories identified in the Softwires problem 
> statement and 
> > how L2TP and TSP satisfy them.  Hopefully, this comparison 
> will give 
> > us a better picture.
> > 
> > JF, please feel free to provide correct info on TSP, I did my best 
> > according to the TSP draft and your preso.
> > 
> > cheers,
> > alice
> > 
> > -------------------------------------------------------------------
> > 1) Standardisation Status
> > 
> >         L2TP is designed specially for wire (layer 2) emulation.
> >         L2TP fits right into the Softwire paradigm in which L2TP
> >         signals the L2 attributes during control setup as well as
> >         manage the wire post initial setup.
> > 
> >         L2TP has been deployed widely and is well proven in 
> this role.
> >         It provides a layered solution such that other 
> protocols like
> >         PPP, DHCP, etc run on top of the wire just like 
> they would for
> >         standard hardwires.
> > 
> >         * L2TPv2 (RFC2661) has been standard since 1999 and protocol
> >           has been well tested and proven by large-scale VPN 
> > deployments.
> >           Complete suite of l2tp standards exists and widely
> > implemented: 
> >              
> >           RFC 2661 - "Layer Two Tunneling Protocol"
> >           RFC 2867 - "RADIUS Accounting Modifications for Tunnel
> >                       Protocol Support"
> >           RFC 3371 - "Layer Two Tunneling Protocol "L2TP" Management
> >                       Information Base"
> >           RFC 3193 - "Securing L2TP using IPsec"
> >           RFC 3948 - "UDP Encapsulation of IPsec ESP Packet"
> >           RFC 3145 - "L2TP Disconnect Cause Information"
> >           RFC 3308 - "Layer Two Tunneling Protocol (L2TP) 
> > Differentiated
> > 
> >                       Services Extension"
> > 
> >         - TSP is a relatively new draft:
> >           draft-blanchet-v6ops-tunnelbroker-tsp-03.txt
> 
> I'm not sure when it was the first version, but is not so new 
> as I may seem.

JF already updatede me, that the tsp was proposed in 2001...

> 
> >         - TSP draft only specifies protocol between the 
> tunnel client
> >           and broker, no protocol defined between the tunnel broker
> >           and tunnel server.
> > 
> > 
> > 2) Technology Reuse
> > 
> >         * Reuse of L2TP encapsulation for the MESH case, including
> >           Accounting and MIB.
> > 
> >         - TSP will be one extra protocol to manage.
> > 
> > 
> > 3) Interoperability
> > 
> > * l2tpv2 implementations include:
> > 
> >              L2TPv2 has been independently implemented by 
> major router
> >              vendors, for Linux and PoSix-bases OSs and on 
> MS Windows
> >              OSs (both natively and by third-vendors).
> > 
> >              Major router vendors:
> >                 Cisco, Juniper, Redback, Nortel
> > 
> >              Linux and other POSIX-based OSs (GPL):
> >                 sourceforge.net, Roaring Penguin, etc
> > 
> >              Native Microsoft Windows client:
> >                 ipv4 over ipv4 client:
> >                    on all windows OSs (IPsec optional)
> 
> This is not a requirement, so isn't an issue.
> 
> I will be more worried by the support of IPv6 in IPv6 client 
> (also the concentrator part).
> 
> >                 ipv6 over ipv4 client (with PPPv6 and DHCPv6):
> >                    available on Vista / Longhorn
> >                    (now in beta testing, to be released end of 2006)
> 
> We are also missing the IPv4 in IPv6 client (also the 
> concentrator part).
> This is a requirement.

This is back to TTM issue again.  L2TPv2 IPv6 transport is not there
yet.  It is a softwire requirement and L2TPv2 RFC supports it.  But
how soon do we need it for deployment.  That's the question.  

> 
> > 
> >              Downloadable Windows XP clients: ipv6 over ipv4
> >                 NTT, SixXs (to be released in 2 months), Trumpet.
> > 
> 
> Last, but not least, in my opinion requiring UDP 
> encapsulation is not ideal.
> Anyway, I understand that this is not longer a need in 
> L2TPv3, for our phase 2.
> 
> > 
> >         - TSP implementations include:
> > 
> >              TSP Server:
> >              Hexago
> > 
> >              TSP Client:
> >              Draytek, Panasonic, NEC
> > 
> >              Independant implementations:
> >              ENST, University of Southampton, SixXs
> > 
> > 
> > 4) Address allocation
> > 
> >         * l2tpv2 solution will use IPCP (v4/v6) and DHCP 
> (v6/v4) which
> >           are standard building blocks.
> > 
> > 
> >         - TSP embeds it's own prefix DP, meaning extra support is
> >           required for TSP in addition to the standards, i.e. DHCP.
> > 
> 
> I consider this a good thing, because otherwise we are 
> requiring necessarily
> DHCPv6 support in all kind of devices, and it was noted 
> already that some have no plans for supporting it.
> 
> DHCPv6 can also be used anyway.
> 
> > 
> > 5) Scalability
> > 
> >         * L2TPv2 is proven to be scalable to the millions 
> subscribers
> >           in multiple VPN deployments (i.e. NTT, BT, AOL).
> > 
> >         * Upper Tens of thousands of concurrent L2TPv2 sessions on a
> >           single node (or "LNS")
> > 
> >         * Call setup rates in the hundreds per second
> > 
> >         * L2TP supports a "Try another directed" message 
> allowing LNS
> >           to provide LAC a list of alternate LNSes that it 
> can connect
> >           to.  This message is currently specified for 
> L2TPv3 only, but
> >           has been implemented for L2TPv2 and RFC2661 can 
> be extended
> >           to cover it.
> > 
> > 
> >         - Freenet6 TSP deployment has about 10 thousand tunnels on a
> >           single SC.
> >         - No numbers on KDDI, AT&T and Wanadoo trials.
> > 
> > 
> > 6) Authentication/Security
> > 
> >  * L2TPv2 supports mutual Control Channel Authentication at
> >           beginning of establishment message exchange.
> > 
> >         * Inherits PPP per-user Authentication
> > 
> >         * Data encapsulated in session header with tunnel/session
> >           ids, provides better security than IP-in-IP (i.e.protocol
> >           0x41) encapsulation.
> > 
> >         * Runs over IPSec to provide full tunnel protection
> >           * RFC 3193 - Securing L2TP using IPsec
> >           * RFC 3948 - UDP Encapsulation of IPsec ESP Packets
> > 
> > 
> >         - TSP Authentication not at beginning of establishment,
> >           vulnerable in load balancing redirection scenerios.
> >         - No security related drafts for BCP or encryption.
> >         - Uses IP-in-IP (ie. protcol 0x41) for data encapsulation,
> >           "easy to spoof"
> > 
> > 
> > 7) OAM
> > 
> > * L2TPv2 supports in-band signalling:
> >           - data connectivity problem will prevent tunnel 
> establishment
> >             in the first place.
> >           - loss of data connectivity will trigger keepalive timeout
> >             and thus allows LAC/LNS to clean up stale tunnel.
> > 
> >         * L2TPv2 In-band keepalives can be enabled from both LAC/LNS
> >           and only sent if there is no data traffic.  So it 
> does not 
> > add
> > 
> >           extra load to congested link.
> > 
> >         * L2TPv2 has standard accounting and MIB support
> >           * RFC 2867 - RADIUS Accounting extension for tunnel
> >           * RFC 3371 - L2TP MIB
> >           * RFC 3145 - L2TP Disconnect Cause Information
> > 
> >         * L2TPv2 high-availability support
> >           High-availabilty/graceful restart mechanisms have 
> been built
> >           into the protocol for redundancy purposes:
> >              draft-ietf-l2tpext-failover-06.txt - (also applies to
> > L2TPv2)
> >               "Fail Over extensions for L2TP "failover"
> > 
> >         * L2TP supports VCCV, an in-band per-session ping.  VCCV 
> > serves as
> >           a diagnostic or fault detection mechanism to test the
> >           network's forwarding plane liveliness.  VCCV 
> currently only
> >           applies to L2TPv3, but it can easily be extended 
> to work with
> >           L2TPv2.
> >              draft-ietf-pwe3-vccv-07.txt -
> >               "Pseudo Wire Virtual Circuit Connectivity Verification
> >                (VCCV)"
> > 
> > 
> >         - TSP uses out-of-band signaling and tunneled 
> traffic does not 
> > follow
> >           same path.  Therefore have to signal to broker that data 
> > path is
> >           down to clean up tunnel.
> >         - TSP in-band keepalives are requested by the 
> client and sent 
> > from
> >           client to server only.  In case of congestion, 
> server has to 
> > send
> >           request message to client to reduce the frequency which 
> > again adds
> >           to the traffic load.
> >         - TSP has no standard Accounting or MIB support
> > 
> > 
> > 8) Available encapsulations
> > 
> >         * L2TPv2 RFC 2661 supports
> >           IPv6/UDP/IPv4
> >           IPv4/UDP/IPv6
> >           IPv4/UDP/IPv4
> >           IPv6/UDP/IPv6
> >           IPvX/UDP/IPxY/IPsec - this is to emphasize 
> standard support 
> > of L2TP
> >                                 over IPSec.
> > 
> >         - TSP draft supports
> >           IPv6/IPv4
> >           IPv6/UDP/IPv4
> >           IPv4/IPv6
> >           extensible to others, but not yet specified in draft.
> > 
> > 9) NAT traversial
> > 
> >  * l2tpv2 runs over UDP
> 
> As indicated above, this is a must here, no option for 
> proto-41 forwarding, which in my opinion is a disadvantage.
> 
> > 
> >         - Same for TSP
> > 
> > 10) Nomadicity
> > 
> >         * l2tpv2 is well integrated with RADIUS for per-user 
> > authentication
> >           and authorization.  Roaming users may get back the same
> >           IP address (if within the same administrative 
> domain) or a 
> > different
> >           IP address if outside the domain.
> > 
> >         - TSP does the same.
> > 
> > 11) Multicast support
> > 
> >         * Multicast protocol and data traffic pass throught l2tpv2 
> > tunnel
> >           transparently.
> > 
> >         - TSP can do the same.
> > 
> > 
> > _______________________________________________
> > 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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Mar 2006 22:59:54 -0600

> Responder a: <[email-masked]>
> Fecha: Sun, 19 Mar 2006 20:29:53 -0800
> Para: <[email-masked]>, <[email-masked]>
> Conversación: [Softwires] Technical Comparison between L2TPv2 and TSP
> Asunto: RE: [Softwires] Technical Comparison between L2TPv2 and TSP
> 

I'm not sure to follow you here. The IPv4 in IPv6 transport support is a
requirement of softwires. I also understand that is supported in the L2TP
standards, the question left then is if it is supported in the marketed
implementations ?

> rejects/ignores the tsp value and perform dhcp later.  Is this

I think JF can confirm much better than myself here, but it should be
possible to avoid using TSP for this and using DHCP(/v6).

> is not violating the requirement either.

This is a "small" discrepancy among the co-authors of the problem statement.
I have always been in the side of making sure to avoid UDP encapsulation if
not needed.

Actually for IPv6-in-IPv4, we know that some times is needed because NAT,
but forcing it for IPv4-in-IPv6 is a terrible and I will even say a nasty
decision :-(

Of course, I agree that L2Tv3 doesn't enforce that, but then again we have
the situation about what is more ready at the end of the road for our "TTM":
L2TPv3 or TSP ?, because in equal conditions we should make the comparison
then among L2TPv3 and TSP, not L2TPv2 and TSP ...

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: Marc Blanchet <[email-masked]>
Date: Mon, 20 Mar 2006 11:02:48 -0600

> rejects/ignores the tsp value and perform dhcp later.  Is this

the TSP client optionally requests the prefix. So if the TSP client  
does want to use DHCPv6 for prefix delegation, it just has to _not_  
request a prefix to the broker.

- requesting a prefix within TSP is an optional feature, not  
mandatory feature.
- similar to DNS stuff also handled in TSP session.
- the advantage when using these optional features is that within a  
single authenticated session, you get everything you need for an IPv6  
service.

btw, these features were requested by real users doing real v6  
deployment.

Marc.