part of a software package on a host is sometimes referred to as an
"LAC Client" [RFC2661].
3. Protocol Overview
L2TP is comprised of two types of messages, control messages and data
messages (sometimes referred to as "control packets" and "data
packets", respectively). Control messages are used in the
establishment, maintenance, and clearing of control connections and
sessions. These messages utilize a reliable control channel within
L2TP to guarantee delivery (see Section 4.2 for details). Data
messages are used to encapsulate the L2 traffic being carried over
the L2TP session. Unlike control messages, data messages are not
retransmitted when packet loss occurs.
The L2TPv3 control message format defined in this document borrows
largely from L2TPv2. These control messages are used in conjunction
with the associated protocol state machines that govern the dynamic
setup, maintenance, and teardown for L2TP sessions. The data message
format for tunneling data packets may be utilized with or without the
L2TP control channel, either via manual configuration or via other
signaling methods to pre-configure or distribute L2TP session
information. Utilization of the L2TP data message format with other
signaling methods is outside the scope of this document.
Figure 3.0: L2TPv3 Structure
+-------------------+ +-----------------------+
| Tunneled Frame | | L2TP Control Message |
+-------------------+ +-----------------------+
| L2TP Data Header | | L2TP Control Header |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+-------------------+----+-----------------------+
| Packet-Switched Network (IP, FR, MPLS, etc.) |
+------------------------------------------------+
Figure 3.0 depicts the relationship of control messages and data
messages over the L2TP control and data channels, respectively. Data
messages are passed over an unreliable data channel, encapsulated by
an L2TP header, and sent over a Packet-Switched Network (PSN) such as
IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over
a reliable L2TP control channel, which operates over the same PSN.
The necessary setup for tunneling a session with L2TP consists of two
steps: (1) Establishing the control connection, and (2) establishing
a session as triggered by an incoming call or outgoing call. 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.
3.1. Control Message Types
The Message Type AVP (see Section 5.4.1) defines the specific type of
control message being sent.
This document defines the following control message types (see
Sections 6.1 through 6.15 for details on the construction and use of
each message):
Control Connection Management
0 (reserved)
1 (SCCRQ) Start-Control-Connection-Request
2 (SCCRP) Start-Control-Connection-Reply
3 (SCCCN) Start-Control-Connection-Connected
4 (StopCCN) Stop-Control-Connection-Notification
5 (reserved)
6 (HELLO) Hello
20 (ACK) Explicit Acknowledgement
Call Management
7 (OCRQ) Outgoing-Call-Request
8 (OCRP) Outgoing-Call-Reply
9 (OCCN) Outgoing-Call-Connected
10 (ICRQ) Incoming-Call-Request
11 (ICRP) Incoming-Call-Reply
12 (ICCN) Incoming-Call-Connected
13 (reserved)
14 (CDN) Call-Disconnect-Notify
Error Reporting
15 (WEN) WAN-Error-Notify
Link Status Change Reporting
16 (SLI) Set-Link-Info
3.2. L2TP Header Formats
This section defines header formats for L2TP control messages and
L2TP data messages. All values are placed into their respective
fields and sent in network order (high-order octets first).
3.2.1. L2TP Control Message Header
The L2TP control message header provides information for the reliable
transport of messages that govern the establishment, maintenance, and
teardown of L2TP sessions. By default, control messages are sent
over the underlying media in-band with L2TP data messages.
The L2TP control message header is formatted as follows:
Figure 3.2.1: L2TP Control Message Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 1, indicating that this is a control
message.
The L and S bits MUST be set to 1, indicating that the Length field
and sequence numbers are present.
The x bits are reserved for future extensions. All reserved bits
MUST be set to 0 on outgoing messages and ignored on incoming
messages.
The Ver field indicates the version of the L2TP control message
header described in this document. On sending, this field MUST be
set to 3 for all messages (unless operating in an environment that
includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section
4.1 for details).
The Length field indicates the total length of the message in octets,
always calculated from the start of the control message header itself
(beginning with the T bit).
The Control Connection ID field contains the identifier for the
control connection. L2TP control connections are named by
identifiers that have local significance only. That is, the same
control connection will be given unique Control Connection IDs by
each LCCE from within each endpoint’s own Control Connection ID
number space. As such, the Control Connection ID in each message is
that of the intended recipient, not the sender. Non-zero Control
Connection IDs are selected and exchanged as Assigned Control
Connection ID AVPs during the creation of a control connection.
Ns indicates the sequence number for this control message, beginning
at zero and incrementing by one (modulo 2**16) for each message sent.
See Section 4.2 for more information on using this field.
Nr indicates the sequence number expected in the next control message
to be received. Thus, Nr is set to the Ns of the last in-order
message received plus one (modulo 2**16). See Section 4.2 for more
information on using this field.
3.2.2. L2TP Data Message
In general, an L2TP data message consists of a (1) Session Header,
(2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as
depicted below.
Figure 3.2.2: L2TP Data Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Session Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2TP Session Header is specific to the encapsulating PSN over
which the L2TP traffic is delivered. The Session Header MUST provide
(1) a method of distinguishing traffic among multiple L2TP data
sessions and (2) a method of distinguishing data messages from
control messages.
Each type of encapsulating PSN MUST define its own session header,
clearly identifying the format of the header and parameters necessary
to setup the session. Section 4.1 defines two session headers, one
for transport over UDP and one for transport over IP.
The L2-Specific Sublayer is an intermediary layer between the L2TP
session header and the start of the tunneled frame. It contains
control fields that are used to facilitate the tunneling of each
frame (e.g., sequence numbers or flags). The Default L2-Specific
Sublayer for L2TPv3 is defined in Section 4.6.
The Data Message Header is followed by the Tunnel Payload, including
any necessary L2 framing as defined in the payload-specific companion
documents.
3.3. Control Connection Management
The L2TP control connection handles dynamic establishment, teardown,
and maintenance of the L2TP sessions and of the control connection
itself. The reliable delivery of control messages is described in
Section 4.2.
This section describes typical control connection establishment and
teardown exchanges. It is important to note that, in the diagrams
that follow, the reliable control message delivery mechanism exists
independently of the L2TP state machine. For instance, Explicit
Acknowledgement (ACK) messages may be sent after any of the control
messages indicated in the exchanges below if an acknowledgment is not
piggybacked on a later control message.
LCCEs are identified during control connection establishment either
by the Host Name AVP, the Router ID AVP, or a combination of the two
(see Section 5.4.3). The identity of a peer LCCE is central to
selecting proper configuration parameters (i.e., Hello interval,
window size, etc.) for a control connection, as well as for
determining how to set up associated sessions within the control
connection, password lookup for control connection authentication,
control connection level tie breaking, etc.
3.3.1. Control Connection Establishment
Establishment of the control connection involves an exchange of AVPs
that identifies the peer and its capabilities.
A three-message exchange is used to establish the control connection.
The following is a typical message exchange:
LCCE A LCCE B
------ ------
SCCRQ ->
<- SCCRP
SCCCN ->
3.3.2. Control Connection Teardown
Control connection teardown may be initiated by either LCCE and is
accomplished by sending a single StopCCN control message. As part of
the reliable control message delivery mechanism, the recipient of a
StopCCN MUST send an ACK message to acknowledge receipt of the
message and maintain enough control connection state to properly
accept StopCCN retransmissions over at least a full retransmission
cycle (in case the ACK message is lost). The recommended time for a
full retransmission cycle is at least 31 seconds (see Section 4.2).
The following is an example of a typical control message exchange:
LCCE A LCCE B
------ ------
StopCCN ->
(Clean up)
(Wait)
(Clean up)
An implementation may shut down an entire control connection and all
sessions associated with the control connection by sending the
StopCCN. Thus, it is not necessary to clear each session
individually when tearing down the whole control connection.
3.4. Session Management
After successful control connection establishment, individual
sessions may be created. Each session corresponds to a single data
stream between the two LCCEs. This section describes the typical
call establishment and teardown exchanges.
3.4.1. Session Establishment for an Incoming Call
A three-message exchange is used to establish the session. The
following is a typical sequence of events:
LCCE A LCCE B
------ ------
(Call
Detected)
ICRQ ->
<- ICRP
(Call
Accepted)
ICCN ->
3.4.2. Session Establishment for an Outgoing Call
A three-message exchange is used to set up the session. The
following is a typical sequence of events:
LCCE A LCCE B
------ ------
<- OCRQ
OCRP ->
(Perform
Call
Operation)
OCCN ->
(Call Operation
Completed
Successfully)
3.4.3. Session Teardown
Session teardown may be initiated by either the LAC or LNS and is
accomplished by sending a CDN control message. After the last
session is cleared, the control connection MAY be torn down as well
(and typically is). The following is an example of a typical control
message exchange:
LCCE A LCCE B
------ ------
CDN ->
(Clean up)
(Clean up)
4. Protocol Operation
4.1. L2TP Over Specific Packet-Switched Networks (PSNs)
L2TP may operate over a variety of PSNs. There are two modes
described for operation over IP, L2TP directly over IP (see Section
4.1.1) and L2TP over UDP (see Section 4.1.2). 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.
L2TP over other PSNs may be defined, but the specifics are outside
the scope of this document. Examples of L2TPv2 over other PSNs
include [RFC3070] and [RFC3355].
The following field definitions are defined for use in all L2TP
Session Header encapsulations.
Session ID
A 32-bit field containing a non-zero identifier for a session.
L2TP sessions are named by identifiers that have local
significance only. That is, the same logical session will be
given different Session IDs by each end of the control connection
for the life of the session. When the L2TP control connection is
used for session establishment, Session IDs are selected and
exchanged as Local Session ID AVPs during the creation of a
session. The Session ID alone provides the necessary context for
all further packet processing, including the presence, size, and
value of the Cookie, the type of L2-Specific Sublayer, and the
type of payload being tunneled.
Cookie
The optional Cookie field contains a variable-length value
(maximum 64 bits) used to check the association of a received data
message with the session identified by the Session ID. The Cookie
MUST be set to the configured or signaled random value for this
session. The Cookie provides an additional level of guarantee
that a data message has been directed to the proper session by the
Session ID. A well-chosen Cookie may prevent inadvertent
misdirection of stray packets with recently reused Session IDs,
Session IDs subject to packet corruption, etc. The Cookie may
also provide protection against some specific malicious packet
insertion attacks, as described in Section 8.2.
When the L2TP control connection is used for session
establishment, random Cookie values are selected and exchanged as
Assigned Cookie AVPs during session creation.
4.1.1. L2TPv3 over IP
L2TPv3 over IP (both versions) utilizes the IANA-assigned IP protocol
ID 115.
4.1.1.1. L2TPv3 Session Header Over IP
Unlike L2TP over UDP, the L2TPv3 session header over IP is free of
any restrictions imposed by coexistence with L2TPv2 and L2F. As
such, the header format has been designed to optimize packet
processing. The following session header format is utilized when
operating L2TPv3 over IP:
Figure 4.1.1.1: L2TPv3 Session Header Over IP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session ID and Cookie fields are as defined in Section 4.1. The
Session ID of zero is reserved for use by L2TP control messages (see
Section 4.1.1.2).
4.1.1.2. L2TP Control and Data Traffic over IP
Unlike L2TP over UDP, which uses the T bit to distinguish between
L2TP control and data packets, L2TP over IP uses the reserved Session
ID of zero (0) when sending control messages. It is presumed that
checking for the zero Session ID is more efficient -- both in header
size for data packets and in processing speed for distinguishing
between control and data messages -- than checking a single bit.
The entire control message header over IP, including the zero session
ID, appears as follows:
Figure 4.1.1.2: L2TPv3 Control Message Header Over IP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (32 bits of zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Named fields are as defined in Section 3.2.1. Note that the Length
field is still calculated from the beginning of the control message
header, beginning with the T bit. It does NOT include the "(32 bits
of zeros)" depicted above.
When operating directly over IP, L2TP packets lose the ability to
take advantage of the UDP checksum as a simple packet integrity
check, which is of particular concern for L2TP control messages.
Control Message Authentication (see Section 4.3), even with an empty
password field, provides for a sufficient packet integrity check and
SHOULD always be enabled.
4.1.2. L2TP over UDP
L2TPv3 over UDP must consider other L2 tunneling protocols that may
be operating in the same environment, including L2TPv2 [RFC2661] and
L2F [RFC2341].
While there are efficiencies gained by running L2TP directly over IP,
there are possible side effects as well. For instance, L2TP over IP
is not as NAT-friendly as L2TP over UDP.
4.1.2.1. L2TP Session Header Over UDP
The following session header format is utilized when operating L2TPv3
over UDP:
Figure 4.1.2.1: L2TPv3 Session Header over UDP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 0, indicating that this is a data message.
The x bits and Reserved field are reserved for future extensions.
All reserved values MUST be set to 0 on outgoing messages and ignored
on incoming messages.
The Ver field MUST be set to 3, indicating an L2TPv3 message.
Note that the initial bits 1, 4, 6, and 7 have meaning in L2TPv2
[RFC2661], and are deprecated and marked as reserved in L2TPv3.
Thus, for UDP mode on a system that supports both versions of L2TP,
it is important that the Ver field be inspected first to determine
the Version of the header before acting upon any of these bits.
The Session ID and Cookie fields are as defined in Section 4.1.
4.1.2.2. UDP Port Selection
The method for UDP Port Selection defined in this section is
identical to that defined for L2TPv2 [RFC2661].
When negotiating a control connection over UDP, control messages MUST
be sent as UDP datagrams using the registered UDP port 1701
[RFC1700]. The initiator of an L2TP control connection picks an
available source UDP port (which may or may not be 1701) and sends to
the desired destination address at port 1701. The recipient picks a
free port on its own system (which may or may not be 1701) and sends
its reply to the initiator’s UDP port and address, setting its own
source port to the free port it found.
Any subsequent traffic associated with this control connection
(either control traffic or data traffic from a session established
through this control connection) must use these same UDP ports.
It has been suggested that having the recipient choose an arbitrary
source port (as opposed to using the destination port in the packet
initiating the control connection, i.e., 1701) may make it more
difficult for L2TP to traverse some NAT devices. Implementations
should consider the potential implication of this capability before
choosing an arbitrary source port. A NAT device that can pass TFTP
traffic with variant UDP ports should be able to pass L2TP UDP
traffic since both protocols employ similar policies with regard to
UDP port selection.
4.1.2.3. UDP Checksum
The tunneled frames that L2TP carry often have their own checksums or
integrity checks, rendering the UDP checksum redundant for much of