Subject: [Softwires] Technical Comparison between L2TPv2 and TSP

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Fri, 17 Mar 2006 19:51:30 -0800

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

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

        - 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: David Ward <[email-masked]>
Date: Sat, 18 Mar 2006 09:13:38 -0600

Alice - 

Thanks for writing this down. A couple items would be good to describe that
are called out in the problem statement and missing from your summary:

 CPE initiation/termination for H&S
 Scaling/Deployment experience

Thanks

-DWard

---

From: JF Tremblay <[email-masked]>
Date: Sat, 18 Mar 2006 21:23:46 -0500

--On Friday, March 17, 2006 7:51 PM -0800 "Maria A. Dos Santos 

> satisfy them.  Hopefully, this comparison will give us a

Hi Maria.
Agreed, a good complete technical comparison was missing from our
previous discussions. Glad you took the time to write down all of this.

> my best according to the TSP draft and your preso.

Of course. See below.

> alice

The problem statement does not mention L2 as a base paradigm.

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

TSP has been proposed in draft-vg-ngtrans-tsp-00.txt in 2001 used
since then.

>           and broker, no protocol defined between the tunnel broker

This is out-of-scope for softwire.

>         - TSP will be one extra protocol to manage.

However, TSP reuses existing and well known encapsulation types such as
protocol 41.

>           required for TSP in addition to the standards, i.e. DHCP.

The idea is to compensate for the lack of implementations of some IPv6
protocols such as IPCPv6 and DHCPv6. This argument was indeed stronger
a few years ago.

>           to.  This message is currently specified for L2TPv3 only,
> but           has been implemented for L2TPv2 and RFC2661 can be
> extended           to cover it.

Redirection message is built-in TSP.

>         - No numbers on KDDI, AT&T and Wanadoo trials.

KDDI deployment scales to a few thousands, this was presented by Shu 
Yamamoto at the interim.  	

>           beginning of establishment message exchange.

Is the authentication really mutual? This wasn't clear from the 
discussion at the interim.

>           vulnerable in load balancing redirection scenerios.

L2TP has the same issue, to my knowledge. We discussed this at the
interim and agreed this is a non-issue, since the redirection has to
happen before authentication in any case.

>         - Uses IP-in-IP (ie. protcol 0x41) for data encapsulation,

Agreed. Using strict reverse path forwarding helps in this case.

>           - data connectivity problem will prevent tunnel
> establishment              in the first place.
>           High-availabilty/graceful restart mechanisms have been
> built            into the protocol for redundancy purposes:
>         * L2TP supports VCCV, an in-band per-session ping.  VCCV
> serves as
>           applies to L2TPv3, but it can easily be extended to work
> with            L2TPv2.
>           same path.  Therefore have to signal to broker that data
> path is
>           down to clean up tunnel.
>           request message to client to reduce the frequency which
> again adds
>           to the traffic load.
>           IPvX/UDP/IPxY/IPsec - this is to emphasize standard support
> of L2TP
>                                 over IPSec.
>
>         - TSP draft supports
>           IPv6/IPv4
>           IPv6/UDP/IPv4
>           IPv4/IPv6

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Mar 2006 21:31:53 -0600

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

I'm not sure when it was the first version, but is not so new as I may seem.

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

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

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

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

>           extensible to others, but not yet specified in draft.

As indicated above, this is a must here, no option for proto-41 forwarding,
which in my opinion is a disadvantage.

>         * Multicast protocol and data traffic pass throught l2tpv2

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