Layer 2 Tunneling Protocol
The Layer 2 Tunneling Protocol (L2TP) is a connection-oriented tunneling protocol that enables the transportation of Point-to-Point Protocol (PPP) packets across packet-switched networks, such as the Internet, in a manner transparent to both end-users and PPP applications.[1] Defined in RFC 2661, L2TP operates at the data link layer (Layer 2 of the OSI model) by encapsulating PPP frames into L2TP packets over IP networks, allowing the separation of physical Layer 2 termination from PPP session processing to support virtual private networks (VPNs) and remote access services.[1] This protocol facilitates multi-protocol support over PPP while relying on underlying transport protocols like IP/UDP for delivery, without providing inherent mechanisms for link establishment or encryption.[1] L2TP emerged in the late 1990s as a collaborative effort between Cisco Systems and Microsoft to combine the strengths of two predecessor protocols: Cisco's Layer 2 Forwarding (L2F) protocol, which focused on tunneling PPP over arbitrary networks, and Microsoft's Point-to-Point Tunneling Protocol (PPTP), which emphasized remote access tunneling over IP.[1] Standardized by the Internet Engineering Task Force (IETF) as a Proposed Standard in August 1999 through RFC 2661, L2TP addressed limitations in earlier protocols by providing a vendor-neutral framework for compulsory and voluntary tunneling scenarios, particularly for Internet Service Providers (ISPs) delivering dial-up and broadband services.[1] Subsequent extensions, such as RFC 3931 in 2005, introduced L2TP version 3 (L2TPv3) to broaden support beyond PPP to other Layer 2 payloads like Ethernet and Frame Relay, enhancing its applicability in provider-provisioned VPNs (PPVPNs).[2] At its core, L2TP architecture involves two primary endpoints: the L2TP Access Concentrator (LAC), which handles the user's initial Layer 2 connection (e.g., via dial-up or DSL) and initiates tunneling of PPP frames, and the L2TP Network Server (LNS), which acts as the PPP termination point and provides authentication, authorization, and accounting (AAA) services.[1] Communication occurs over logical tunnels that carry both control messages—for tunnel and session establishment, maintenance, and teardown using reliable sequenced delivery—and data messages that encapsulate PPP datagrams without reliability guarantees, relying instead on PPP's own error handling.[1] L2TP employs UDP as its transport layer protocol on port 1701 for both control and data channels, enabling operation over IP networks while supporting features like multi-session multiplexing within a single tunnel and optional host authentication during setup.[1] While L2TP excels in flexibility for service provider networks and cost reduction by avoiding dedicated leased lines, it lacks built-in security features such as encryption or payload integrity, making it vulnerable to eavesdropping and requiring integration with protocols like IPsec for secure VPN deployments.[3] In practice, L2TP/IPsec combinations are widely used for remote access VPNs, supporting protocols like Challenge Handshake Authentication Protocol (CHAP) and Extensible Authentication Protocol (EAP) for user verification, and it remains a key enabler for broadband aggregation and wholesale-retail ISP interconnections.[4]Overview
Description
The Layer 2 Tunneling Protocol (L2TP) is a computer networking protocol that enables the tunneling of Point-to-Point Protocol (PPP) frames across packet-switched networks, such as the Internet, in a manner that remains largely transparent to end-users and applications.[1] Developed as a standard method for extending PPP sessions over IP networks, L2TP combines features from earlier protocols like Layer 2 Forwarding (L2F) and Point-to-Point Tunneling Protocol (PPTP) to support virtual private networking (VPN) and remote access services.[1] L2TP relies on two primary components for tunnel establishment and operation: the L2TP Access Concentrator (LAC) and the L2TP Network Server (LNS). The LAC, typically located at the network access provider's edge, acts as the initial tunnel endpoint, encapsulating PPP frames from a remote user's device and forwarding them to the LNS over the intervening network.[1] The LNS, situated at the destination network (such as a corporate server), serves as the peer endpoint, terminating the logical PPP session and handling authentication, authorization, and further routing of the tunneled traffic.[1] Positioned at the data link layer (Layer 2) of the OSI model, L2TP provides tunneling services over the network (Layer 3) and transport (Layer 4) layers by encapsulating PPP frames within L2TP headers and then within User Datagram Protocol (UDP) packets for transport over IP.[1] The protocol operates using UDP port 1701 for both control messages, which establish and manage the tunnel, and data messages, which carry the encapsulated PPP payloads.[1] Once the L2TP tunnel is set up via an exchange of control messages between the LAC and LNS, PPP session negotiation occurs within the tunnel to authenticate users and configure the connection parameters.[1] L2TP itself does not provide encryption or confidentiality, and it is commonly paired with IPsec to secure the tunneled traffic.[1]Applications
The Layer 2 Tunneling Protocol (L2TP) is primarily employed in virtual private networks (VPNs) to facilitate remote access, enabling users to securely connect to corporate networks from distant locations, as well as site-to-site connections that link multiple office branches over public infrastructures.[5][6] It is also used for VPN connections on mobile devices, such as smartphones and tablets, enabling secure access over networks like Wi-Fi and cellular data.[7][8] In internet service provider (ISP) environments, L2TP plays a key role in tunneling Point-to-Point Protocol over Ethernet (PPPoE) or legacy dial-up sessions from customer premises equipment to centralized backend authentication and routing servers, thereby decoupling access termination from core network functions.[9][10] This architecture permits ISPs to aggregate subscriber traffic efficiently while maintaining compatibility with existing PPP-based authentication mechanisms. L2TP finds further application in broadband aggregation, where it consolidates traffic from diverse access technologies like DSL and cable into IP cores, and in wholesale access models that enable infrastructure providers to lease network capacity to retail partners without exposing underlying topologies.[11] In virtualized networks, it supports multi-tenant environments by allowing ISPs to virtualize infrastructure delivery, such as offering segmented services to business partners through isolated tunnels.[12][13] Key benefits of L2TP include its inherent compatibility with legacy PPP infrastructure, which eases integration into established dial-up and broadband systems without requiring overhauls.[14] It supports multiple PPP sessions within a single tunnel, optimizing resource use by multiplexing user connections over shared paths.[9] Additionally, its design promotes scalability for high-volume deployments, handling thousands of sessions in enterprise and ISP settings through dynamic tunnel management.[15][16] In contemporary deployments as of 2025, L2TP continues to be used in broadband network gateways (BNGs) for subscriber management, including in 5G fixed wireless access and IoT applications, where access concentrators hand off user traffic to ISPs.[10] For example, L2TP-enabled IoT SIM cards provide secure tunneling for 5G devices to LANs, and it is used for out-of-band management of 5G base stations by separating access from service delivery.[17][18]History
Development
The Layer 2 Tunneling Protocol (L2TP) originated as a collaborative effort between Microsoft and Cisco Systems to develop a vendor-neutral standard for tunneling Point-to-Point Protocol (PPP) frames over IP networks. The initial work began in 1996, when engineers from both companies recognized the need to merge the strengths of their respective proprietary protocols—Microsoft's Point-to-Point Tunneling Protocol (PPTP), introduced in 1995, and Cisco's Layer 2 Forwarding (L2F) protocol, developed around the same period—to address fragmentation in VPN tunneling solutions. PPTP provided robust PPP session management but was limited to Microsoft ecosystems, while L2F offered flexible forwarding across diverse network access servers yet lacked broad interoperability; the joint development aimed to create a unified protocol that leveraged PPP's authentication and multilink capabilities while enabling seamless extension of dial-up sessions over IP infrastructures.[19][1] Key contributors included Gurdeep Singh Pall and Glen Zorn from Microsoft, who brought expertise in PPTP's session control mechanisms, and W. Mark Townsley and Andrew Valencia from Cisco, who integrated L2F's tunneling architecture. The first Internet-Draft, titled "Layer Two Tunneling Protocol 'L2TP'", was submitted to the IETF's Point-to-Point Protocol Extensions (PPPEXT) working group in August 1996 by Pall, Valencia, and others, outlining the core protocol design for encapsulating PPP packets in UDP datagrams. This draft was influenced by emerging IETF requirements for efficient PPP transport over IP, emphasizing transparency to end-users and support for virtual private dial-up networks (VPDN). Development progressed through iterative revisions, with the protocol designed to support both LAC-initiated tunnels (where the access concentrator handles initial PPP negotiation) and LNS-initiated tunnels (where the network server manages sessions), providing flexibility for client-side and server-side deployments in enterprise and ISP environments.[19][1] A significant milestone occurred in May 1997, when Microsoft and Cisco publicly demonstrated interoperability between their L2TP implementations at an industry event, validating the protocol's cross-vendor compatibility during its third draft stage. This demonstration highlighted L2TP's potential to replace siloed solutions with a standardized approach, driven by the growing demand for secure remote access amid the Internet's expansion. By 1998, further refinements addressed IETF feedback on multilink support and header efficiency, setting the stage for formal standardization while ensuring the protocol's core focus on combining PPTP's encryption hooks with L2F's forwarding model for broader adoption.[20]Standardization
The Layer 2 Tunneling Protocol (L2TP) was formally standardized by the Internet Engineering Task Force (IETF) in RFC 2661, published on August 9, 1999, as a Proposed Standard. This document establishes the foundational specification for L2TP, detailing protocol versions, control and data message types, and the Attribute-Value Pair (AVP) mechanism for extensible parameter exchange between tunnel endpoints.[21] RFC 2661 builds on the Point-to-Point Protocol (PPP) framework from RFC 1661, enabling the tunneling of PPP sessions across IP networks while maintaining compatibility with existing dial-up and virtual private network (VPN) infrastructures.[21] Subsequent extensions expanded L2TP's capabilities beyond its initial PPP-centric design. RFC 3931, published on March 8, 2005, defines Layer Two Tunneling Protocol Version 3 (L2TPv3), which introduces support for non-PPP payloads and facilitates the tunneling of arbitrary Layer 2 protocols, including Ethernet pseudowires, Frame Relay, and ATM circuits, over IP or other packet-switched networks.[22] This version enhances flexibility for service providers by allowing pseudowire emulation without relying on PPP encapsulation. Additionally, RFC 3193, published in November 2001, outlines the integration of L2TP with IPsec to provide tunnel authentication, confidentiality, and integrity protection through Encapsulating Security Payload (ESP) or Authentication Header (AH) mechanisms.[23] For authentication and authorization, RFC 2868, published in June 2000, specifies RADIUS attributes tailored for tunnel protocols like L2TP, enabling centralized management of compulsory tunneling in dial-up environments.[24] L2TPv3's support for Ethernet transport was further detailed in RFC 4719, published on November 2006, which describes the encapsulation and pseudowire establishment procedures for carrying Ethernet frames over L2TPv3 sessions.[25] No major new core RFCs for L2TP have been issued since around 2010, though extensions like RFC 5515 (April 2009) added AVPs for access line information to convey physical line attributes in broadband scenarios. As of 2025, L2TP continues to see practical application and citation in vendor documentation, such as Cisco's configurations for L2TP-based subscriber management in Cloud Native Broadband Network Gateway (CN-BNG) deployments, underscoring its ongoing utility in ISP hand-off and VPN services, despite Microsoft's October 2024 announcement to deprecate L2TP in future Windows Server versions.[10][26] The protocol's specifications remain active as Proposed Standards, with IETF-maintained errata addressing minor clarifications but no formal obsoletions or advancements to Internet Standard status recorded.Protocol Operation
Tunneling Models
The Layer 2 Tunneling Protocol (L2TP) supports several architectural models for deploying tunnels, primarily centered around the roles of the L2TP Access Concentrator (LAC) and the L2TP Network Server (LNS). In the standard LAC-LNS model, the LAC serves as the access device, such as a network access server (NAS), which encapsulates and forwards Point-to-Point Protocol (PPP) frames from a remote client over an intervening network to the LNS. The LNS acts as the logical termination point for the PPP session, often integrated with a RADIUS server for authentication, authorization, and accounting (AAA). This model decouples PPP authentication and session management from the tunneling mechanism, allowing the LAC to handle initial access while centralizing user management at the LNS.[21] A variant of this architecture is the LNS-LAC model, where the LNS initiates the tunnel to the LAC to establish outgoing connections, such as for dial-out scenarios. In this setup, the LNS receives traffic destined for a remote endpoint and sends an Outgoing Call Request (OCRQ) message to the LAC, which then dials out to the target using PPP. This enables scalable outbound dialing from a central server to distributed access points, with load balancing across multiple LACs if needed.[21] L2TP also accommodates a peer-to-peer model, where equal nodes establish direct tunnels without a strict client-server hierarchy, commonly used for site-to-site virtual private networks (VPNs). Here, both endpoints function symmetrically, potentially acting as both LAC and LNS to exchange Layer 2 traffic bidirectionally over IP networks. These models support key topologies, including voluntary tunneling—where the client explicitly initiates the connection—and compulsory tunneling, enforced by the access network. Additionally, L2TP tunnels can host multiple sessions within a single control connection, optimizing resource use for concurrent PPP streams.[22]Message Types and Packet Exchange
The Layer 2 Tunneling Protocol (L2TP) employs two primary categories of messages: control messages for establishing, maintaining, and tearing down tunnels and sessions, and data messages for transporting encapsulated Point-to-Point Protocol (PPP) frames. Control messages operate over a reliable channel using UDP port 1701, incorporating sequence numbers for ordered delivery and acknowledgments to ensure reliability, while data messages use an unreliable channel without inherent retransmission mechanisms.[27][28][29] Tunnel establishment begins with the Start-Control-Connection-Request (SCCRQ) message sent by the tunnel initiator, such as a L2TP Access Concentrator (LAC) to a L2TP Network Server (LNS), containing attributes for negotiation like protocol version and framing capabilities. The responder replies with a Start-Control-Connection-Reply (SCCRP) if it accepts the parameters, potentially adjusting them via Attribute-Value Pairs (AVPs). Upon agreement, the initiator sends a Start-Control-Connection-Connected (SCCCN) message to confirm the tunnel, followed by Zero-Length Body (ZLB) acknowledgments from both ends to verify receipt and establish the reliable control connection, which uses a sliding window protocol with retransmissions on timeouts.[30][31][32][33] Periodic Hello messages may be exchanged to detect tunnel liveness during operation.[34] Within an established tunnel, sessions are created to carry individual PPP connections, supporting both incoming and outgoing call models depending on the LAC-LNS architecture. For an incoming call, the LAC sends an Incoming-Call-Request (ICRQ) to the LNS, specifying session parameters such as the called number; the LNS responds with an Incoming-Call-Reply (ICRP) if acceptable, followed by an Incoming-Call-Connected (ICCN) from the LAC to finalize the session, with ZLB acknowledgments ensuring control message delivery. In the outgoing call scenario, the LNS initiates with an Outgoing-Call-Request (OCRQ) to the LAC, which replies via Outgoing-Call-Reply (OCRP) and confirms with Outgoing-Call-Connected (OCCN) upon successful PPP negotiation.[35][36][37][38][39][40][41] Data messages in L2TP simply encapsulate PPP frames within the tunnel, prefixed with a short header that may include optional sequence numbers for reordering at the receiver, but they rely on the underlying UDP transport for delivery without reliability guarantees, allowing efficient forwarding of user traffic once sessions are active.[27][28] Sessions are torn down using a Call-Disconnect-Notify (CDN) message, sent by either endpoint with an error code indicating the reason, such as user request or administrative closure, followed by ZLB acknowledgment to close the session gracefully. Tunnel teardown occurs similarly via a Stop-Control-Connection-Notification (StopCCN) from either side, which triggers the closure of all associated sessions and the control connection, again confirmed with ZLB.[42][43][44][45] Error handling in message exchanges primarily relies on ZLB packets as acknowledgments for control messages, enabling retransmissions in the reliable control channel via exponential backoff timers when acknowledgments are not received, while data channel errors are managed at the PPP layer rather than L2TP itself.[29][30]Packet Format
The Layer 2 Tunneling Protocol (L2TP) encapsulates its packets within UDP datagrams for transport over IP networks, using UDP port 1701 as the standard destination port for both control and data messages.[46] This UDP encapsulation allows L2TP to traverse NAT and firewall environments, with the entire L2TP packet—including header and payload—carried as the UDP payload.[46] Optionally, L2TP packets may be further protected by IPsec Encapsulating Security Payload (ESP) for confidentiality and integrity, where IPsec wraps the UDP/IP packet.[47] L2TP packets share a common two-octet flags field at the start of the header, followed by optional fields, with the total header size varying from a minimum of 8 bytes (when no optional fields are present) up to 20 bytes or more including padding.[48] The flags field is 16 bits long and includes the type bit (T: 0 for data packets, 1 for control packets), length bit (L: 1 if the length field is present), sequence bit (S: 1 if sequence numbers are present), offset bit (O: 1 if offset padding is present), priority bit (P: 1 for preferential forwarding of data packets), and version bits (set to 2 for L2TP version 2).[48] If the L bit is set, a 16-bit length field follows, specifying the total length of the L2TP message in octets (mandatory for control packets).[48] Next are the 16-bit tunnel ID (identifying the L2TP tunnel) and 16-bit session ID (identifying the specific session within the tunnel), both locally significant to the sender.[48] Optional 16-bit sequence numbers (Ns for the sent sequence and Nr for the expected next sequence) follow if the S bit is set, providing reliability for control messages.[48] If the O bit is set, a 16-bit offset size field indicates the length of optional offset padding (always 0 for control packets), followed by the variable-length pad to align the payload.[48] Control messages consist of the header followed by one or more Attribute Value Pairs (AVPs), which are encoded in a Type-Length-Value (TLV) format to convey configuration and management information.[49] Each AVP begins with a 16-bit flags field (including M for mandatory and H for hidden AVPs), a 16-bit length (indicating total AVP size from 6 to 1023 octets), an optional 16-bit vendor ID (0 for IETF-defined AVPs), and a 16-bit attribute type, followed by the variable-length value field.[49] Mandatory AVPs (M bit set) must be recognized by the peer, or the session or tunnel is terminated; hidden AVPs (H bit set) are obscured using a shared secret for security.[50] Examples include the Message Type AVP (type 0, 16-bit value specifying control message types like Start-Control-Connection-Request), Assigned Tunnel ID AVP (type 1, 16-bit value assigning the peer's tunnel ID), and Framing Capabilities AVP (type 3, 32-bit bitmask indicating support for synchronous or asynchronous PPP framing).[51] Data messages carry the tunneled payload immediately after the header (and any offset padding), typically encapsulating a PPP frame with its own header and data.[52] The PPP frame is prefixed by the L2TP session header but retains its protocol field to indicate the encapsulated datalink protocol.[52] L2TP version 3 (L2TPv3) extends the protocol for pseudowire applications, introducing a revised header format without reliance on PPP and supporting direct IP encapsulation (protocol number 115) in addition to UDP.[53] The L2TPv3 data session header consists of a 32-bit session ID, optional 32- or 64-bit cookie for added security, and optional L2-specific sublayer fields including a 24-bit sequence number; pseudowire types are indicated via control AVPs like Pseudowire Type (type 68, 16-bit value specifying payloads such as Ethernet or Frame Relay).[54] Control headers in L2TPv3 mirror version 2 but use 32-bit IDs and include AVPs for pseudowire capabilities (type 62, variable list of supported types).[55] The payload in L2TPv3 data packets directly carries the Layer 2 frame corresponding to the pseudowire type, without PPP encapsulation.[56]| Field | Size (bits) | Description | Optional? |
|---|---|---|---|
| Flags | 16 | T (type), L (length), f (reserved), S (sequence), O (offset), P (priority), f (reserved), v (version: 2 for L2TPv2) | No |
| Length | 16 | Total L2TP message length in octets | Yes (L bit) |
| Tunnel ID | 16 | Tunnel identifier | No |
| Session ID | 16 | Session identifier | No |
| Ns (Sequence) | 16 | Next sent sequence number | Yes (S bit) |
| Nr (Sequence) | 16 | Next expected receive sequence | Yes (S bit) |
| Offset Size | 16 | Length of offset pad | Yes (O bit) |
| Offset Pad | Variable | Padding bytes to align payload | Yes (O bit) |