the L2TP data message contents. Thus, UDP checksums MAY be disabled
in order to reduce the associated packet processing burden at the
L2TP endpoints.
The L2TP header itself does not have its own checksum or integrity
check. However, use of the L2TP Session ID and Cookie pair guards
against accepting an L2TP data message if corruption of the Session
ID or associated Cookie has occurred. When the L2-Specific Sublayer
is present in the L2TP header, there is no built-in integrity check
for the information contained therein if UDP checksums or some other
integrity check is not employed. IPsec (see Section 4.1.3) may be
used for strong integrity protection of the entire contents of L2TP
data messages.
UDP checksums MUST be enabled for L2TP control messages.
4.1.3. L2TP and IPsec
The L2TP data channel does not provide cryptographic security of any
kind. If the L2TP data channel operates over a public or untrusted
IP network where privacy of the L2TP data is of concern or
sophisticated attacks against L2TP are expected to occur, IPsec
[RFC2401] MUST be made available to secure the L2TP traffic.
Either L2TP over UDP or L2TP over IP may be secured with IPsec.
[RFC3193] defines the recommended method for securing L2TPv2. L2TPv3
possesses identical characteristics to IPsec as L2TPv2 when running
over UDP and implementations MUST follow the same recommendation.
When operating over IP directly, [RFC3193] still applies, though
references to UDP source and destination ports (in particular, those
in Section 4, "IPsec Filtering details when protecting L2TP") may be
ignored. Instead, the selectors used to identify L2TPv3 traffic are
simply the source and destination IP addresses for the tunnel
endpoints together with the L2TPv3 IP protocol type, 115.
In addition to IP transport security, IPsec defines a mode of
operation that allows tunneling of IP packets. The packet-level
encryption and authentication provided by IPsec tunnel mode and that
provided by L2TP secured with IPsec provide an equivalent level of
security for these requirements.
IPsec also defines access control features that are required of a
compliant IPsec implementation. These features allow filtering of
packets based upon network and transport layer characteristics such
as IP address, ports, etc. In the L2TP tunneling model, analogous
filtering may be performed at the network layer above L2TP. These
network layer access control features may be handled at an LCCE via
vendor-specific authorization features, or at the network layer
itself by using IPsec transport mode end-to-end between the
communicating hosts. The requirements for access control mechanisms
are not a part of the L2TP specification, and as such, are outside
the scope of this document.
Protecting the L2TP packet stream with IPsec does, in turn, also
protect the data within the tunneled session packets while
transported from one LCCE to the other. Such protection must not be
considered a substitution for end-to-end security between
communicating hosts or applications.
4.1.4. IP Fragmentation Issues
Fragmentation and reassembly in network equipment generally require
significantly greater resources than sending or receiving a packet as
a single unit. As such, fragmentation and reassembly should be
avoided whenever possible. Ideal solutions for avoiding
fragmentation include proper configuration and management of MTU
sizes among the Remote System, the LCCE, and the IP network, as well
as adaptive measures that operate with the originating host (e.g.,
[RFC1191], [RFC1981]) to reduce the packet sizes at the source.
An LCCE MAY fragment a packet before encapsulating it in L2TP. For
example, if an IPv4 packet arrives at an LCCE from a Remote System
that, after encapsulation with its associated framing, L2TP, and IP,
does not fit in the available path MTU towards its LCCE peer, the
local LCCE may perform IPv4 fragmentation on the packet before tunnel
encapsulation. This creates two (or more) L2TP packets, each
carrying an IPv4 fragment with its associated framing. This
ultimately has the effect of placing the burden of fragmentation on
the LCCE, while reassembly occurs on the IPv4 destination host.
If an IPv6 packet arrives at an LCCE from a Remote System that, after
encapsulation with associated framing, L2TP and IP, does not fit in
the available path MTU towards its L2TP peer, the Generic Packet
Tunneling specification [RFC2473], Section 7.1 SHOULD be followed.
In this case, the LCCE should either send an ICMP Packet Too Big
message to the data source, or fragment the resultant L2TP/IP packet
(for reassembly by the L2TP peer).
If the amount of traffic requiring fragmentation and reassembly is
rather light, or there are sufficiently optimized mechanisms at the
tunnel endpoints, fragmentation of the L2TP/IP packet may be
sufficient for accommodating mismatched MTUs that cannot be managed
by more efficient means. This method effectively emulates a larger
MTU between tunnel endpoints and should work for any type of L2-
encapsulated packet. Note that IPv6 does not support "in-flight"
fragmentation of data packets. Thus, unlike IPv4, the MTU of the
path towards an L2TP peer must be known in advance (or the last
resort IPv6 minimum MTU of 1280 bytes utilized) so that IPv6
fragmentation may occur at the LCCE.
In summary, attempting to control the source MTU by communicating
with the originating host, forcing that an MTU be sufficiently large
on the path between LCCE peers to tunnel a frame from any other
interface without fragmentation, fragmenting IP packets before
encapsulation with L2TP/IP, or fragmenting the resultant L2TP/IP
packet between the tunnel endpoints, are all valid methods for
managing MTU mismatches. Some are clearly better than others
depending on the given deployment. For example, a passive monitoring
application using L2TP would certainly not wish to have ICMP messages
sent to a traffic source. Further, if the links connecting a set of
LCCEs have a very large MTU (e.g., SDH/SONET) and it is known that
the MTU of all links being tunneled by L2TP have smaller MTUs (e.g.,
1500 bytes), then any IP fragmentation and reassembly enabled on the
participating LCCEs would never be utilized. An implementation MUST
implement at least one of the methods described in this section for
managing mismatched MTUs, based on careful consideration of how the
final product will be deployed.
L2TP-specific fragmentation and reassembly methods, which may or may
not depend on the characteristics of the type of link being tunneled
(e.g., judicious packing of ATM cells), may be defined as well, but
these methods are outside the scope of this document.
4.2. Reliable Delivery of Control Messages
L2TP provides a lower level reliable delivery service for all control
messages. The Nr and Ns fields of the control message header (see
Section 3.2.1) belong to this delivery mechanism. The upper level
functions of L2TP are not concerned with retransmission or ordering
of control messages. The reliable control messaging mechanism is a
sliding window mechanism that provides control message retransmission
and congestion control. Each peer maintains separate sequence number
state for each control connection.
The message sequence number, Ns, begins at 0. Each subsequent
message is sent with the next increment of the sequence number. The
sequence number is thus a free-running counter represented modulo
65536. The sequence number in the header of a received message is
considered less than or equal to the last received number if its
value lies in the range of the last received number and the preceding
32767 values, inclusive. For example, if the last received sequence
number was 15, then messages with sequence numbers 0 through 15, as
well as 32784 through 65535, would be considered less than or equal.
Such a message would be considered a duplicate of a message already
received and ignored from processing. However, in order to ensure
that all messages are acknowledged properly (particularly in the case
of a lost ACK message), receipt of duplicate messages MUST be
acknowledged by the reliable delivery mechanism. This acknowledgment
may either piggybacked on a message in queue or sent explicitly via
an ACK message.
All control messages take up one slot in the control message sequence
number space, except the ACK message. Thus, Ns is not incremented
after an ACK message is sent.
The last received message number, Nr, is used to acknowledge messages
received by an L2TP peer. It contains the sequence number of the
message the peer expects to receive next (e.g., the last Ns of a
non-ACK message received plus 1, modulo 65536). While the Nr in a
received ACK message is used to flush messages from the local
retransmit queue (see below), the Nr of the next message sent is not
updated by the Ns of the ACK message. Nr SHOULD be sanity-checked
before flushing the retransmit queue. For instance, if the Nr
received in a control message is greater than the last Ns sent plus 1
modulo 65536, the control message is clearly invalid.
The reliable delivery mechanism at a receiving peer is responsible
for making sure that control messages are delivered in order and
without duplication to the upper level. Messages arriving out-of-
order may be queued for in-order delivery when the missing messages
are received. Alternatively, they may be discarded, thus requiring a
retransmission by the peer. When dropping out-of-order control
packets, Nr MAY be updated before the packet is discarded.
Each control connection maintains a queue of control messages to be
transmitted to its peer. The message at the front of the queue is
sent with a given Ns value and is held until a control message
arrives from the peer in which the Nr field indicates receipt of this
message. After a period of time (a recommended default is 1 second
but SHOULD be configurable) passes without acknowledgment, the
message is retransmitted. The retransmitted message contains the
same Ns value, but the Nr value MUST be updated with the sequence
number of the next expected message.
Each subsequent retransmission of a message MUST employ an
exponential backoff interval. Thus, if the first retransmission
occurred after 1 second, the next retransmission should occur after 2
seconds has elapsed, then 4 seconds, etc. An implementation MAY
place a cap upon the maximum interval between retransmissions. This
cap SHOULD be no less than 8 seconds per retransmission. If no peer
response is detected after several retransmissions (a recommended
default is 10, but MUST be configurable), the control connection and
all associated sessions MUST be cleared. As it is the first message
to establish a control connection, the SCCRQ MAY employ a different
retransmission maximum than other control messages in order to help
facilitate failover to alternate LCCEs in a timely fashion.
When a control connection is being shut down for reasons other than
loss of connectivity, the state and reliable delivery mechanisms MUST
be maintained and operated for the full retransmission interval after
the final message StopCCN message has been sent (e.g., 1 + 2 + 4 + 8
+ 8... seconds), or until the StopCCN message itself has been
acknowledged.
A sliding window mechanism is used for control message transmission
and retransmission. Consider two peers, A and B. Suppose A
specifies a Receive Window Size AVP with a value of N in the SCCRQ or
SCCRP message. B is now allowed to have a maximum of N outstanding
(i.e., unacknowledged) control messages. Once N messages have been
sent, B must wait for an acknowledgment from A that advances the
window before sending new control messages. An implementation may
advertise a non-zero receive window as small or as large as it
wishes, depending on its own ability to process incoming messages
before sending an acknowledgement. Each peer MUST limit the number
of unacknowledged messages it will send before receiving an
acknowledgement by this Receive Window Size. The actual internal
unacknowledged message send-queue depth may be further limited by
local resource allocation or by dynamic slow-start and congestion-
avoidance mechanisms.
When retransmitting control messages, a slow start and congestion
avoidance window adjustment procedure SHOULD be utilized. A
recommended procedure is described in Appendix A. A peer MAY drop
messages, but MUST NOT actively delay acknowledgment of messages as a
technique for flow control of control messages. Appendix B contains
examples of control message transmission, acknowledgment, and
retransmission.
4.3. Control Message Authentication
L2TP incorporates an optional authentication and integrity check for
all control messages. This mechanism consists of a computed one-way
hash over the header and body of the L2TP control message, a pre-
configured shared secret, and a local and remote nonce (random value)
exchanged via the Control Message Authentication Nonce AVP. This
per-message authentication and integrity check is designed to perform
a mutual authentication between L2TP nodes, perform integrity
checking of all control messages, and guard against control message
spoofing and replay attacks that would otherwise be trivial to mount.
At least one shared secret (password) MUST exist between
communicating L2TP nodes to enable Control Message Authentication.
See Section 5.4.3 for details on calculation of the Message Digest
and construction of the Control Message Authentication Nonce and
Message Digest AVPs.
L2TPv3 Control Message Authentication is similar to L2TPv2 [RFC2661]
Tunnel Authentication in its use of a shared secret and one-way hash
calculation. The principal difference is that, instead of computing
the hash over selected contents of a received control message (e.g.,
the Challenge AVP and Message Type) as in L2TPv2, the entire message
is used in the hash in L2TPv3. In addition, instead of including the
hash digest in just the SCCRP and SCCCN messages, it is now included
in all L2TP messages.
The Control Message Authentication mechanism is optional, and may be
disabled if both peers agree. For example, if IPsec is already being
used for security and integrity checking between the LCCEs, the
function of the L2TP mechanism becomes redundant and may be disabled.
Presence of the Control Message Authentication Nonce AVP in an SCCRQ
or SCCRP message serves as indication to a peer that Control Message
Authentication is enabled. If an SCCRQ or SCCRP contains a Control
Message Authentication Nonce AVP, the receiver of the message MUST
respond with a Message Digest AVP in all subsequent messages sent.
Control Message Authentication is always bidirectional; either both
sides participate in authentication, or neither does.
If Control Message Authentication is disabled, the Message Digest AVP
still MAY be sent as an integrity check of the message. The
integrity check is calculated as in Section 5.4.3, with an empty
zero-length shared secret, local nonce, and remote nonce. If an
invalid Message Digest is received, it should be assumed that the
message has been corrupted in transit and the message dropped
accordingly.
Implementations MAY rate-limit control messages, particularly SCCRQ
messages, upon receipt for performance reasons or for protection
against denial of service attacks.
4.4. Keepalive (Hello)
L2TP employs a keepalive mechanism to detect loss of connectivity
between a pair of LCCEs. This is accomplished by injecting Hello
control messages (see Section 6.5) after a period of time has elapsed
since the last data message or control message was received on an
L2TP session or control connection, respectively. As with any other
control message, if the Hello message is not reliably delivered, the
sending LCCE declares that the control connection is down and resets
its state for the control connection. This behavior ensures that a
connectivity failure between the LCCEs is detected independently by
each end of a control connection.
Since the control channel is operated in-band with data traffic over
the PSN, this single mechanism can be used to infer basic data
connectivity between a pair of LCCEs for all sessions associated with
the control connection.
Periodic keepalive for the control connection MUST be implemented by
sending a Hello if a period of time (a recommended default is 60
seconds, but MUST be configurable) has passed without receiving any
message (data or control) from the peer. An LCCE sending Hello
messages across multiple control connections between the same LCCE
endpoints MUST employ a jittered timer mechanism to prevent grouping
of Hello messages.
4.5. Forwarding Session Data Frames
Once session establishment is complete, circuit frames are received
at an LCCE, encapsulated in L2TP (with appropriate attention to
framing, as described in documents for the particular pseudowire
type), and forwarded over the appropriate session. For every
outgoing data message, the sender places the identifier specified in
the Local Session ID AVP (received from peer during session
establishment) in the Session ID field of the L2TP data header. In
this manner, session frames are multiplexed and demultiplexed between
a given pair of LCCEs. Multiple control connections may exist
between a given pair of LCCEs, and multiple sessions may be
associated with a given control connection.
The peer LCCE receiving the L2TP data packet identifies the session
with which the packet is associated by the Session ID in the data
packet’s header. The LCCE then checks the Cookie field in the data
packet against the Cookie value received in the Assigned Cookie AVP
during session establishment. It is important for implementers to
note that the Cookie field check occurs after looking up the session
context by the Session ID, and as such, consists merely of a value
match of the Cookie field and that stored in the retrieved context.
There is no need to perform a lookup across the Session ID and Cookie
as a single value. Any received data packets that contain invalid
Session IDs or associated Cookie values MUST be dropped. Finally,
the LCCE either forwards the network packet within the tunneled frame
(e.g., as an LNS) or switches the frame to a circuit (e.g., as an
LAC).
4.6. Default L2-Specific Sublayer
This document defines a Default L2-Specific Sublayer format (see
Section 3.2.2) that a pseudowire may use for features such as
sequencing support, L2 interworking, OAM, or other per-data-packet
operations. The Default L2-Specific Sublayer SHOULD be used by a
given PW type to support these features if it is adequate, and its
presence is requested by a peer during session negotiation.
Alternative sublayers MAY be defined (e.g., an encapsulation with a
larger Sequence Number field or timing information) and identified
for use via the L2-Specific Sublayer Type AVP.
Figure 4.6: Default L2-Specific Sublayer Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The S (Sequence) bit is set to 1 when the Sequence Number contains a
valid number for this sequenced frame. If the S bit is set to zero,
the Sequence Number contents are undefined and MUST be ignored by the
receiver.
The Sequence Number field contains a free-running counter of 2^24
sequence numbers. If the number in this field is valid, the S bit
MUST be set to 1. The Sequence Number begins at zero, which is a
valid sequence number. (In this way, implementations inserting
sequence numbers do not have to "skip" zero when incrementing.) The
sequence number in the header of a received message is considered
less than or equal to the last received number if its value lies in
the range of the last received number and the preceding (2^23-1)
values, inclusive.
4.6.1. Sequencing Data Packets
The Sequence Number field may be used to detect lost, duplicate, or
out-of-order packets within a given session.
When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP
data channel, this part of the link has the characteristic of being
able to reorder, duplicate, or silently drop packets. Reordering may
break some non-IP protocols or L2 control traffic being carried by
the link. Silent dropping or duplication of packets may break
protocols that assume per-packet indications of error, such as TCP
header compression. While a common mechanism for packet sequence
detection is provided, the sequence dependency characteristics of
individual protocols are outside the scope of this document.
If any protocol being transported by over L2TP data channels cannot
tolerate misordering of data packets, packet duplication, or silent
packet loss, sequencing may be enabled on some or all packets by
using the S bit and Sequence Number field defined in the Default L2-
Specific Sublayer (see Section 4.6). For a given L2TP session, each
LCCE is responsible for communicating to its peer the level of
sequencing support that it requires of data packets that it receives.
Mechanisms to advertise this information during session negotiation
are provided (see Data Sequencing AVP in Section 5.4.4).
When determining whether a packet is in or out of sequence, an
implementation SHOULD utilize a method that is resilient to temporary
dropouts in connectivity coupled with high per-session packet rates.
The recommended method is outlined in Appendix C.
4.7. L2TPv2/v3 Interoperability and Migration
L2TPv2 and L2TPv3 environments should be able to coexist while a
migration to L2TPv3 is made. Migration issues are discussed for each
media type in this section. Most issues apply only to
implementations that require both L2TPv2 and L2TPv3 operation.
However, even L2TPv3-only implementations must at least be mindful of
these issues in order to interoperate with implementations that
support both versions.
4.7.1. L2TPv3 over IP
L2TPv3 implementations running strictly over IP with no desire to
interoperate with L2TPv2 implementations may safely disregard most
migration issues from L2TPv2. All control messages and data messages
are sent as described in this document, without normative reference
to RFC 2661.
If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only
if it is not available, then L2TPv3 over UDP with automatic fallback
(see Section 4.7.3) MUST be used. There is no deterministic method
for automatic fallback from L2TPv3 over IP to either L2TPv2 or L2TPv3
over UDP. One could infer whether L2TPv3 over IP is supported by
sending an SCCRQ and waiting for a response, but this could be
problematic during periods of packet loss between L2TP nodes.
4.7.2. L2TPv3 over UDP
The format of the L2TPv3 over UDP header is defined in Section
4.1.2.1.
When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2
and shares the first two octets of header format with L2TPv2. The
Ver field is used to distinguish L2TPv2 packets from L2TPv3 packets.
If an implementation is capable of operating in L2TPv2 or L2TPv3
modes, it is possible to automatically detect whether a peer can
support L2TPv2 or L2TPv3 and operate accordingly. The details of
this fallback capability is defined in the following section.
4.7.3. Automatic L2TPv2 Fallback
When running over UDP, an implementation may detect whether a peer is
L2TPv3-capable by sending a special SCCRQ that is properly formatted
for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ
with its Ver field set to 2 (for L2TPv2), and ensuring that any
L2TPv3-specific AVPs (i.e., AVPs present within this document and not
defined within RFC 2661) in the message are sent with each M bit set
to 0, and that all L2TPv2 AVPs are present as they would be for
L2TPv2. This is done so that L2TPv3 AVPs will be ignored by an
L2TPv2-only implementation. Note that, in both L2TPv2 and L2TPv3,
the value contained in the space of the control message header
utilized by the 32-bit Control Connection ID in L2TPv3, and the 16-
bit Tunnel ID and
16-bit Session ID in L2TPv2, are always 0 for an SCCRQ. This