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

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Sat, 18 Mar 2006 18:18:31 -0800

Hi all (again),

I have updated the comparison to add back the missing
items:

Section 3: added CPE implementation information
Section 5 & 5.5: now we have "Scalability" and
                 "Deployment Experience" separated

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
        - 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

             CPE implementations:
                Linksys v6 over v4 clients have been implemented by
                NTT and Point6 (based on GPL client).

             Native Microsoft Windows client: 
                ipv4 over ipv4 client:
                   on all windows OSs (IPsec optional)
                   (for some older Windows Os, Microsoft has a 
                    free L2TP/IPSec VPN client for download)
                ipv6 over ipv4 client (with PPPv6 and DHCPv6):
                   available on Vista / Longhorn  
                   (now in beta testing, to be released end of 2006)

             Downloadable Windows XP clients: ipv6 over ipv4
                NTT, SixXs (to be released in 2 months), Trumpet.

        - TSP implementations include:

             TSP Server:
             Hexago

             TSP CPE Client:
             Draytek, Panasonic, NEC (based on GPL client??)

             Independant implementations:
             ENST, University of Southampton, SixXs (windows & Unix)

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.

5) Scalability 

        * L2TPv2 is proven to be scalable to the millions subscribers
          in multiple VPN deployments.

        * 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 has 10,000 tunnels now on single server.
        - Have tested 50,000 tunnels on one broker, assuming that 64K 
          would be a hard limit based on tyical OS limitations.
        - TSP also supports loadbalancing in the tunnel broker.

5.5) Deployment experience

        * L2TPv2 is widely used in large scale IPv4 o IPv4 VPN
          deployments with millions of tunnels each:
	     - Cases in point being NTT, BT, AOL

        * L2TPv2 is used in IPv6 o IPv4 deployments by Point6 and
          NTT's commerical OCN IPv6 service.

        - Freenet6 TSP IPv6 over IPv4 deployment (10,000 tunnels)
        - KDDI TSP IPv4 over IPv6 deployment (1000 tunnels)
        - AT&T and Wanadoo trials, no numbers.

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 -
              "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

        - 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

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 Mar 2006 20:41:03 +0000

Hi,

Just a comment regarding 'handwaving' about problems running L2TP VPNs
behind NATs.

I see anecdotal comments about problems, mainly from our nomadic staff
who use VPNs from hotels and conference areas in which NAT is almost a
given.   Sometimes PPTP VPNs will work where L2TP does not.   

This scenario is more towards the nomadic IPv6 user rather than the
'dense' large-scale deployment within a given (broadband) ISP for its 
own customers (who may typically have ISP-supplied DSL routers).

The scenario where the SOHO CPE is the tunnel endpoint would generally
remove the NAT traversal requirement.   This is the solution I would
personally prefer to use, but of course that requires functionality
in commodity CPEs that as yet don't either have native IPv6 support.

Tim