Current Meeting Report

2.3.8 Layer Two Tunneling Protocol Extensions (l2tpext)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/30/2002

W. Mark Townsley <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Thomas Narten <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe
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 thereby take advantage of the work done for any protocol 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 must 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 ( 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
JUL 01  Submit L2TP PPP Disconnect Information to IESG for consideration as a Proposed Standard
JUL 01  Submit L2TP ATM extensions to IESG for consideration as a Proposed Standard
JUL 01  Submit L2TP MIB to IESG for consideration as a Proposed Standard
JUL 01  Submit L2TP Link Information to IESG for consideration as a Proposed Standard
JUL 01  Submit L2TP Session Info to IESG for consideration as a Proposed Standard
AUG 01  Submit L2TP Header Compression to IESG for consideration as a Proposed Standard
AUG 01  Submit L2TP Differentiated Services to IESG for consideration as a Proposed Standard
AUG 01  Submit L2TP over AAL5 to IESG for consideration as a Proposed Standard
AUG 01  Submit initial Internet-Draft of L2TP Base Specification
AUG 01  Submit initial Internet-Draft of PPP over L2TP
  • - draft-ietf-l2tpext-sesinfo-04.txt
  • - draft-ietf-l2tpext-link-05.txt
  • - draft-ietf-l2tpext-l2tp-atm-03.txt
  • - draft-ietf-l2tpext-l2tphc-05.txt
  • - draft-ietf-l2tpext-ds-05.txt
  • - draft-ietf-l2tpext-l2tp-mib-04.txt
  • - draft-ietf-l2tpext-mcast-01.txt
  • - draft-dasilva-l2tp-relaysvc-03.txt
  • - draft-ietf-l2tpext-l2tp-base-03.txt
  • - draft-ietf-l2tpext-tunnel-switching-02.txt
  • - draft-ietf-l2tpext-pwe3-fr-01.txt
  • - draft-ietf-l2tpext-rfc2661-iana-00.txt
  • - draft-ietf-l2tpext-failover-00.txt
  • - draft-ietf-l2tpext-v92-moh-01.txt
  • - draft-ietf-l2tpext-pwe3-hdlc-00.txt
  • - draft-ietf-l2tpext-atmext-rfc3301-bis-00.txt
  • - draft-ietf-l2tpext-l2tpmib-base-00.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

    Current Meeting Report

    Layer Two Tunneling Protocol Extensions WG (l2tpext)

    TUESDAY, July 16 at 1415-1515

    CHAIR: W. Mark Townsley <>


    14:15 Agenda Bashing
    W. Mark Townsley

    14:20 L2TPEXT WG Update
    W. Mark Townsley

    No comments from floor - see slides.

    Any interest in mcast - no comments, will be put up for last call.

    Need more participation in tunnel switching

    Please read pwe3-fragmentation and comment re 2661

    14:30 L2TPv3 Update
    Jed Lau

    Need clarification of must and may L2TPv3 relative L2TPv2
    Explained that must/may list resolved in v3 by checking what made sense in the spec.
    No comments on change to pw specific field or removal of offset.
    Request for contribution - payload and application drafts

    Juha Huien (JH) - If you set up an l2tp session how does app know of the attachment
    JL - Defined by the app
    JH - Applications need to register identifier
    MT - PW type and end ident (opaque type defined by higher layer) help this identification, but there is not a lot of help in the protocol per se.
    Need something like JH VPLS @ DNS draft
    Additional AVPs, or a "application type" AVP, may be needed

    14:40 L2TPv3 MIB
    Jed Lau

    Payload specific l2tp mib - not the same as pwe3 payload

    Jun Kyun - How do we combind l2tp xport mib with MPLS MIB

    JL - defines transport and l2tp session specific

    JL - when L2TP runs over mpls may not be able to combine mib
    Concen at overlap between xport layer mibs and l2tp mibs

    JL - mibs will only be created if needed and will be l2tp session specific

    14:50 L2TP Call Information Messages
    W. Mark Townsley (for Tom Mistretta)

    Radius stuff will be moved to radius mib leaving just l2tp stuff. Vendor specific info - "text"

    Request accept as WG doc.
    Need to resolve conflict/intersections with atmex and sessio

    Glen - Standards a good thing by as you said much of this is vendor specific. Don't we need to do better than text messaging (ie vendor specific AVP's because need to do machine interpretation.

    MT - This is for human readable trouble-shooting only. MAchines should not attempt to understsnd these msgs

    Glen - Fine, but customers may want to act on data, so may make more sence to have vendor specific AVP's.

    MT - Asked industry and answer was needed only for trouble shooting. This is better than putting it into 32bit physical channel id as some people are trying to do.

    JH - Why can't the vendor id be defined
    MT - Problem encourages vendor specific rather than standard behaviour. Also names change.
    ?? - Could send SMI code.


    None received.