Request for Comments: 3931 M. Townsley, Ed.
Category: Standards Track Cisco Systems
I. Goyret, Ed.
Lucent Technologies
March 2005
Layer Two Tunneling Protocol - Version 3 (L2TPv3)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes "version 3" of the Layer Two Tunneling
Protocol (L2TPv3). L2TPv3 defines the base control protocol and
encapsulation for tunneling multiple Layer 2 connections between two
IP nodes. Additional documents detail the specifics for each data
link type being emulated.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes from RFC 2661. . . . . . . . . . . . . . . . . . 4
1.2. Specification of Requirements. . . . . . . . . . . . . . 4
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Control Message Types. . . . . . . . . . . . . . . . . . 10
3.2. L2TP Header Formats. . . . . . . . . . . . . . . . . . . 11
3.2.1. L2TP Control Message Header. . . . . . . . . . . 11
3.2.2. L2TP Data Message. . . . . . . . . . . . . . . . 12
3.3. Control Connection Management. . . . . . . . . . . . . . 13
3.3.1. Control Connection Establishment . . . . . . . . 14
3.3.2. Control Connection Teardown. . . . . . . . . . . 14
3.4. Session Management . . . . . . . . . . . . . . . . . . . 15
3.4.1. Session Establishment for an Incoming Call . . . 15
3.4.2. Session Establishment for an Outgoing Call . . . 15
3.4.3. Session Teardown . . . . . . . . . . . . . . . . 16
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
4.1. L2TP Over Specific Packet-Switched Networks (PSNs) . . . 16
4.1.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 17
4.1.2. L2TP over UDP. . . . . . . . . . . . . . . . . . 18
4.1.3. L2TP and IPsec . . . . . . . . . . . . . . . . . 20
4.1.4. IP Fragmentation Issues. . . . . . . . . . . . . 21
4.2. Reliable Delivery of Control Messages. . . . . . . . . . 23
4.3. Control Message Authentication . . . . . . . . . . . . . 25
4.4. Keepalive (Hello). . . . . . . . . . . . . . . . . . . . 26
4.5. Forwarding Session Data Frames . . . . . . . . . . . . . 26
4.6. Default L2-Specific Sublayer . . . . . . . . . . . . . . 27
4.6.1. Sequencing Data Packets. . . . . . . . . . . . . 28
4.7. L2TPv2/v3 Interoperability and Migration . . . . . . . . 28
4.7.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 29
4.7.2. L2TPv3 over UDP. . . . . . . . . . . . . . . . . 29
4.7.3. Automatic L2TPv2 Fallback. . . . . . . . . . . . 29
5. Control Message Attribute Value Pairs. . . . . . . . . . . . . 30
5.1. AVP Format . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Mandatory AVPs and Setting the M Bit . . . . . . . . . . 32
5.3. Hiding of AVP Attribute Values . . . . . . . . . . . . . 33
5.4. AVP Summary. . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. General Control Message AVPs . . . . . . . . . . 36
5.4.2. Result and Error Codes . . . . . . . . . . . . . 40
5.4.3. Control Connection Management AVPs . . . . . . . 43
5.4.4. Session Management AVPs. . . . . . . . . . . . . 48
5.4.5. Circuit Status AVPs. . . . . . . . . . . . . . . 57
6. Control Connection Protocol Specification. . . . . . . . . . . 59
6.1. Start-Control-Connection-Request (SCCRQ) . . . . . . . . 60
6.2. Start-Control-Connection-Reply (SCCRP) . . . . . . . . . 60
6.3. Start-Control-Connection-Connected (SCCCN) . . . . . . . 61
6.4. Stop-Control-Connection-Notification (StopCCN) . . . . . 61
6.5. Hello (HELLO). . . . . . . . . . . . . . . . . . . . . . 61
6.6. Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . 62
6.7. Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . 63
6.8. Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . 63
6.9. Outgoing-Call-Request (OCRQ) . . . . . . . . . . . . . . 64
6.10. Outgoing-Call-Reply (OCRP) . . . . . . . . . . . . . . . 65
6.11. Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . 65
6.12. Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . 66
6.13. WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . 66
6.14. Set-Link-Info (SLI). . . . . . . . . . . . . . . . . . . 67
6.15. Explicit-Acknowledgement (ACK) . . . . . . . . . . . . . 67
7. Control Connection State Machines. . . . . . . . . . . . . . . 68
7.1. Malformed AVPs and Control Messages. . . . . . . . . . . 68
7.2. Control Connection States. . . . . . . . . . . . . . . . 69
7.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 71
7.3.1. ICRQ Sender States . . . . . . . . . . . . . . . 72
7.3.2. ICRQ Recipient States. . . . . . . . . . . . . . 73
7.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 74
7.4.1. OCRQ Sender States . . . . . . . . . . . . . . . 75
7.4.2. OCRQ Recipient (LAC) States. . . . . . . . . . . 76
7.5. Termination of a Control Connection. . . . . . . . . . . 77
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 78
8.1. Control Connection Endpoint and Message Security . . . . 78
8.2. Data Packet Spoofing . . . . . . . . . . . . . . . . . . 78
9. Internationalization Considerations. . . . . . . . . . . . . . 79
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 80
10.1. Control Message Attribute Value Pairs (AVPs) . . . . . . 80
10.2. Message Type AVP Values. . . . . . . . . . . . . . . . . 81
10.3. Result Code AVP Values . . . . . . . . . . . . . . . . . 81
10.4. AVP Header Bits. . . . . . . . . . . . . . . . . . . . . 82
10.5. L2TP Control Message Header Bits . . . . . . . . . . . . 82
10.6. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 83
10.7. Circuit Status Bits. . . . . . . . . . . . . . . . . . . 83
10.8. Default L2-Specific Sublayer bits. . . . . . . . . . . . 84
10.9. L2-Specific Sublayer Type. . . . . . . . . . . . . . . . 84
10.10 Data Sequencing Level. . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . 85
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 87
Appendix A: Control Slow Start and Congestion Avoidance. . . . . . 89
Appendix B: Control Message Examples . . . . . . . . . . . . . . . 90
Appendix C: Processing Sequence Numbers. . . . . . . . . . . . . . 91
Editors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 94
1. Introduction
The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism
for tunneling Layer 2 (L2) "circuits" across a packet-oriented data
network (e.g., over IP). L2TP, as originally defined in RFC 2661, is
a standard method for tunneling Point-to-Point Protocol (PPP)
[RFC1661] sessions. L2TP has since been adopted for tunneling a
number of other L2 protocols. In order to provide greater
modularity, this document describes the base L2TP protocol,
independent of the L2 payload that is being tunneled.
The base L2TP protocol defined in this document consists of (1) the
control protocol for dynamic creation, maintenance, and teardown of
L2TP sessions, and (2) the L2TP data encapsulation to multiplex and
demultiplex L2 data streams between two L2TP nodes across an IP
network. Additional documents are expected to be published for each
L2 data link emulation type (a.k.a. pseudowire-type) supported by
L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents will
contain any pseudowire-type specific details that are outside the
scope of this base specification.
When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as
defined in RFC 2661 will be referred to as "L2TPv2", corresponding to
the value in the Version field of an L2TP header. (Layer 2
Forwarding, L2F, [RFC2341] was defined as "version 1".) At times,
L2TP as defined in this document will be referred to as "L2TPv3".
Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in
general.
1.1. Changes from RFC 2661
Many of the protocol constructs described in this document are
carried over from RFC 2661. Changes include clarifications based on
years of interoperability and deployment experience as well as
modifications to either improve protocol operation or provide a
clearer separation from PPP. The intent of these modifications is to
achieve a healthy balance between code reuse, interoperability
experience, and a directed evolution of L2TP as it is applied to new
tasks.
Notable differences between L2TPv2 and L2TPv3 include the following:
Separation of all PPP-related AVPs, references, etc., including a
portion of the L2TP data header that was specific to the needs of
PPP. The PPP-specific constructs are described in a companion
document.
Transition from a 16-bit Session ID and Tunnel ID to a 32-bit
Session ID and Control Connection ID, respectively.
Extension of the Tunnel Authentication mechanism to cover the
entire control message rather than just a portion of certain
messages.
Details of these changes and a recommendation for transitioning to
L2TPv3 are discussed in Section 4.7.
1.2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.3. Terminology
Attribute Value Pair (AVP)
The variable-length concatenation of a unique Attribute
(represented by an integer), a length field, and a Value
containing the actual value identified by the attribute. Zero or
more AVPs make up the body of control messages, which are used in
the establishment, maintenance, and teardown of control
connections. This basic construct is sometimes referred to as a
Type-Length-Value (TLV) in some specifications. (See also:
Control Connection, Control Message.)
Call (Circuit Up)
The action of transitioning a circuit on an L2TP Access
Concentrator (LAC) to an "up" or "active" state. A call may be
dynamically established through signaling properties (e.g., an
incoming or outgoing call through the Public Switched Telephone
Network (PSTN)) or statically configured (e.g., provisioning a
Virtual Circuit on an interface). A call is defined by its
properties (e.g., type of call, called number, etc.) and its data
traffic. (See also: Circuit, Session, Incoming Call, Outgoing
Call, Outgoing Call Request.)
Circuit
A general term identifying any one of a wide range of L2
connections. A circuit may be virtual in nature (e.g., an ATM
PVC, an IEEE 802 VLAN, or an L2TP session), or it may have direct
correlation to a physical layer (e.g., an RS-232 serial line).
Circuits may be statically configured with a relatively long-lived
uptime, or dynamically established with signaling to govern the
establishment, maintenance, and teardown of the circuit. For the
purposes of this document, a statically configured circuit is
considered to be essentially the same as a very simple, long-
lived, dynamic circuit. (See also: Call, Remote System.)
Client
(See Remote System.)
Control Connection
An L2TP control connection is a reliable control channel that is
used to establish, maintain, and release individual L2TP sessions
as well as the control connection itself. (See also: Control
Message, Data Channel.)
Control Message
An L2TP message used by the control connection. (See also:
Control Connection.)
Data Message
Message used by the data channel. (a.k.a. Data Packet, See also:
Data Channel.)
Data Channel
The channel for L2TP-encapsulated data traffic that passes between
two LCCEs over a Packet-Switched Network (i.e., IP). (See also:
Control Connection, Data Message.)
Incoming Call
The action of receiving a call (circuit up event) on an LAC. The
call may have been placed by a remote system (e.g., a phone call
over a PSTN), or it may have been triggered by a local event
(e.g., interesting traffic routed to a virtual interface). An
incoming call that needs to be tunneled (as determined by the LAC)
results in the generation of an L2TP ICRQ message. (See also:
Call, Outgoing Call, Outgoing Call Request.)
L2TP Access Concentrator (LAC)
If an L2TP Control Connection Endpoint (LCCE) is being used to
cross-connect an L2TP session directly to a data link, we refer to
it as an L2TP Access Concentrator (LAC). An LCCE may act as both
an L2TP Network Server (LNS) for some sessions and an LAC for
others, so these terms must only be used within the context of a
given set of sessions unless the LCCE is in fact single purpose
for a given topology. (See also: LCCE, LNS.)
L2TP Control Connection Endpoint (LCCE)
An L2TP node that exists at either end of an L2TP control
connection. May also be referred to as an LAC or LNS, depending
on whether tunneled frames are processed at the data link (LAC) or
network layer (LNS). (See also: LAC, LNS.)
L2TP Network Server (LNS)
If a given L2TP session is terminated at the L2TP node and the
encapsulated network layer (L3) packet processed on a virtual
interface, we refer to this L2TP node as an L2TP Network Server
(LNS). A given LCCE may act as both an LNS for some sessions and
an LAC for others, so these terms must only be used within the
context of a given set of sessions unless the LCCE is in fact
single purpose for a given topology. (See also: LCCE, LAC.)
Outgoing Call
The action of placing a call by an LAC, typically in response to
policy directed by the peer in an Outgoing Call Request. (See
also: Call, Incoming Call, Outgoing Call Request.)
Outgoing Call Request
A request sent to an LAC to place an outgoing call. The request
contains specific information not known a priori by the LAC (e.g.,
a number to dial). (See also: Call, Incoming Call, Outgoing
Call.)
Packet-Switched Network (PSN)
A network that uses packet switching technology for data delivery.
For L2TPv3, this layer is principally IP. Other examples include
MPLS, Frame Relay, and ATM.
Peer
When used in context with L2TP, Peer refers to the far end of an
L2TP control connection (i.e., the remote LCCE). An LAC’s peer
may be either an LNS or another LAC. Similarly, an LNS’s peer may
be either an LAC or another LNS. (See also: LAC, LCCE, LNS.)
Pseudowire (PW)
An emulated circuit as it traverses a PSN. There is one
Pseudowire per L2TP Session. (See also: Packet-Switched Network,
Session.)
Pseudowire Type
The payload type being carried within an L2TP session. Examples
include PPP, Ethernet, and Frame Relay. (See also: Session.)
Remote System
An end system or router connected by a circuit to an LAC.
Session
An L2TP session is the entity that is created between two LCCEs in
order to exchange parameters for and maintain an emulated L2
connection. Multiple sessions may be associated with a single
Control Connection.
Zero-Length Body (ZLB) Message
A control message with only an L2TP header. ZLB messages are used
only to acknowledge messages on the L2TP reliable control
connection. (See also: Control Message.)
2. Topology
L2TP operates between two L2TP Control Connection Endpoints (LCCEs),
tunneling traffic across a packet network. There are three
predominant tunneling models in which L2TP operates: LAC-LNS (or vice
versa), LAC-LAC, and LNS-LNS. These models are diagrammed below.
(Dotted lines designate network connections. Solid lines designate
circuit connections.)
Figure 2.0: L2TP Reference Models
(a) LAC-LNS Reference Model: On one side, the LAC receives traffic
from an L2 circuit, which it forwards via L2TP across an IP or other
packet-based network. On the other side, an LNS logically terminates
the L2 circuit locally and routes network traffic to the home
network. The action of session establishment is driven by the LAC
(as an incoming call) or the LNS (as an outgoing call).
+-----+ L2 +-----+ +-----+
| |------| LAC |.........[ IP ].........| LNS |...[home network]
+-----+ +-----+ +-----+
remote
system
|<-- emulated service -->|
|<----------- L2 service ------------>|
(b) LAC-LAC Reference Model: In this model, both LCCEs are LACs.
Each LAC forwards circuit traffic from the remote system to the peer
LAC using L2TP, and vice versa. In its simplest form, an LAC acts as
a simple cross-connect between a circuit to a remote system and an
L2TP session. This model typically involves symmetric establishment;
that is, either side of the connection may initiate a session at any
time (or simultaneously, in which a tie breaking mechanism is
utilized).
+-----+ L2 +-----+ +-----+ L2 +-----+
| |------| LAC |........[ IP ]........| LAC |------| |
+-----+ +-----+ +-----+ +-----+
remote remote
system system
|<- emulated service ->|
|<----------------- L2 service ----------------->|
(c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A
user-level, traffic-generated, or signaled event typically drives
session establishment from one side of the tunnel. For example, a
tunnel generated from a PC by a user, or automatically by customer
premises equipment.
+-----+ +-----+
[home network]...| LNS |........[ IP ]........| LNS |...[home network]
+-----+ +-----+
|<- emulated service ->|
|<---- L2 service ---->|
Note: In L2TPv2, user-driven tunneling of this type is often referred
to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as