Layer Two Tunneling Protocol Extensions (l2tpext)

Last Modified: 2006-10-09

Additional information is available at tools.ietf.org/wg/l2tpext

Chair(s):

  • Ignacio Goyret <igoyret@lucent.com>

  • Carlos Pignataro <cpignata@cisco.com>

    Internet Area Director(s):

  • Jari Arkko <jari.arkko@piuha.net>
  • Mark Townsley <townsley@cisco.com>

    Internet Area Advisor:

  • Mark Townsley <townsley@cisco.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
    defined
    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
    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
    (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
    Mar 2004  Submit L2TP Header Compression to IESG for consideration as a Proposed Standard
    Apr 2004  Submit Internet-Draft of PPP over L2TPv3 to IESG
    Done  Submit Internet-Draft of HDLC over L2TPv3 to IESG
    Done  Submit Internet-Draft of Frame Relay over L2TPv3 to IESG
    Done  Submit L2VPN Extensions for L2TP to IESG
    Done  Submit Internet-Draft of Ethernet over L2TPv3 to IESG
    Done  WG Last Call on L2TP Failover
    Done  WG Last Call on L2TP Tunnel Switching
    Mar 2005  WG Last Call on L2TP RADIUS and Infomsg Extensions

    Internet-Drafts:

    PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3) (95299 bytes)
    Layer Two Tunneling Protocol - Setup of TDM Pseudowires (18731 bytes)
    Signaling and Encapsulation for the Transport of IP over L2TPv3 (39513 bytes)
    RADIUS & L2TP Extended NAS-Port AVPs (25354 bytes)

    Request For Comments:

    Layer Two Tunneling Protocol (L2TP) over Frame Relay (RFC 3070) (12940 bytes)
    L2TP Disconnect Cause Information (RFC 3145) (17421 bytes)
    Securing L2TP using IPSEC (RFC 3193) (63804 bytes)
    Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation (RFC 3437) (20820 bytes)
    Layer Two Tunnelling Protocol : ATM access network extensions (RFC 3301) (42756 bytes)
    L2TP Over AAL5 (RFC 3355) (25114 bytes)
    Layer Two Tunneling Protocol 'L2TP' Management Information Base (RFC 3371) (139974 bytes)
    L2TP IP Differentiated Services Extension (RFC 3308) (21536 bytes)
    L2TP IANA Considerations Update (RFC 3438) (9135 bytes)
    Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) (RFC 3573) (22758 bytes)
    L2TP Active Discovery Relay for PPPoE (RFC 3817) (37765 bytes)
    Layer Two Tunneling Protocol (Version 3) (RFC 3931) (214407 bytes)
    Extensions to support efficient carrying of multicast traffic in Layer-2 Tunneling Protocol (L2TP) (RFC 4045) (59140 bytes)
    High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) (RFC 4349) (22888 bytes)
    Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (RFC 4454) (58281 bytes)
    Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (RFC 4591) (28232 bytes)
    Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) (RFC 4667) (33166 bytes)
    Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (RFC 4719) (30764 bytes)
    Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) (RFC 4951) (53659 bytes)
    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.