Layer Two Tunneling Protocol "L2TP"
updated by
- rfc-9601 — Propagating Explicit Congestion Notification across IP Tunnel Headers Separated by a Shim
Extracted elements (30)
Data messages use an unreliable channel by design—retransmission of lost PPP data frames would introduce unacceptable latency for real-time traffic. Only the control channel uses reliable delivery with sequence numbers and retransmission, keeping data forwarding efficient.
The M bit in AVPs is designed to be used conservatively: it should only be set for AVPs that are absolutely crucial to proper operation. Before setting M, implementors should consider that doing so will terminate any session or tunnel on a peer that does not recognize the AVP, making it the sender's responsibility for the resulting non-interoperability.
The Priority (P) bit in data message headers allows LCP echo requests and other keepalive traffic to receive preferential local queuing. Without it, temporary congestion could interfere with keepalive messages and cause unnecessary link loss.
The Ver value 1 in the L2TP header is reserved to permit detection of L2F (RFC 2341) packets arriving intermixed with L2TP packets. Receivers MUST discard packets with unknown Ver values, providing a clean separation from the predecessor protocol.
All reserved bits in the L2TP header MUST be set to 0 on outgoing messages and ignored on incoming messages. An AVP received with a reserved bit set to 1 MUST be treated as an unrecognized AVP.
Control messages utilize a reliable Control Channel within L2TP to guarantee delivery. Data messages are not retransmitted when packet loss occurs. The control channel uses a sliding window with sequence numbers and ZLB acknowledgment packets.
Human-readable text in all Result Code error messages and Vendor Name AVPs MUST be provided in the UTF-8 charset using the Default Language as specified in RFC 2277.
If the M bit is set on an unrecognized AVP within a session-associated message, the session MUST be terminated. If the M bit is set on an unrecognized AVP within a tunnel-associated message, the entire tunnel and all sessions within MUST be terminated. If the M bit is not set, the unrecognized AVP MUST be ignored.
Sequence numbers (Ns and Nr fields, indicated by the S bit) are required to be present in all control messages. The S bit MUST be set to 1 for control messages. The L bit and O bit are also MUST/MUST-NOT for control messages (L=1, O=0, P=0).
The H bit (AVP hiding) MUST only be set if a shared secret exists between LAC and LNS. A Random Vector AVP MUST precede the first AVP with the H bit set to 1 in any given control message.
The Message Type AVP MUST be the first AVP in every control message, immediately following the control message header. If the M-bit is set within the Message Type AVP and the message type is unknown, the tunnel MUST be cleared.
The Receive Window Size AVP specifies the number of outstanding control messages the peer may send before awaiting acknowledgment. If absent, the peer MUST assume a window size of 4 for its transmit window.
The Sequencing Required AVP (Attribute Type 39), when present in ICCN or OCCN, indicates that sequence numbers MUST always be present on the data channel for the associated session, allowing the LNS to enforce in-order delivery.
The Ver field in the L2TP header MUST be 2. Packets received with an unknown Ver field MUST be discarded. The value 1 is reserved to allow detection of intermixed L2F packets.
Tunnel IDs and Session IDs have local significance only; each endpoint assigns its own identifier to the same tunnel/session. The Tunnel ID and Session ID in each message are those of the intended recipient, not the sender. Before receiving an Assigned Tunnel ID AVP from a peer, messages MUST be sent with Tunnel ID = 0.
Use of the M-bit with new AVPs MUST provide the ability to configure the associated feature off, so that the AVP is either not sent or sent with the M-bit not set. This prevents non-interoperability in deployments where the feature is not supported.
L2TP defines 16 control message types: SCCRQ (1), SCCRP (2), SCCCN (3), StopCCN (4), HELLO (6) for control connection management; OCRQ (7), OCRP (8), OCCN (9), ICRQ (10), ICRP (11), ICCN (12), CDN (14) for call management; WEN (15) for error reporting; and SLI (16) for PPP session control.
Proxy LCP and Authentication AVPs (Attribute Types 26–33) allow the LAC to forward the PPP LCP CONFREQ exchange and authentication credentials to the LNS, enabling PPP to continue without re-negotiation. The LNS policy may still require renegotiation if the LAC is not trusted.
The Tie Breaker AVP (Attribute Type 5, 8 octets) is used in SCCRQ to resolve simultaneous tunnel creation between the same LAC-LNS pair. The endpoint sending the numerically lower value wins; equal values cause both sides to discard their tunnels.
IANA maintains registries for L2TP AVP Attribute Types (Section 10.1), Message Type AVP Values (Section 10.2), Result Code AVP values for both StopCCN and CDN (Section 10.3), Framing and Bearer Capabilities bits (Section 10.4), Proxy Authen Type values (Section 10.5), and AVP Header Bits (Section 10.6). Vendor-specific AVPs use IANA-assigned SMI Enterprise Codes as Vendor ID.
L2TP does not provide end-to-end security between the remote system and the home LAN. Applications requiring end-to-end confidentiality must use their own security mechanisms. The security boundary is only between the LAC and LNS tunnel endpoints.
L2TP itself provides no mandatory encryption or strong per-packet authentication. The document explicitly recommends use of IPsec for packet-level confidentiality and integrity, noting that L2TP tunnel authentication alone is insufficient for many environments.
L2TP tunnel authentication uses a CHAP-style challenge/response mechanism. The LAC and LNS exchange Challenge AVPs in SCCRQ/SCCRP and must return a valid Challenge Response AVP (16-octet MD5 hash) in SCCRP/SCCCN before the tunnel is considered authenticated.
Proxy PPP authentication passes potentially cleartext credentials (PAP passwords, MSCHAPv1 responses) from the LAC to the LNS inside AVPs. AVP hiding is recommended for these fields, but the underlying shared-secret-based hiding is not cryptographically strong; IPsec is recommended for environments requiring stronger protection.
Control connection states are: idle → (send/receive SCCRQ) → wait-ctl-reply or wait-ctl-conn → (exchange SCCRP/SCCCN) → established → (StopCCN or timeout) → idle. Both sides authenticate via CHAP-style challenge/response during the three-way handshake if tunnel authentication is required.
LAC incoming call states: idle → (receive call) → wait-reply → (receive ICRP) → wait-connect → (receive ICCN) → established → (CDN or disconnect) → idle. LNS incoming call states progress through wait-tunnel, wait-connect, and established on receipt of ICRQ, ICCN, and data.
LNS outgoing call states: idle → (send OCRQ) → wait-reply → (receive OCRP) → wait-connect → (receive OCCN) → established. LAC outgoing call states mirror this, initiating the physical call on receipt of OCRQ and reporting completion via OCCN.
Each AVP is encoded as: M/H bits + 4 reserved bits + 10-bit Length, 16-bit Vendor ID, 16-bit Attribute Type, followed by a variable-length Attribute Value. Maximum AVP size is 1023 octets; minimum Length is 6 (no value field).
The AVP hiding subformat encodes a 16-bit 'Length of Original Value', followed by the original attribute value, followed by optional random padding. The hidden value is produced by XOR-chaining MD5 hashes of (Attribute Number + shared secret + Random Vector) in 16-octet blocks, adapted from the RFC 2138 RADIUS obfuscation method.
The L2TP message header contains a flags/version octet pair (T, L, S, O, P bits plus 4-bit Ver), optional 16-bit Length, 16-bit Tunnel ID, 16-bit Session ID, optional 16-bit Ns, optional 16-bit Nr, and optional Offset Size/pad fields. All values are in network byte order.