L2TP is one of those protocols that quietly powers a huge chunk of the internet's plumbing — every time a DSL subscriber's PPP session gets handed from a local ISP's access concentrator to a distant network, L2TP is probably doing the hand-off. It's also half of the venerable L2TP/IPsec VPN stack still shipped in every major OS in 2026.

The problem. In the mid-1990s, dial-up PPP was the universal access protocol. But PPP assumed the user dialed directly into their service provider. As ISPs consolidated and corporate remote-access grew, you wanted a user to dial a local Network Access Server (NAS) and have their PPP session magically appear at a remote Home Gateway — extending the PPP link across the IP backbone. Cisco solved this with L2F (RFC 2341). Microsoft and friends solved it with PPTP. The IETF, predictably, told both camps to go sit in a room together. The result was L2TP, which borrowed L2F's clean separation between control and data channels and PPTP's wider deployment story.

Key design decisions:

• Two endpoint roles: the LAC (L2TP Access Concentrator) terminates the physical/PPP layer; the LNS (L2TP Network Server) terminates the PPP session logically. The PPP frames tunnel between them.
• Control and data multiplexed on one UDP port (1701). Control messages are reliable (sequence numbers, retransmissions, sliding window — TCP-lite implemented inside UDP). Data messages are best-effort, optionally sequenced.
• Tunnels contain sessions. One tunnel between an LAC/LNS pair carries many sessions, one per user PPP call. This amortizes setup cost and authentication.
• AVPs (Attribute-Value Pairs) encode every control message field. Vendors can add private AVPs with a "mandatory" bit — if you don't understand a mandatory AVP, you must tear the tunnel down. This is a remarkably forward-thinking extensibility design that protocols like Diameter would later echo.
• No built-in confidentiality. Famously, L2TP itself does not encrypt. The authors deliberately punted to IPsec (RFC 3193 spells out the marriage), arguing that tunneling and security are separable concerns. Critics called this a cop-out; in retrospect, it kept L2TP usable in contexts where IPsec was overkill (carrier backhaul) while still enabling secure VPN use.

Why it matters today. Three reasons. First, broadband: nearly every DSL provider in Europe and much of Asia runs PPPoE from the subscriber to a local BRAS, then L2TP from the BRAS to the ISP that actually owns the customer (LAC/LNS wholesale model). Without L2TP, the wholesale broadband market as we know it wouldn't exist. Second, VPN: L2TP/IPsec is still the lowest-common-denominator VPN on macOS, iOS, Windows, and Android — when WireGuard isn't an option, this stack is. Third, mobile: L2TPv3 (RFC 3931) generalized the protocol beyond PPP to tunnel arbitrary Layer 2 frames, and shows up in MPLS pseudowire deployments.

Quirky bits. The RFC has a delightful section explicitly noting that running L2TP over L2TP is allowed but "may cause undesirable interactions" — a polite way of saying don't do it. The hello-keepalive mechanism is optional but universally implemented because without it, half-dead tunnels accumulate forever. And the spec's authentication is just a CHAP-style shared-secret challenge, which is why anyone treating L2TP as a security boundary without IPsec is asking for trouble.