2.3.10 Layer Two Tunneling Protocol Extensions (l2tpext)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-14


Mark Townsley <mark@townsley.net>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Thomas Narten <narten@us.ibm.com>

Mailing Lists:

General Discussion: l2tpext@ietf.org
To Subscribe: l2tpext-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/l2tpext/index.html

Description of Working Group:

This group is responsible for extensions to the Layer 2 Tunneling
Protocol.  Examples of L2TP "extensions" include any changes to the
L2TP encapsulation, control messages, or new AVPs sent in IETF
standard control messages.

I. L2TP Background:

L2TP (RFC2661) provides a means for tunneling PPP over IP. Because PPP
can effectivly carry any traffic (e.g., IP (RFC 1332), IPX (RFC 1552),
etc.) it can effectively be used to tunnel arbitrary protocols over
IP. L2TP provides:

- An extensible control protocol for dynamic setup, maintenance, and
  teardown of multiple layer 2 tunnels between two logical endpoints.

- An encapsulation method for tunneling PPP frames between each
  endpoint. This includes multiplexing of multiple, discrete, PPP
  streams between each endpoint.

L2TP looks (in most ways) like just another point-to-point link to PPP
and may thereby take advantage of the work done for any protocol
for use over a traditional PPP WAN link. It should be noted, however,
that the ability to dynamically establish a PPP connection between any
two IP connected endpoints brings new applications and challenges of
scale to existing PPP implementations and protocol definitions that
be considered.

As high-speed broadband access to the home replaces traditional dialup
infrastructure, L2TP has been utilized as one standard method for
aggregation and delivery of PPP connections over packet networks. Thus,
rather than a relatively small scale or low speed circuit-switched
connection such as an analog modem or ISDN connection at the L2TP
Access Concentrator (LAC), we see PPP being received over ATM PVCs
which are generally higher speed and "always-on" vs. temporally
connected.  Further, there are non-IETF standard PPP tunneling
protocols that have been developed and deployed, including PPPoE
(RFC 2516) and the 3GPP2 Wireless GPRS Tunneling Protocol Standard
(http://www.3gpp.org) that interface with L2TP at various points in the
network.  While it is unfortunate that there is more than one standard
method for tunneling PPP defined, each of these have their own
installed bases and specific application-driven nuances. Proper
integration with these various tunneling methods as they "hand-off" to
the L2TP portion of the network must be ensured.

II. L2TP Interaction with PWE3 for Pseudo-Wire Transport:

In addition to tunneling PPP, L2TPEXT will develop protocol extensions
necessary for the tunneling of specific "pseudo-wires" as defined in
the PWE3 WG. Specific milestone identification for this activity is
currently subject to ongoing work and results from PWE3.

III. WG Activities

The Working Group is currently focussed on the following activities:

- RFC2661 bundles data transport, protocol signaling, and PPP
  emulation methods into a single document. This working group will
  separate RFC2661 into stand-alone documents for greater
  modularity. This will consist of a base L2TP document defining
  common tunneling constructs and encapsulation, and a PPP document
  defining the use of these constructs for tunneling of PPP sessions
  as defined in RFC2661. Documents for tunneling of pseudo-wires
  defined in PWE3 will be forthcoming as well.

  As RFC2661 is rewritten to separate the tunnel setup and maintenance
  sections for support of new applications and increased modularity,
  some modifications to the base protocol may be necessary. This
  includes addition of a Pseudo Wire AVP to identify the pseudo wire
  being carried (with PPP identified as 0). In all cases, these will
  follow the extensible models offered in the L2TP base protocol
  design, with as much attention to backwards compatibility as
  possible given the new requirements.

In addition to its broader scope, L2TPEXT has ongoing work to complete
from its inception as a tunneling protocol for PPP only. While RFC2661
will ultimately be made obsolete by a new L2TP base specification and
companion PPP over L2TP specification, documents based on RFC2661
which do not require this new degree of modularity will still be
published in the near term. These include:

- Identification of specific parameters and modes of IPsec in order to
  aid interoperability when IPsec is used to secure L2TP traffic.

- An L2TP MIB for network management.

- An L2TP Differentiated Services Extension to negotiate DSCP
  parameters to be set for packets associated with a given L2TP
  tunnel, sessions within a tunnel, or L2TP control traffic which may
  need differentiated QoS settings.

- Extensions to L2TP for additional or more robust control information
  for informational or operational purposes as deemed necessary based
  on operational experience. These include better transfer of L2TP PPP
  LCP Information between tunnel endpoints when such state needs to be
  shared, PPP Disconnect codes within L2TP control messages for better
  debugging, and L2TP session information for enhanced logging,
  billing, and error reporting.

- Standard methods for operation over such packet networks such as
  Frame Relay and AAL5.

- L2TP defines a base encapsulation for operation in typical
  environments for tunneling PPP at the time RFC2661 was being
  developed. In cases where bandwidth cost is at a premium, the size
  of the L2TP header becomes more significant. L2TP will define a
  compressed version of the L2TP header for these environments that
  takes advantage of the L2TP control plane to establish operational
  parameters allowing removal of information from individual packets.

Goals and Milestones:

Done  Submit L2TP over Frame Relay to IESG for consideration as a Proposed Standard
Done  Submit L2TP Security to IESG for consideration as a Proposed Standard
Done  Submit L2TP PPP Disconnect Information to IESG for consideration as a Proposed Standard
Done  Submit L2TP ATM extensions to IESG for consideration as a Proposed Standard
Done  Submit L2TP MIB to IESG for consideration as a Proposed Standard
Done  Submit L2TP Link Information to IESG for consideration as a Proposed Standard
Done  Submit L2TP Session Info to IESG for consideration as a Proposed Standard
Done  Submit L2TP Differentiated Services to IESG for consideration as a Proposed Standard
Done  Submit L2TP over AAL5 to IESG for consideration as a Proposed Standard
Done  Submit initial Internet-Draft of L2TP Base Specification
Done  Submit initial Internet-Draft of PPP over L2TP
Done  Submit final Internet-Draft of L2TPv3 Base Specification to IESG
Jan 04  Submit Internet-Draft of HDLC over L2TPv3 to IESG
Jan 04  Submit Internet-Draft of Frame Relay over L2TPv3 to IESG
Feb 04  Submit Internet-Draft of Ethernet over L2TPv3 to IESG
Mar 04  Submit L2TP Header Compression to IESG for consideration as a Proposed Standard
Apr 04  Submit Internet-Draft of PPP over L2TPv3 to IESG


  • draft-ietf-l2tpext-mcast-05.txt
  • draft-ietf-l2tpext-l2tp-base-14.txt
  • draft-ietf-l2tpext-pwe3-fr-04.txt
  • draft-ietf-l2tpext-failover-04.txt
  • draft-ietf-l2tpext-pwe3-hdlc-04.txt
  • draft-ietf-l2tpext-l2vpn-02.txt
  • draft-ietf-l2tpext-pwe3-atm-02.txt

    Request For Comments:

    RFC3070 PS Layer Two Tunneling Protocol (L2TP) over Frame Relay
    RFC3145 PS L2TP Disconnect Cause Information
    RFC3193 PS Securing L2TP using IPSEC
    RFC3301 PS Layer Two Tunnelling Protocol : ATM access network extensions
    RFC3308 PS L2TP IP Differentiated Services Extension
    RFC3355 PS L2TP Over AAL5
    RFC3371 PS Layer Two Tunneling Protocol 'L2TP' Management Information Base
    RFC3437 PS Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
    RFC3438 BCP L2TP IANA Considerations Update
    RFC3573 PS Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)
    RFC3817 I L2TP Active Discovery Relay for PPPoE

    Current Meeting Report

    L2TPEXT minutes
    IETF 61

    Agenda Bashing and Status, Mark Townsley

    Last met, July 2003, Vienna.

    New RFCs Since:
    RFC3817, L2TP active discovery relay for PPP over Ethernet
    RFC3931, L2TPv3 (in the RFC editor's queue)
    Draft-ietf-l2tpext-mcast-05.txt approved for publication

    WG Drafts:

    L2VPN Extensions for L2TP
    Frame-Relay over L2TPv3
    HDLC Frames over L2TPv3
    ATM Pseudo-Wire Extensions for L2TP
    Transport of Ethernet Frames over L2TPv3
    (-02 didnít get posted for some unknown reason)
    Fail Over extensions for L2TP "failover"

    Expired/Stalled Drafts

    L2TP Session Information "sesinfo"
    L2TP Tunnel Switching draft-ietf-l2tpext-tunnel-switching-04.txt

    Potential WG Drafts

    RADIUS & L2TP Extended NAS-Port AVPs
    L2TP Call Information Messages
    L2TPv3 Graceful Restart
    Layer Two Tunneling Protocol - Setup of TDM Pseudowires

    No comments from the audience on status or agenda.

    TDM Setup, Sasha Vainshtein
    TDM PW requires exchange of
    - AC bit rate
    - packet payload size
    - Usage of RTP header
    - AC trunk type - prevent E1 from being connected to T1

    New AVPs
    - TDM PW AVP
    flags: rtp header, fragmentation of TDM multiflags

    - Discussion on a defined flag that is no longer used.

    - Comments about providing a failure reason when tearing down link due to parameter mismatch. Sasha agreed to look into providing this.

    - Proposal: Accept this draft as a WG document & solicit discussion on the mailing list. No substantive objections raised.

    Tom Mistretta - RADIUS-EXT/infoMsg/sesinfo
    Propose to consolidate all the NAS info drafts to Radius draft.

    - LAC - LNS info exchange msgs
    - Three drafts going to three separate directions -- radext, sesinfo and infomsg
    - Want to propagate NAS-port info from one end of network to other, for use in service provider billing --
    - Central problem that 32-bit "physical channel ID" is not a number people can use;
    - Currently have many different proprietary ways to do this;
    - Also people want just to send simple debug msgs between LAC and LNS;
    - There are resulting tunnel-switching complications to tackle as well

    SESINFO draft

    - Infomsg talked about debug
    - Propose to let infomsg and sesinfo expire
    - Continue with the Radius draft

    Tom Narten: Need to get radext group signoff for RADIUS extension; as AD I will not go to Last Call until they have reviewed it; shouldn't have to present in Radext, just send to their group; Mark mentioned Glen Zorn would be good reviewer -- knows both L2TP and RADIUS

    Tom Mistretta - Tunnel Switching
    Propose to update tunnel-switching draft and send out early next year. Potentially remove loop detection - not much concern in audience about tunnel switching loops.

    Congestion Problem: Congestion on tunnel switch aggregator (TSA) is not propagated back to the LAC; LAC might be tring to do load balancing, but not even know there is a TSA out there; only solution we know of is propagating far too much info back; we believe this can be solved in a standards approach simply by having a new message ("resources unavailable, temporary condition" message -- as have elsewhere)

    MarkT: PWE3 also tackling the "PW-switching" problem. Need to reconcile this with PWE3 and L2TPv3

    Try to deliver new draft to mailing list by early next year.

    Sasha - L2TP Graceful Restart Overview


    - Restart the control plane without affecting the forwarding state.
    - Customer traffic should not be disturbed.

    - behavior is split between the two peers
    - peer of the restarting LCCE detects loss of control connection
    - postpones breaking the associated sessions.

    Protocol changes: Two new AVPs. New session state. No new security issues. Same security methods as in the native l2tpv3. Partial graceful restart support possible.

    (Greg Daley) Concern about security in allowing forwarding state to remain and potentially be extended for an amount of time after the control connection goes down.

    Ans: Forwarding state is kept only for finite amount of time after the control connection goes down. If a new control connection is not authenticated in a given time - the forwarding state is removed.

    L2TPv3 Failover, Tom Mistretta, Paul Howard


    Each L2TP peer has configured and dynamic stateful info
    Need protocol ext for reconciling states between peers
    Re-sync 3 phases;
    pre-failover during control channel setup

    Sam Henderson galtzur-l2tpext-gr vs. ietf-l2tpext-failover
    - Galtzur establishes whole new control connection after failover
    - Failover draft establishes new temporary control chan to reset/resync original control channel;
    - After recovery time, query peer for sessions that appear to be stale

    - Combining these:
    - Need recovery tunnel concept to prevent updating data plane with new tunnel ID for v2
    - Allow normal processing of ICRQs with GR AVP and receiving traffic to refresh
    - End up with limiations of one and complexities of the other
    - So now it is easier to implement both drafts separately

    Mark: So far it seems like everyone wants 2 drafts


    L2TPEXT Presentation
    Graceful restart Mechanism for L2TPv3
    Consolidating Failover & Graceful Restart?