Layer Two Tunneling Protocol - Version 3 (L2TPv3)
updated by
Extracted elements (31)
L2TPv3 transitions from 16-bit Session ID and Tunnel ID (L2TPv2) to a 32-bit Session ID and Control Connection ID, separates all PPP-specific constructs into a companion document, and extends tunnel authentication to cover the entire control message rather than just selected fields. These changes improve modularity and protocol security.
When operating L2TP directly over IP, a reserved Session ID of zero is used to distinguish control messages from data messages, rather than using a T bit. The zero Session ID check is considered more efficient—both in header size for data packets and in processing speed—than inspecting a single bit.
For automatic L2TPv2 fallback over UDP, an SCCRQ may be sent with Ver=2 and L2TPv3-specific AVPs having M bit=0, so that an L2TPv2-only peer ignores the new AVPs. An L2TPv3-only implementation MUST ignore all L2TPv2 AVPs in such an SCCRQ even if the M bit is set.
L2TPv3 over IP uses IANA-assigned IP protocol number 115. When operating over IP directly, the IPsec filtering selectors from RFC 3193 based on UDP ports are replaced by source and destination IP addresses plus protocol type 115.
An implementation MUST implement at least one of the specified methods for managing MTU mismatches: controlling source MTU via ICMP, configuring sufficient path MTU, fragmenting IP packets before L2TP encapsulation, or fragmenting the resulting L2TP/IP packet.
An L2TP session MUST be established before L2TP can begin to forward session frames. Multiple sessions may be bound to a single control connection, and multiple control connections may exist between the same two LCCEs.
At least one shared secret MUST exist between communicating L2TP nodes to enable Control Message Authentication. If an SCCRQ or SCCRP contains a Control Message Authentication Nonce AVP, the receiver MUST respond with a Message Digest AVP in all subsequent messages.
Each subsequent retransmission of a control message MUST employ an exponential backoff interval (e.g., 1, 2, 4, 8 seconds). If no peer response is detected after several retransmissions (default 10, but MUST be configurable), the control connection and all associated sessions MUST be cleared.
If the L2TP data channel operates over a public or untrusted network where privacy or sophisticated attacks are expected, IPsec MUST be made available to secure L2TP traffic. L2TPv3 over UDP MUST follow the recommendations in RFC 3193.
If the M bit is set on an AVP unrecognized by its recipient, the associated session MUST be shut down with a CDN (Result Code 2, Error Code 8), or if the message governs a control connection, a StopCCN MUST be sent. If the M bit is not set on an unrecognized AVP, it MUST be silently ignored.
L2TPv3 implementations MUST support L2TP over IP and SHOULD support L2TP over UDP for better NAT and firewall traversal and for easier migration from L2TPv2.
Periodic keepalive MUST be implemented by sending a Hello message if a configurable period (recommended default 60 seconds) has passed without receiving any message from the peer. An LCCE sending Hello messages across multiple control connections to the same endpoints MUST employ a jittered timer to prevent grouping.
The Cookie MUST be set to the configured or signaled random value for the session. Any received data packets that contain invalid Session IDs or associated Cookie values MUST be dropped.
The H bit MUST only be set if (1) a shared secret exists between the LCCEs and (2) Control Message Authentication is enabled. If H bit is set on any AVP in a message, at least one Random Vector AVP MUST also be present and MUST precede the first hidden AVP.
The recipient of a StopCCN MUST send an ACK message and maintain enough control connection state to properly accept StopCCN retransmissions over at least a full retransmission cycle (recommended at least 31 seconds).
UDP checksums MAY be disabled for L2TP data messages to reduce processing burden, but UDP checksums MUST be enabled for L2TP control messages.
When negotiating a control connection over UDP, control messages MUST be sent using registered UDP destination port 1701. Subsequent control and data traffic associated with the connection must use the same negotiated UDP port pair.
When using AVP hiding, the shared key is derived as HMAC-MD5(shared_secret, 1), and the AVP value is encrypted using a chained MD5-XOR scheme seeded by the Attribute Type, shared key, and a Random Vector AVP value. The same random vector MUST NOT be used for two different instances of an AVP with the same Attribute Type unless their values are identical.
The Control Connection ID is a 32-bit field with local significance only; each LCCE assigns its own identifier from its own number space. The Control Connection ID in each message is that of the intended recipient, not the sender; non-zero values are exchanged as Assigned Control Connection ID AVPs during setup.
The Cookie is an optional variable-length field (maximum 64 bits) in the session header that provides an additional check that a received data message is associated with the correct session. Random Cookie values are selected and exchanged as Assigned Cookie AVPs during session creation.
This document creates or updates the following IANA registries: Control Message AVP Attribute Types, Message Type AVP values, Result Code AVP values, AVP Header Bits, L2TP Control Message Header Bits, Pseudowire Types, Circuit Status Bits, Default L2-Specific Sublayer bits, L2-Specific Sublayer Type, and Data Sequencing Level.
Control Message Authentication uses a per-message HMAC-MD5 over the entire control message combined with a pre-shared secret and exchanged nonces, providing mutual authentication, integrity checking, and protection against spoofing and replay attacks. Authentication is always bidirectional and may be disabled if IPsec already provides equivalent protection.
The Cookie field provides a measure of protection against malicious data packet insertion attacks and against stray packets with recently reused or corrupted Session IDs. However, it does not substitute for strong cryptographic security such as IPsec; a well-chosen random Cookie is necessary for effective protection.
The L2TP data channel provides no cryptographic security of any kind. If privacy or protection against sophisticated attacks is required, IPsec MUST be used. IPsec protection of L2TP is not a substitute for end-to-end security between communicating hosts.
Control connection establishment uses a three-message exchange: SCCRQ (initiator) → SCCRP (responder) → SCCCN (initiator), transitioning through states idle → wait-ctl-reply → wait-ctl-conn → established. Teardown is triggered by a single StopCCN from either side.
Incoming session establishment uses a three-message exchange: ICRQ → ICRP → ICCN; outgoing session setup uses OCRQ → OCRP → OCCN. Either side may initiate teardown by sending a CDN message.
Each AVP is encoded as: 1-bit Mandatory (M) flag, 1-bit Hidden (H) flag, 4 reserved bits, 10-bit Length, 16-bit Vendor ID, 16-bit Attribute Type, and variable-length Attribute Value. The minimum AVP length is 6 octets; the maximum is 1023 octets.
The Default L2-Specific Sublayer is a 32-bit field containing: 1-bit S (Sequence) flag, 7 reserved bits, and a 24-bit Sequence Number. The S bit MUST be 1 when the sequence number is valid; if S is 0, the Sequence Number contents MUST be ignored.
The L2TP control message header contains: T bit (1), L bit (1), S bit (1), reserved x bits, 4-bit Ver field, 16-bit Length, 32-bit Control Connection ID, 16-bit Ns (send sequence number), and 16-bit Nr (receive sequence number). The T, L, and S bits MUST all be set to 1; Ver MUST be set to 3.
The L2TPv3 session header over IP consists of a 32-bit Session ID followed by an optional Cookie of up to 64 bits. The Session ID of zero is reserved for control messages; data messages carry a non-zero Session ID assigned by the peer.
The L2TPv3 session header over UDP contains: T bit (MUST be 0 for data), reserved x bits, 4-bit Ver field (MUST be 3), 16-bit Reserved field, 32-bit Session ID, and optional Cookie up to 64 bits. The Ver field must be checked before interpreting other bits to distinguish L2TPv2 from L2TPv3.