Network Working Group J. Lau
Internet-Draft M. Townsley
Category: Standards Track A. Valencia
<draft-ietf-l2tpext-l2tp-base-00.txt> G. Zorn
cisco Systems
I. Goyret
Lucent Technologies
G. Pall
Microsoft Corporation
A. Rubens
Nexthop
B. Palter
Redback Networks
July 2001
Layer Two Tunneling Protocol "L2TP"
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress''.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-l2tpext-l2tp-base-00.txt> and expires January 2002. Please send
comments to the L2TP mailing list (l2tp@l2tp.net).
Copyright Notice
Townsley, et al. Standards Track [Page 1]
INTERNET DRAFT L2TP July 2001
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document describes the Layer Two Tunneling Protocol (L2TP).
L2TP tunnels Layer 2 packets across an intervening network in a way
that is as transparent as possible to both end-users and
applications.
Acknowledgments
The basic concept for L2TP and many of its protocol constructs were
adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these are
A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W.
Verthein, J. Taarud, W. Little, and G. Zorn.
The L2TP rewrite team for splitting RFC2661 into the base and
companion PPP specifications consisted of Ignacio Goyret, Jed Lau,
Bill Palter, Mark Townsley, and Madhvi Verma.
This document was based upon RFC2661, for which a number of people
provided valuable input and effort.
John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege,
Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and
review at the 43rd IETF in Orlando, FL., which led to improvement of
the overall readability and clarity of RFC2661.
Thomas Narten provided a great deal of critical review, formatting,
and wrote the IANA Considerations section.
Dory Leifer made valuable refinements to the protocol definition of
L2TP and contributed to the editing of early drafts leading to
RFC2661.
Steve Cobb and Evan Caves redesigned the state machine tables.
Barney Wolff provided a great deal of design input on the endpoint
authentication mechanism.
Townsley, et al. Standards Track [Page 2]
INTERNET DRAFT L2TP July 2001
Contents
Status of this Memo.......................................... 1
1. Introduction............................................. 5
1.1 Changes from RFC 2661................................ 5
1.2 Specification of Requirements........................ 6
1.3 Terminology.......................................... 6
2. Topology................................................. 9
3. Protocol Overview........................................ 10
3.1 Control Message Types................................ 11
3.2 L2TP Header Formats.................................. 12
3.2.1 L2TP Control Message Header Format.............. 12
3.2.2 L2TP Data Message Header Format................. 13
3.3 Control Connection Management........................ 15
3.3.1 Control Connection Establishment................ 15
3.3.2 Control Connection Teardown..................... 15
3.4 Call Management...................................... 16
3.4.1 Incoming Call Establishment..................... 16
3.4.2 Outgoing Call Establishment..................... 16
3.4.3 Session Teardown................................ 17
4. Control Message Attribute Value Pairs.................... 17
4.1 AVP Format........................................... 17
4.2 Mandatory AVPs....................................... 18
4.3 Hiding of AVP Attribute Values....................... 19
4.4 AVP Summary.......................................... 21
4.4.1 AVPs Applicable to All Control Messages......... 22
4.4.2 Result and Error Codes.......................... 23
4.4.3 Control Connection Management AVPs.............. 25
4.4.4 Call Management AVPs............................ 32
4.4.5 Call Status AVPs................................ 39
5. Protocol Operation....................................... 40
5.1 Migration from L2TPv2 to L2TPv3...................... 40
5.1.1 L2TPv3-Only Implementations..................... 41
5.1.2 L2TPv2/v3 Implementations....................... 41
5.2 Reliable Delivery of Control Messages................ 41
5.3 LCCE Authentication.................................. 44
5.4 Keepalive (Hello).................................... 44
5.5 Forwarding Session Frames............................ 45
5.7 In-Band Operation of the Control and Data Channels... 45
6. Control Connection Protocol Specification................ 46
6.1 Start-Control-Connection-Request (SCCRQ)............. 46
6.2 Start-Control-Connection-Reply (SCCRP)............... 46
Townsley, et al. Standards Track [Page 3]
INTERNET DRAFT L2TP July 2001
6.3 Start-Control-Connection-Connected (SCCCN)........... 47
6.4 Stop-Control-Connection-Notification (StopCCN)....... 47
6.5 Hello (HELLO)........................................ 48
6.6 Incoming-Call-Request (ICRQ)......................... 48
6.7 Incoming-Call-Reply (ICRP)........................... 48
6.8 Incoming-Call-Connected (ICCN)....................... 49
6.9 Outgoing-Call-Request (OCRQ)......................... 49
6.10 Outgoing-Call-Reply (OCRP).......................... 50
6.11 Outgoing-Call-Connected (OCCN)...................... 51
7. Control Connection State Machines........................ 51
7.1 Malformed Control Messages........................... 51
7.2 Timing Considerations................................ 52
7.3 Control Connection States............................ 52
7.4 Incoming Calls....................................... 54
7.4.1 ICRQ Sender States.............................. 55
7.4.2 ICRQ Recipient States........................... 56
7.5 Outgoing Calls....................................... 57
7.5.1 OCRQ Sender States.............................. 58
7.5.2 OCRQ Recipient (LAC) States..................... 59
7.6 Termination of a Control Connection.................. 60
8. L2TP Over Specific Media................................. 60
8.1 L2TP Control Connection over UDP/IP.................. 61
8.2 L2TP Data Channel over IP............................ 61
8.3 L2TP Data Channel over UDP........................... 61
9. Security Considerations.................................. 62
9.1 Control Connection Endpoint Security................. 62
9.2 Packet Level Security................................ 63
9.3 End-to-End Security.................................. 63
9.4 L2TP and IPsec....................................... 63
10. IANA Considerations..................................... 64
10.1 AVP Attributes...................................... 64
10.2 Message Type AVP Values............................. 64
10.3 Result Code AVP Values.............................. 64
10.3.1 Result Code Field Values....................... 64
10.3.2 Error Code Field Values........................ 65
10.4 AVP Header Bits..................................... 65
11. References.............................................. 65
12. Editors' Addresses...................................... 66
Appendix A: Control Slow Start and Congestion Avoidance...... 67
Appendix B: Control Message Examples......................... 68
Townsley, et al. Standards Track [Page 4]
INTERNET DRAFT L2TP July 2001
Appendix C: Intellectual Property Notice..................... 69
1. Introduction
The Layer Two Tunneling Protocol (L2TP) provides a dynamic tunneling
mechanism for multiple Layer 2 (L2) circuits across a packet-oriented
data network. L2TP, as originally defined in RFC 2661, describes a
standard method for tunneling PPP sessions. L2TP has since been
adopted for tunneling of a number of other L2 protocols. In order to
provide greater modularity, this document describes the base L2TP
protocol, independent of the L2 encapsulation that is being tunneled.
The base L2TP protocol consists of (1) the control protocol for
dynamic creation, maintenance, and teardown of L2TP sessions, and (2)
the protocol-independent portion of the L2TP encapsulation to
multiplex and demultiplex arbitrary L2 packet streams.
1.1 Changes from RFC 2661
Most 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 with RFC 2661, and extension of L2TP into new application
spaces.
For the remainder of this document, L2TP as defined in RFC 2661 will
be referred to as "L2TPv2", corresponding to the value in the Version
field of an L2TP control message header. (Recall that L2F was
defined as version 1). L2TP as defined in this document will be
referred to as "L2TPv3".
Notable differences between L2TPv2 and L2TPv3 include:
- 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 contructs 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.
- Better separation of the data channel and control channel.
Details of the these changes and a recommendation for transitioning
to L2TPv3 may be found in Section 5.1.
Townsley, et al. Standards Track [Page 5]
INTERNET DRAFT L2TP July 2001
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) and a Value containing the actual
value identified by the attribute. Multiple AVPs make up control
messages, which are used in the establishment, maintenance, and
teardown of control connections. This construct is known as the
Type-Length-Value (TLV) in some specifications. (See also:
Control Connection, Control Message.)
Call
The action of transitioning a circuit on an LAC to an "up" or
"established" state. A call may be dynamically established
through signaling properties (e.g. an incoming or outgoing call
through the PSTN) or statically established (e.g. provisioning a
VC 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.)
CHAP
Challenge Handshake Authentication Protocol [RFC1994], a point-to-
point cryptographic challenge/response authentication protocol in
which the cleartext password is not passed over the line.
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
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 some method of in-band or out-of-band
control channel governing the establishment, maintenance, and
teardown of the circuit. For the purposes of this document, a
statically configured circuit is considered to be largely
equivalent to a simple dynamic circuit. (See also: Call, Remote
System.)
Townsley, et al. Standards Track [Page 6]
INTERNET DRAFT L2TP July 2001
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 channel 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. (See also: Data Channel.)
Data Channel
The channel of L2TP-encapsulated L2 traffic that passes between
two LCCEs, utilizing a specific data encapsulation method. L2TP
defines one base encapsulation method for L2 traffic, although
others may be used as well. (See also: Control Connection, Data
Message.)
Dominant LCCE
The LCCE that either solely initiated establishment of a control
connection, or won the tie breaker during control connection
establishment. (See also: LCCE, Section 4.4.3.)
Incoming Call
The action of receiving a call 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)
An LCCE that tunnels a circuit (either physically connected or
logically connected, as via another L2TP session) to another
Townsley, et al. Standards Track [Page 7]
INTERNET DRAFT L2TP July 2001
location using L2TP, without performing any native L2 packet
processing on the circuit. The LAC may tunnel to either an LNS or
another LAC. (See also: LCCE, LNS.)
L2TP Control Connection Endpoint (LCCE)
One end of an L2TP control connection, either an LAC or an LNS.
(See also: LAC, LNS.)
L2TP Network Server (LNS)
An LCCE that logically terminates a tunneled circuit locally and
that processes the tunneled traffic as though the circuit were
physically connected to the device. The LNS may tunnel to either
an LAC or another LNS. (See also: LCCE, LAC.)
Outgoing Call
The action of placing a call on an LAC, typically in response to
policy directed by the peer in an Outgoing Call Request message.
(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 for the LAC in placing the call,
information that is typically not known a priori by the LAC. (See
also: Call, Incoming Call, Outgoing Call.)
Peer
When used in context with L2TP, Peer refers to the far end of an
L2TP control connection (i.e. the far 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.)
Remote System
An end-system or router connected by a circuit to an LAC.
Session
An L2TP session is created by a particular L2TP control connection
between two LCCEs when a circuit is successfully established. The
circuit may either pass through (LAC) or terminate locally (LNS)
on the LCCEs, which maintain state for the circuit. There is a
one-to-one relationship between established L2TP sessions and
their associated circuits. (See also: Circuit, LAC, LCCE, LNS.)
Townsley, et al. Standards Track [Page 8]
INTERNET DRAFT L2TP July 2001
Zero-Length Body (ZLB) Message
A control packet with only an L2TP header. ZLB messages are used
for explicitly acknowledging packets on the reliable control
channel.
2. Topology
L2TP operates between two L2TP Control Connection Endpoints (LCCEs),
tunneling circuit traffic across a packet network. An L2TP Network
Server (LNS) is an LCCE that decapsulates tunneled L2 traffic and
directs it as incoming data towards a virtual L2 interface. In
contrast, an L2TP Access Concentrator (LAC) is an LCCE that merely
forwards tunneled traffic directly to a circuit (which may even be
another L2TP session).
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 traffic (at Layer 3) to the home
network. The action of session establishment may be driven by the
LAC (perhaps as an incoming call) or the LNS (perhaps as an outgoing
call). This model typically has, but does not require, a clear
initiator and responder.
+-----+ L2 +-----+ +-----+
| |------| LAC |....[packet network]....| 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. A LAC does not perform any native
handling of the tunneled L2 frame, and thus, does not utilize a
virtual L2 interface. Rather, a LAC acts as a simple cross-connect
between a circuit 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 perhaps simultaneously).
Townsley, et al. Standards Track [Page 9]
INTERNET DRAFT L2TP July 2001
+-----+ L2 +-----+ +-----+ L2 +-----+
| |------| LAC |...[packet network]...| LAC |------| |
+-----+ +-----+ +-----+ +-----+
remote remote
system system
|<- emulated service ->|
|<----------------- L2 service ----------------->|
(c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs.
Each LNS logically terminates the L2TP session locally, requiring
virtual L2 interfaces for each L2TP session on each side of the L2TP
session. A user-level or traffic-generated event typically drives
session establishment from one side of the control connection. Also
known as "voluntary tunneling" [RFC2809].
+-----+ +-----+
[home network]...| LNS |...[packet network]...| LNS |...[home network]
+-----+ +-----+
|<- emulated service ->|
|<---- L2 service ---->|
Note: If an LNS initiates session establishment due to an event
(generally user-driven), the LNS is sometimes referred to as a "LAC
Client" as defined in [RFC2661].
3. Protocol Overview
L2TP utilizes two types of messages: control messages and data
messages. Control messages are used in the establishment,
maintenance, and clearing of control connections and calls. These
messages utilize a reliable control channel within L2TP to guarantee
delivery (see Section 5.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.
While both the L2TP control channel and the L2TP data channel are
defined strictly in this document, the L2TP data channel MAY be
substituted with a different L2 tunneling encapsulation whose format
can negotiated by the L2TP control connection. Furthermore, the L2TP
data channel MAY be used without the control channel, if so desired.
However, it is strongly recommended that such practice be limited to
relatively small-scale deployments, or deployments in which some
other form of automatic control information distribution is employed.
Townsley, et al. Standards Track [Page 10]
INTERNET DRAFT L2TP July 2001
+-------------------+
| L2 Frames |
+-------------------+ +-----------------------+
| L2TP Data Messages| | L2TP Control Messages |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+-------------------+ +-----------------------+
| IP, UDP, ATM, etc.| | UDP, ATM, etc. |
+-------------------+ +-----------------------+
Figure 3.0: L2TPv3 Structure
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
first by an L2TP header and then a packet transport such as UDP,
Frame Relay, ATM, etc. Control messages are sent over a reliable
L2TP control channel, which may transmit packets either in-band (over
the same packet network) or out-of-band (over a different packet
network).
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. The
control connection MUST be established before an incoming or outgoing
call is initiated. 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 4.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.14 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
Townsley, et al. Standards Track [Page 11]
INTERNET DRAFT L2TP July 2001
5 (reserved)
6 (HELLO) Hello
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
3.2 L2TP Header Formats
This specification defines separate header formats for L2TP control
messages and L2TP data messages.
Where a field is marked as optional, its space does not exist in the
message if the field is, indeed, not present. All values are placed
into their respective fields and sent in network order (high order
octets first).
3.2.1 L2TP Control Message Header Format
The L2TP control message header is formatted as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.2.1: L2TP Control Message Header
The T bit MUST be set to 1, indicating that this is a control
message. This provides backwards compatibility with L2TPv2 control
messages and enables the ability for data and control messages to
operate in-band over the same channel.
Townsley, et al. Standards Track [Page 12]
INTERNET DRAFT L2TP July 2001
The L and S bits MUST be set to 1 for compatibility with L2TPv2.
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 (with one exception, see Section 5.1 for
details). Upon receipt, an implementation MUST accept an SCCRQ with
the Ver field set to 2 or 3 (see Section 5.1). All other messages
MUST have the Ver field set to 3 to be accepted by an L2TPv3
implementation.
The Length field indicates the total length of the message in octets.
The Control Connection ID field indicates 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 different Control Connection IDs by
each LCCE. The Control Connection ID in each message is that of the
intended recipient, not the sender. 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 Sections 5.4 and 5.8 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 5.2 for more
information on using this field.
3.2.2 L2TP Data Message Header Format
The L2TP data message header is formatted as follows:
Townsley, et al. Standards Track [Page 13]
INTERNET DRAFT L2TP July 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer (arbitrary length)... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunneled L2 Frame...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.2.2: L2TP Data Message Header
The Session ID field contains the identifier for a session. L2TP
sessions are named by identifiers that have local significance only.
That is, the same session will be given different Session IDs by each
end of the session. The Session ID specified in each message is that
of the intended recipient, not the sender. Session IDs are selected
and exchanged as Assigned Session ID AVPs during the creation of a
session. (See Section 5.7 for a discussion of in-band operation of
the control connection and data channel, which affects the Session ID
field.)
The Cookie field contains a 32-bit value used to check the
association of a received data packet with the session identified by
the Session ID. The cookie guards against the misrouting of data
packets, which could result if the incorrect Session ID is specified
in received packets (due to misconfiguration, header corruption, or
otherwise). Cookie values are selected and exchanged as Assigned
Cookie AVPs during the creation of a session.
The L2-Specific Sublayer is an intermediary layer between the fixed
L2TP data header (consisting of the Session ID and Cookie fields) and
the start of the inner L2 frame. It may contain control fields that
L2TP uses to facilitate the tunneling of the L2 frames (e.g. offset
bytes or sequence numbers). Because the sublayer is specific to each
L2 payload that may be tunneled using the L2TP data encapsulation,
the format of the sublayer is determined by the Pseudo Wire AVP (see
Section 4.4.4), which identifies the L2 payload. Further details are
defined in the appropriate L2 payload-specific companion documents.
The Tunneled L2 Frame consists of the encapsulated L2 traffic,
including any L2 framing that might be present.
Townsley, et al. Standards Track [Page 14]
INTERNET DRAFT L2TP July 2001
3.3 Control Connection Management
Two peers that wish to tunnel L2 traffic to each other must first
establish a reliable control connection between them. The control
connection handles the establishment and teardown of the L2TP
sessions and of the control connection itself. The reliable delivery
of control messages is described in Section 5.2.
This section describes the 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, ZLB
ACKs may be sent after any of the control messages indicated in the
exchanges below if an acknowledgement is not piggybacked on a later
control message. (See Section 5.2 for a description of the reliable
control message delivery mechanism.)
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 a ZLB ACK 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 ZLB ACK is lost). The recommended time for a full retransmission
cycle is at least 31 seconds (see Section 5.2). The following is an
example of a typical control message exchange:
LCCE A LCCE B
------ ------
StopCCN ->
(Clean up)
Townsley, et al. Standards Track [Page 15]
INTERNET DRAFT L2TP July 2001
(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 Call 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 Incoming Call Establishment
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
ICCN ->
3.4.2 Outgoing Call Establishment
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 ->
Townsley, et al. Standards Track [Page 16]
INTERNET DRAFT L2TP July 2001
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. Control Message Attribute Value Pairs
To maximize extensibility while still permitting interoperability, a
uniform method for encoding message types and bodies is used
throughout L2TP. This encoding will be termed AVP (Attribute-Value
Pair) in the remainder of this document.
4.1 AVP Format
Each AVP is encoded as:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Attribute Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[until Length is reached]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first six bits are a bit mask, describing the general attributes
of the AVP.
Two bits are defined in this document; the remaining bits are
reserved for future extensions. Reserved bits MUST be set to 0. An
AVP received with a reserved bit set to 1 MUST be treated as an
unrecognized AVP.
Mandatory (M) bit: Controls the behavior required of an
implementation that receives an AVP that is unrecognized or
malformed. The M bit of a given AVP should only be checked if the
AVP is unrecognized or malformed. If the M bit is set on an
Townsley, et al. Standards Track [Page 17]
INTERNET DRAFT L2TP July 2001
unrecognized or malformed AVP in a in a control message associated
with a particular session, the session MUST be terminated. If the M
bit is set on an unrecognized or malformed AVP within a control
message associated with a control connection, the control connection
(and all sessions bound to the control connection) MUST be
terminated. If the M bit is not set, an unrecognized AVP MUST be
ignored. The control message must then continue to be processed as
if the AVP had not been present.
Hidden (H) bit: Identifies the hiding of data in the Attribute Value
field of an AVP. This capability can be used to avoid the passing of
sensitive data, such as user passwords, as cleartext in an AVP.
Section 4.3 describes the procedure for performing AVP hiding.
Length: Encodes the number of octets (including the Overall Length
and bit mask fields) contained in this AVP. The Length may be
calculated as 6 + the length of the Attribute Value field in octets.
The field itself is 10 bits, permitting a maximum of 1023 octets of
data in a single AVP. The minimum Length of an AVP is 6. If the
Length is 6, then the Attribute Value field is absent.
Vendor ID: The IANA assigned "SMI Network Management Private
Enterprise Codes" [RFC1700] value. The value 0, corresponding to
IETF adopted attribute values, is used for all AVPs defined within
this document. Any vendor wishing to implement its own L2TP
extensions can use its own Vendor ID along with private Attribute
values, guaranteeing that they will not collide with any other
vendor's extensions or future IETF extensions. Note that there are
16 bits allocated for the Vendor ID, thus limiting this feature to
the first 65,535 enterprises.
Attribute Type: A 2-octet value with a unique interpretation across
all AVPs defined under a given Vendor ID.
Attribute Value: This is the actual value as indicated by the Vendor
ID and Attribute Type. It follows immediately after the Attribute
Type field and runs for the remaining octets indicated in the Length
(i.e., Length minus 6 octets of header). This field is absent if the
Length is 6.
4.2 Mandatory AVPs
Receipt of an unrecognized or malformed AVP that has the M bit set is
catastrophic to the session or control connection with which it is
associated. Thus, the M bit should only be defined for AVPs that are
absolutely crucial to proper operation of the session or control
connection. Furthermore, in the case in which the LAC or LNS
receives an unknown AVP with the M bit set and shuts down the session
Townsley, et al. Standards Track [Page 18]
INTERNET DRAFT L2TP July 2001
or control connection accordingly, it is the full responsibility of
the peer sending the Mandatory AVP to accept fault for causing a non-
interoperable situation. Before defining an AVP with the M bit set,
particularly a vendor-specific AVP, be sure that this is the intended
consequence.
When an adequate alternative exists to use of the M bit, it should be
utilized. For example, rather than simply sending an AVP with the M
bit set to determine if a specific extension exists, availability may
be identified by sending an AVP in a request message and expecting a
corresponding AVP in a reply message.
Use of the M bit with new AVPs (i.e. those not defined in this
document) MUST provide the ability to configure the associated
feature off, such that the AVP is either not sent, or sent with the M
bit not set.
On the other side, the recipient of a control message should only
check the M bit of an AVP when the AVP is determined to be
unrecognized or malformed. The M bit should not be checked for a
recognized and well-formatted AVP. This rule prevents the
possibility of a valid AVP resulting in a session or control
connection teardown, simply because its M bit was set to a value that
was unexpected by the receiving LCCE.
4.3 Hiding of AVP Attribute Values
The H bit in the header of each AVP provides a mechanism to indicate
to the receiving peer whether the contents of the AVP are hidden or
present in cleartext. This feature can be used to hide sensitive
control message data such as user passwords or user IDs.
The H bit MUST only be set if a shared secret exists between the
LCCEs and LCCE authentication has completed. The shared secret is
the same secret that is used for LCCE authentication (see Section
5.3). Hidden values MUST NOT be unhidden until after LCCE
authentication has completed successfully (perhaps requiring the
hidden value to be stored until after receipt of additional setup
messages). To do otherwise runs the risk of AVP data being utilized
without verifying the integrity of the shared secret. If the H bit
is set in any AVP(s) in a given control message, a Random Vector AVP
must also be present in the message and MUST precede the first AVP
having an H bit of 1.
Hiding an AVP value is done in several steps. The first step is to
take the length and value fields of the original (cleartext) AVP and
encode them into a Hidden AVP Subformat as follows:
Townsley, et al. Standards Track [Page 19]
INTERNET DRAFT L2TP July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Original Value | Original Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of Original Attribute Value: This is length of the Original
Attribute Value to be obscured in octets. This is necessary to
determine the original length of the Attribute Value that is lost
when the additional Padding is added.
Original Attribute Value: Attribute Value that is to be obscured.
Padding: Random additional octets used to obscure length of the
Attribute Value that is being hidden.
To mask the size of the data being hidden, the resulting subformat
MAY be padded as shown above. Padding does NOT alter the value
placed in the Length of Original Attribute Value field, but does
alter the length of the resultant AVP that is being created. For
example, if an Attribute Value to be hidden is 4 octets in length,
the unhidden AVP length would be 10 octets (6 + Attribute Value
length). After hiding, the length of the AVP will become 6 +
Attribute Value length + size of the Length of Original Attribute
Value field + Padding. Thus, if Padding is 12 octets, the AVP length
will be 6 + 4 + 2 + 12 = 24 octets.
Next, An MD5 hash is performed on the concatenation of:
+ the 2-octet Attribute number of the AVP
+ the shared secret
+ an arbitrary length random vector
The value of the random vector used in this hash is passed in the
value field of a Random Vector AVP. This Random Vector AVP must be
placed in the message by the sender before any hidden AVPs. The same
random vector may be used for more than one hidden AVP in the same
message. If a different random vector is used for the hiding of
subsequent AVPs, then a new Random Vector AVP must be placed in the
command message before the first AVP to which it applies.
The MD5 hash value is then XORed with the first 16 octet (or less)
segment of the Hidden AVP Subformat and placed in the Attribute Value
field of the Hidden AVP. If the Hidden AVP Subformat is less than 16
octets, the Subformat is transformed as if the Attribute Value field
had been padded to 16 octets before the XOR. Only the actual octets
Townsley, et al. Standards Track [Page 20]
INTERNET DRAFT L2TP July 2001
present in the Subformat are modified, and the length of the AVP is
not altered.
If the Subformat is longer than 16 octets, a second one-way MD5 hash
is calculated over a stream of octets consisting of the shared secret
followed by the result of the first XOR. That hash is XORed with the
second 16 octet (or less) segment of the Subformat and placed in the
corresponding octets of the Value field of the Hidden AVP.
If necessary, this operation is repeated, with the shared secret used
along with each XOR result to generate the next hash to XOR the next
segment of the value with.
The hiding method was adapted from RFC 2138 [RFC2138], which was
taken from the "Mixing in the Plaintext" section in the book "Network
Security" by Kaufman, Perlman and Speciner [KPS]. A detailed
explanation of the method follows:
Call the shared secret S, the Random Vector RV, and the Attribute
Value AV. Break the value field into 16-octet chunks p1, p2, etc.,
with the last one padded at the end with random data to a 16-octet
boundary. Call the ciphertext blocks c(1), c(2), etc. We will also
define intermediate values b1, b2, etc.
b1 = MD5(AV + S + RV) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
The String will contain c(1)+c(2)+...+c(i), where + denotes
concatenation.
On receipt, the random vector is taken from the last Random Vector
AVP encountered in the message prior to the AVP to be unhidden. The
above process is then reversed to yield the original value.
4.4 AVP Summary
The following sections contain a list of all L2TP AVPs defined in
this document.
Following the name of the AVP is a list indicating the message types
that utilize each AVP. After each AVP title follows a short
description of the purpose of the AVP, a detail (including a graphic)
of the format for the Attribute Value, and any additional information
needed for proper use of the AVP.
Townsley, et al. Standards Track [Page 21]
INTERNET DRAFT L2TP July 2001
4.4.1 AVPs Applicable to All Control Messages
Message Type (All Messages)
The Message Type AVP, Attribute Type 0, identifies the control
message herein and defines the context in which the exact meaning of
the following AVPs will be determined.
The Attribute Value field for this AVP has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Type is a 2-octet unsigned integer.
The Message Type AVP MUST be the first AVP in a message, immediately
following the control message header (defined in Section 3.2.1). See
Section 3.1 for the list of defined control message types and their
identifiers.
The Mandatory (M) bit within the Message Type AVP has special
meaning. Rather than an indication as to whether the AVP itself
should be ignored if not recognized or malformed, it is an indication
as to whether the control message itself should be ignored. If the M
bit is set within the Message Type AVP and the Message Type is
unknown to the implementation, the control connection MUST be
cleared. If the M bit is not set, then the implementation may ignore
an unknown message type. The M bit MUST be set to 1 for all message
types defined in this document. This AVP may not be hidden (the H
bit MUST be 0). The Length of this AVP is 8.
A vendor-specific control message may be defined by setting the
Vendor ID of the Message Type AVP to a value other than the IETF
Vendor ID of 0 (see Section 4.1).
Random Vector (All Messages)
The Random Vector AVP, Attribute Type 36, is used to enable the
hiding of the Attribute Value of arbitrary AVPs.
The Attribute Value field for this AVP has the following format:
Townsley, et al. Standards Track [Page 22]
INTERNET DRAFT L2TP July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octet String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Random Octet String may be of arbitrary length, although a random
vector of at least 16 octets is recommended. The string contains the
random vector for use in computing the MD5 hash to retrieve or hide
the Attribute Value of a hidden AVP (see Section 4.3).
More than one Random Vector AVP may appear in a message, in which
case a hidden AVP uses the Random Vector AVP most closely preceding
it. This AVP MUST precede the first AVP with the H bit set.
The M bit for this AVP SHOULD be set to 1. This AVP MUST NOT be
hidden (the H bit MUST be 0). The Length of this AVP is 6 plus the
length of the Random Octet String.
4.4.2 Result and Error Codes
Result Code (CDN, StopCCN)
The Result Code AVP, Attribute Type 1, indicates the reason for
terminating the control channel or session.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (opt) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Result Code is a 2-octet unsigned integer. The optional Error
Code is a 2-octet unsigned integer. An optional Error Message can
follow the Error Code field. Presence of the Error Code and Message
are indicated by the AVP Length field. The Error Message contains an
arbitrary string providing further (human readable) text associated
with the condition. Human readable text in all error messages MUST
be provided in the UTF-8 charset using the Default Language
[RFC2277].
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1. The Length is 8 if there is no Error
Code or Message, 10 if there is an Error Code and no Error Message,
Townsley, et al. Standards Track [Page 23]
INTERNET DRAFT L2TP July 2001
or 10 + the length of the Error Message if there is an Error Code and
Message.
Defined Result Code values for the StopCCN message are as follows:
0 - Reserved
1 - General request to clear control connection
2 - General error, Error Code indicates the problem
3 - Control channel already exists
4 - Requester is not authorized to establish a control channel
5 - The protocol version of the requester is not supported,
Error Code indicates highest version supported
6 - Requester is being shut down
7 - Finite State Machine error
Defined Result Code values for the CDN message are as follows:
0 - Reserved
1 - Call disconnected due to loss of carrier or circuit disconnect
2 - Call disconnected for the reason indicated
in Error Code
3 - Call disconnected for administrative reasons
4 - Call failed due to lack of appropriate facilities being
available (temporary condition)
5 - Call failed due to lack of appropriate facilities being
available (permanent condition)
6 - Invalid destination
7 - Call failed due to no carrier detected
8 - Call failed due to detection of a busy signal
9 - Call failed due to lack of a dial tone
10 - Call was not established within time allotted
11 - Call was connected but no appropriate framing was detected
TBA - Call was not established due to losing tie breaker
The Error Codes defined below pertain to types of errors that are not
specific to any particular L2TP request, but rather to protocol or
message format errors. If an L2TP reply indicates in its Result Code
that a general error occurred, the General Error value should be
examined to determine what the error was. The currently defined
General Error codes and their meanings are as follows:
0 - No general error
1 - No control connection exists yet for this pair of LCCEs
2 - Length is wrong
3 - One of the field values was out of range
4 - Insufficient resources to handle this operation now
5 - Invalid Session ID
6 - A generic vendor-specific error occurred
Townsley, et al. Standards Track [Page 24]
INTERNET DRAFT L2TP July 2001
7 - Try another. If initiator is aware of other possible responder
destinations, it should try one of them. This can be
used to guide an LAC or LNS based on policy.
8 - The session or control connection was shutdown due to receipt of
an unknown AVP with the M bit set (see Section 4.2). The Error
Message SHOULD contain the attribute of the offending AVP in
(human readable) text form.
9 - Try another directed. If an LAC or LNS is aware of other possible
destinations, it should inform the initiator of the control
connection or session. The Error Message MUST contain a
comma-separated list of addresses from which the initiator may
choose. If the L2TP data channel runs over IPv4, then this would
be a comma-separated list of IP addresses in the canonical
dotted-decimal format (i.e. "10.0.0.1, 10.0.0.2, 10.0.0.3") in the
UTF-8 charset using the Default Language [RFC2277]. If there are
no servers for the LAC or LNS to suggest, then Error Code 7 should
be used. The delimiter between addresses MUST be precisely a
single comma and a single space.
When a General Error Code of 6 is used, additional information about
the error SHOULD be included in the Error Message field.
Furthermore, a vendor-specific AVP MAY be sent to indicate the
problem more precisely.
4.4.3 Control Connection Management AVPs
Protocol Version (SCCRP, SCCRQ)
The Protocol Version AVP, Attribute Type 2, indicates the L2TP
protocol version of the sender.
The Attribute Value field for this AVP has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rev |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Ver field is a 1-octet unsigned integer containing the value 1.
Rev field is a 1-octet unsigned integer containing 0. This pertains
to L2TP version 1, revision 0. Note this is not the same version
number that is included in the header of each message.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1. The Length of this AVP is 8.
Tie Breaker (SCCRQ)
Townsley, et al. Standards Track [Page 25]
INTERNET DRAFT L2TP July 2001
The Tie Breaker AVP, Attribute Type 5, indicates that the sender
desires a single control connection to exist between the given LCCE
pair.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tie Breaker Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...(64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tie Breaker Value is an 8-octet value that is used to choose a
single control connection when two LCCEs request a control connection
concurrently. The recipient of a SCCRQ must check to see if a SCCRQ
has been sent to the peer, and if so, must compare its Tie Breaker
value with the received one. The lower value "wins", and the "loser"
MUST silently discard its control connection. In the case in which a
tie breaker is present on both sides and the value is equal, both
sides MUST discard their control connections and restart control
connection negotiation.
If a tie breaker is received and an outstanding SCCRQ has no tie
breaker value, the initiator that included the Tie Breaker AVP
"wins". If neither side issues a tie breaker, then two separate
control connections are opened.
In the case of a tie, the "winner" of the tie is declared the
"dominant LCCE". Session-level ties, as detected by End Identifier
AVP, are always won by the dominant LCCE. If there is no tie, the
dominant LCCE is always the initiator of the control connection (the
sender of the SCCRQ).
Tie breaker values MUST be random values.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 0. The Length of this AVP is 14.
Firmware Revision (SCCRP, SCCRQ)
The Firmware Revision AVP, Attribute Type 6, indicates the firmware
revision of the issuing device.
The Attribute Value field for this AVP has the following format:
Townsley, et al. Standards Track [Page 26]
INTERNET DRAFT L2TP July 2001
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Firmware Revision is a 2-octet unsigned integer encoded in a
vendor-specific format.
For devices that do not have a firmware revision (e.g. general
purpose computers running L2TP software modules), the revision of the
L2TP software module may be reported instead.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) is 8.
Host Name (SCCRP, SCCRQ)
The Host Name AVP, Attribute Type 7, indicates the name of the
issuing LAC or LNS.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Host Name is of arbitrary length, but MUST be at least 1 octet.
This name should be as broadly unique as possible; for hosts
participating in DNS [RFC1034], a hostname with fully qualified
domain would be appropriate. The Host Name MAY be used to identify
LCCE configuration, including the shared secret for LCCE
authentication (if enabled) and any other options defined for the
control connection.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1. The Length of this AVP is 6 plus the
length of the Host Name.
Vendor Name (SCCRP, SCCRQ)
The Vendor Name AVP, Attribute Type 8, contains a vendor-specific
(possibly human readable) string describing the type of LAC or LNS
being used.
Townsley, et al. Standards Track [Page 27]
INTERNET DRAFT L2TP July 2001
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Name ...(arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor Name is the indicated number of octets representing the
vendor string. Human readable text for this AVP MUST be provided in
the UTF-8 charset using the Default Language [RFC2277].
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6
plus the length of the Vendor Name.
Assigned Control Connection ID (SCCRP, SCCRQ, StopCCN)
The Assigned Control Connection ID AVP, Attribute Type TBA, encodes
the ID being assigned to this control connection by the sender.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Control Connection ID is a 4-octet non-zero unsigned
integer.
The Assigned Control Connection ID AVP establishes a value used to
multiplex and demultiplex multiple control connections between a pair
of LCCEs. Once the Assigned Control Connection ID AVP has been
received by an LCCE, the Control Connection ID specified in the AVP
MUST be included in the Control Connection ID field of all control
packets sent to the peer for the lifetime of the control connection.
Before the Assigned Control Connection ID AVP is received from a
peer, all control messages MUST be sent to that peer with a Control
Connection ID value of 0 in the header. Because a Control Connection
ID value of 0 is used in this special manner, the zero value MUST NOT
be sent as an Assigned Control Connection ID value.
If an LCCE needs to send a StopCCN to a peer but has not received an
Assigned Control Connection ID AVP from the peer, there are two cases
to consider. If an Assigned Control Connection ID AVP has been sent
to the peer in a previous message, its value MUST be sent as the
Townsley, et al. Standards Track [Page 28]
INTERNET DRAFT L2TP July 2001
Assigned Control Connection ID AVP in the StopCCN to allow the peer
to try to identify the appropriate control connection via a reverse
lookup. Alternatively, if an Assigned Control Connection ID has not
been sent to the peer in a previous message, a Control Connection ID
SHOULD be allocated and sent as the Assigned Control Connection ID
AVP so that the StopCCN may be reliably delivered. This is most
important if the StopCCN carries an essential directive within (e.g.
a Result Code of value 9 with an alternate address to which to
attempt connection). If an Assigned Control Connection ID AVP is not
sent in the StopCCN or any previous message, the StopCCN MUST NOT be
retransmitted.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1 (see Section 5.1). The Length (before hiding)
of this AVP is 10.
Receive Window Size (SCCRQ, SCCRP)
The Receive Window Size AVP, Attribute Type 10, specifies the receive
window size being offered to the remote peer.
The Attribute Value field for this AVP has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Window Size is a 2-octet unsigned integer.
If absent, the peer must assume a Window Size of 4 for its transmit
window. The remote peer may send the specified number of control
messages before it must wait for an acknowledgment.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1. The Length of this AVP is 8.
Challenge (SCCRP, SCCRQ)
The Challenge AVP, Attribute Type 11, indicates that the issuing peer
wishes to authenticate the LCCE using a CHAP-style authentication
mechanism.
The Attribute Value field for this AVP has the following format:
Townsley, et al. Standards Track [Page 29]
INTERNET DRAFT L2TP July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is one or more octets of random data.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1. The Length (before hiding) of this AVP is 6
plus the length of the Challenge.
Challenge Response (SCCCN, SCCRP)
The Response AVP, Attribute Type 13, provides a response to a
challenge received.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a 16-octet value reflecting the CHAP-style [RFC1994]
response to the challenge.
This AVP MUST be present in an SCCRP or SCCCN if a challenge was
received in the preceding SCCRQ or SCCRP, respectively. For purposes
of the ID value in the CHAP response calculation, the value of the
Message Type AVP for this message is used (e.g. 2 for an SCCRP, and 3
for an SCCCN).
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1. The Length (before hiding) of this AVP is
22.
Data Channel Capabilities List (SCCRP, SCCRQ)
The Data Channel Capabilities List AVP, Attribute Type TBA, indicates
the Data Channel Types that will be accepted by the sender. The
Townsley, et al. Standards Track [Page 30]
INTERNET DRAFT L2TP July 2001
sender of this AVP MUST be prepared to accept one or a combination of
the Data Channel Types specified in this list for a given session.
The specific Data Channel Types used for a session are identified by
the Data Channel Type List AVP.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Channel Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Channel Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Channel Types that may be included in the Data Channel
Capabilities List are as follows:
1 - IP
2 - UDP/IP in-band
3 - UDP/IP out-of-band
See Section 8 for a discussion of L2TP over specific media.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1 (see Section 5.1). The Length (before hiding)
of this AVP is 8 octets with one Data Channel Type specified, plus 2
octets for each additional Data Channel Type.
Pseudo Wire Capabilities List (SCCRP, SCCRQ)
The Pseudo Wire Capabilities List AVP, Attribute Type TBA, indicates
the L2 payload types that will be accepted by the sender. The
specific payload type of a given session is identified by the Pseudo
Wire Type AVP.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudo Wire Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Pseudo Wire Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Defined Pseudo Wire Types that may be included in the Pseudo Wire
Capabilities List are as follows:
Townsley, et al. Standards Track [Page 31]
INTERNET DRAFT L2TP July 2001
0 - PPP
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1 (see Section 5.1). The Length (before hiding)
of this AVP is 8 octets with one Pseudo Wire Type specified, plus 2
octets for each additional Pseudo Wire Type.
4.4.4 Call Management AVPs
Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
The Assigned Session ID AVP, Attribute Type TBA, encodes the ID being
assigned to this session by the sender.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Session ID is a 4-octet non-zero unsigned integer.
The Assigned Session ID AVP establishes a value used to multiplex and
demultiplex data sent over a control connection between two LCCEs.
Once this AVP has been received, the LCCE MUST pass this value in the
Session ID AVP of all session control messages that it subsequently
transmits to its peer on behalf of this session. Before the Assigned
Session ID AVP is received from a peer, control messages MUST be sent
to the peer with a Session ID AVP value of 0. Because a Session ID
value of 0 is used in this special manner, the zero value MUST NOT be
sent as an Assigned Session ID value.
If an LCCE needs to send a CDN to a peer but has not received an
Assigned Session ID AVP from the peer, there are two cases to
consider. If an Assigned Session ID AVP has been sent to the peer in
a previous message, its value MUST be sent as the Session ID AVP in
the CDN to allow the peer to try to identify the appropriate session
via a reverse lookup. Alternatively, if an Assigned Session ID has
not been sent to the peer in a previous message, the Session ID AVP
MUST NOT be sent in the CDN.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1 (see Section 5.1). The Length (before hiding)
of this AVP is 10.
Session ID (CDN, ICRP, ICRQ, ICCN, OCRP, OCRQ, OCCN)
Townsley, et al. Standards Track [Page 32]
INTERNET DRAFT L2TP July 2001
The Session ID AVP, Attribute Type TBA, encodes the ID that was
assigned to this session by the peer.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session ID is a 4-octet non-zero unsigned integer.
The Session ID AVP communicates the previously established value used
to multiplex and demultiplex data sent over a control connection
between two LCCEs. For an outgoing control message, the value of the
Session ID AVP is set to the Assigned Session ID AVP that had been
received from the peer in an earlier control message exchange.
Before the Assigned Session ID AVP is received from the peer, control
messages MUST be sent to the peer with a Peer-Assigned Session ID AVP
value of 0.
If an LCCE needs to send a CDN to a peer but has not received an
Assigned Session ID AVP from the peer, there are two cases. If an
Assigned Session ID AVP has been sent to the peer in a previous
message, its value MUST be sent as the Session ID AVP in the CDN to
allow the peer to attempt identify the appropriate session via a
reverse lookup. Alternatively, if an Assigned Session ID has not
been sent to the peer in a previous message, the Session ID AVP MUST
NOT be sent in the CDN.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1 (see Section 5.1). The Length (before hiding)
of this AVP is 10.
Call Serial Number (ICRQ, OCRQ)
The Call Serial Number AVP, Attribute Type 15, encodes an identifier
assigned by the LAC or LNS to this call.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Townsley, et al. Standards Track [Page 33]
INTERNET DRAFT L2TP July 2001
The Call Serial Number is a 32-bit value.
The Call Serial Number is intended to be an easy reference for
administrators on both ends of a control connection to use when
investigating call failure problems. Call Serial Numbers should be
set to progressively increasing values, which are likely to be unique
for a significant period of time across all interconnected LNSs and
LACs.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1. The Length (before hiding) of this AVP is
10.
End Identifier AVP (ICRQ, OCRQ)
The End Identifier AVP, Attribute Type TBA, encodes an identifier
assigned by the LAC or LNS to this call, used to detect ties in
session establishment for the same circuit.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Identifier ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The End Identifier contains interface, circuit, and other
information, depending on the circuit that is being tunneled. The
field may be a simple ASCII string. For example, a source interface
serial 1/1 and DLCI 100, and a destination interface serial 1/1 with
DLCI 200, could be represented as "serial 1/1 DLCI 100, serial 1/1
DLCI 200".
The format of the information contained in this AVP should be agreed
on by the administrators at the two LCCEs. Specification of this
format is outside the scope of this document.
A session-level tie is detected if an LCCE receives an ICRQ or OCRQ
with an End Identifier AVP whose value matches the End Identifier AVP
that was just sent in an outgoing ICRQ or OCRQ to the same peer. If
the two End Identifier values match, an LCCE recognizes that a tie
exists (i.e. both LCCEs are attempting to establish sessions for the
same circuit). The tie is broken by the dominant LCCE. The "losing"
LCCE must send a CDN to its peer to cancel the ICRQ or OCRQ that it
had sent to the peer.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
Townsley, et al. Standards Track [Page 34]
INTERNET DRAFT L2TP July 2001
AVP SHOULD be set to 1 (see Section 5.1). The Length (before hiding)
of this AVP is 6 plus the length of the End Identifier value.
Minimum BPS (OCRQ)
The Minimum BPS AVP, Attribute Type 16, encodes the lowest acceptable
line speed for this call.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum BPS is a 32-bit value indicates the speed in bits per
second.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1. The Length (before hiding) of this AVP is
10.
Maximum BPS (OCRQ)
The Maximum BPS AVP, Attribute Type 17, encodes the highest
acceptable line speed for this call.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Maximum BPS is a 32-bit value indicates the speed in bits per
second.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1. The Length (before hiding) of this AVP is
10.
Data Channel Type List (ICRQ, OCRQ)
The Data Channel Type List AVP, Attribute Type TBA, indicates the
data channel configurations that will be used by the sender for
outgoing data packets.
Townsley, et al. Standards Track [Page 35]
INTERNET DRAFT L2TP July 2001
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Channel Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Channel Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See the definition for the Data Channel Capabilities List AVP for a
list of defined Data Channel Types that may be included. Identifying
more than one Data Channel Type is an indication that packets may
arrive on any or all of the listed data channels. See Section 8 for
a discussion of L2TP over specific media.
A peer MUST NOT request an incoming or outgoing call with a Data
Channel List AVP specifying a Data Channel Type not advertised in the
Data Channel Capabilities List AVP it received during control
connection establishment. Attempts to do so will result in the
session being rejected.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1 (see Section 5.1). The Length (before hiding)
of this AVP is 8 octets with one Data Channel Type specified, plus 2
octets for each additional Data Channel Type.
Pseudo Wire Type (ICRQ, OCRQ)
The Pseudo Wire Type AVP, Attribute Type TBA, indicates the L2
payload type for the requested call.
The Attribute Value field for this AVP has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudo Wire Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See the definition for the Pseudo Wire Capabilities List AVP for a
list of defined Pseudo Wire Type values.
A peer MUST NOT request an incoming or outgoing call with a Pseudo
Wire Type AVP specifying a value not advertised in the Pseudo Wire
Capabilities List AVP it received during control connection
establishment. Attempts to do so will result in the call being
rejected.
Townsley, et al. Standards Track [Page 36]
INTERNET DRAFT L2TP July 2001
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1 (see Section 5.1). The Length (before hiding)
of this AVP is 8.
(Tx) Connect Speed (ICCN, OCCN)
The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the speed
of the facility chosen for the connection attempt.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (H) | BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The (Tx) Connect Speed BPS is a 4-octet value indicating the speed in
bits per second. A value of zero indicates that the speed is
indeterminable or that there is no physical point-to-point link.
When the optional Rx Connect Speed AVP is present, the value in this
AVP represents the transmit connect speed from the perspective of the
LAC (e.g. data flowing from the LAC to the remote system). When the
optional Rx Connect Speed AVP is NOT present, the connection speed
between the remote system and LAC is assumed to be symmetric and is
represented by the single value in this AVP.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1. The Length (before hiding) of this AVP is
10.
Rx Connect Speed (ICCN, OCCN)
The Rx Connect Speed AVP, Attribute Type 38, represents the speed of
the connection from the perspective of the LAC (e.g. data flowing
from the remote system to the LAC).
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (H) | BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BPS is a 4-octet value indicating the speed in bits per second. A
value of zero indicates that the speed is indeterminable or that
Townsley, et al. Standards Track [Page 37]
INTERNET DRAFT L2TP July 2001
there is no physical point-to-point link.
Presence of this AVP implies that the connection speed may be
asymmetric with respect to the transmit connect speed given in the
(Tx) Connect Speed AVP.
This AVP may be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) of this AVP is
10.
Physical Channel ID (ICRQ, OCRP)
The Physical Channel ID AVP, Attribute Type 25, encodes the vendor-
specific physical channel number used for a call.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Physical Channel ID is a 4-octet value intended to be used for
logging purposes only.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) of this AVP is
10.
Private Group ID (ICCN)
The Private Group ID AVP, Attribute Type 37, is used by the LAC to
indicate that this call is to be associated with a particular
customer group.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Group ID ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Private Group ID is a string of octets of arbitrary length.
The LNS MAY treat the session as well as network traffic through this
session in a special manner determined by the peer. For example, if
Townsley, et al. Standards Track [Page 38]
INTERNET DRAFT L2TP July 2001
the LNS is individually connected to several private networks using
unregistered addresses, this AVP may be included by the LAC to
indicate that a given call should be associated with one of the
private networks.
The Private Group ID is a string corresponding to a table in the LNS
that defines the particular characteristics of the selected group. A
LAC MAY determine the Private Group ID from a RADIUS response, local
configuration, or some other source.
This AVP may be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6
plus the length of the Private Group ID.
Assigned Cookie (ICRP, ICRQ, OCRQ, OCRP)
The Assigned Cookie AVP, Attribute Type TBA, encodes the cookie value
that the LCCE MUST include in the Cookie field of all outgoing data
packets.
The Attribute Value field for this AVP has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The cookie is a 4-octet unsigned integer.
The cookie value MUST be random data generated by the sender.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1 (see Section 5.1). The Length (before hiding)
of this AVP is 10.
4.4.5 Call Status AVPs
Circuit Errors (WEN)
The Circuit Errors AVP, Attribute Type 34, conveys circuit error
information to the peer.
The Attribute Value field for this AVP has the following format:
Townsley, et al. Standards Track [Page 39]
INTERNET DRAFT L2TP July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Hardware Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns (L) | Buffer Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns (L) | Time-out Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors (L) | Alignment Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are defined:
Reserved: Not used, MUST be 0.
Hardware Overruns: Number of receive buffer over-runs since call
was established.
Buffer Overruns: Number of buffer over-runs detected since call
was established.
Time-out Errors: Number of time-outs since call was established.
Alignment Errors: Number of alignment errors since call was
established.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 1. The Length (before hiding) of this AVP is
32.
5. Protocol Operation
This section addresses various operational issues in both the control
connection and data channel of L2TP.
5.1 Migration from L2TPv2 to L2TPv3
This section defines the methods that MUST be followed in order to
provide a smooth transition from the installed base of L2TPv2 to
L2TPv3. The first section describes what is expected of an
L2TPv3-only implementation that does not fall back to L2TPv2 mode to
interoperate with the existing installed base. The second section
describes how an L2TPv2/v3-capable implementation may "autodetect"
whether its peer is L2TPv3-capable, and how to fall back to L2TPv2
mode if so desired.
Townsley, et al. Standards Track [Page 40]
INTERNET DRAFT L2TP July 2001
5.1.1 L2TPv3-Only Implementations
As the recipient of an SCCRQ, a new L2TPv3 implementation MUST accept
an SCCRQ with a Ver field of 2 in the header. The AVPs in the
message MUST be parsed to determine whether the message suggests a
native L2TPv2 implementation or an L2TPv2/v3 implementation
attempting version detection. The presence of the 32-bit Assigned
Control Connection ID AVP indicates that the sender is an
L2TPv3-capable implementation, and an L2TPv3 message SHOULD be sent
in response to the SCCRQ. If the 32-bit Assigned Control Connection
ID AVP is not present, then an L2TPv2 StopCCN that includes the
16-bit Assigned Tunnel ID AVP (as defined in [RFC2661]) MUST be
constructed and sent in response to the SCCRQ. Note that this does
not require additional state on either implementation. Further, the
StopCCN MAY be sent as a single message without waiting for an
acknowledgement or providing retransmission on the message.
An L2TPv3-only implementation SHOULD always send messages with Ver 3
in the control message header, including the SCCRQ. L2TPv2
implementations are expected to drop such messages.
5.1.2 L2TPv2/v3 Implementations
An L2TPv2/v3 implementation is one that can operate in either mode
for the intended application. L2TPv3 is always favored, but
L2TPv2-only implementations will still operate within the
specifications of L2TPv2. Beyond the added benefits of L2TPv3,
fallback to L2TPv2 should be seamless and occur automatically.
In order to provide such fallback, an L2TPv2/v3 implementation MUST
send an SCCRQ that looks enough like an L2TPv2 SCCRQ to be accepted
by L2TPv2 implementations. Thus, the SCCRQ is sent with a Ver field
of 2 in the control message header, along with the other AVPs
expected in an L2TPv2 SCCRQ as defined in [RFC2661]. All required
L2TPv3 AVPs for an SCCRQ (e.g. the 32-bit Assigned Control Connection
ID) MUST be sent as well, with their M bits set to 0.
If the response to the SCCRQ is a properly formatted L2TPv3 message,
then operation can continue as described in this document for an
L2TPv3 implementation. If the response is a properly formatted
L2TPv2 message, then the L2TPv2/v3 implementation MUST fallback to an
L2TPv2 mode of operation.
5.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.1) belong to this delivery mechanism. The upper level
Townsley, et al. Standards Track [Page 41]
INTERNET DRAFT L2TP July 2001
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 ZLB ACK message), receipt of duplicate messages MUST be
acknowledged by the reliable delivery mechanism. This
acknowledgement may either piggybacked on a message in queue or sent
explicitly via a ZLB ACK.
All control messages take up one slot in the control message sequence
number space, except the ZLB acknowledgement. Thus, Ns is not
incremented after a ZLB 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-
ZLB message received plus 1, modulo 65536). While the Nr in a
received ZLB 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 ZLB. As a precaution, 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, it 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
Townsley, et al. Standards Track [Page 42]
INTERNET DRAFT L2TP July 2001
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)
passes without acknowledgement, 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 MUST be no less than 8 seconds per retransmission. If no peer
response is detected after several retransmissions (a recommended
default is 5, but SHOULD be configurable), the control connection and
all associated sessions MUST be cleared.
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 exchange has occurred.
A sliding window mechanism is used for control message transmission.
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 up to N outstanding 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 support a receive window of only 1 (e.g. by
sending out a Receive Window Size AVP with a value of 1), but MUST
accept a window of up to 4 from its peer (i.e. have the ability to
send 4 messages before backing off). A value of 0 for the Receive
Window Size AVP is invalid.
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 MUST NOT withhold acknowledgment of messages as a technique
for flow controlling control messages. An L2TP implementation is
expected to be able to keep up with incoming control messages,
possibly responding to some with errors reflecting an inability to
honor the requested action.
In addition, a peer MUST NOT withhold acknowledgement of messages in
order to maintain state in the L2TP state machine. Conversely, the
L2TP state machine MUST be capable of maintaining state if a ZLB ACK
Townsley, et al. Standards Track [Page 43]
INTERNET DRAFT L2TP July 2001
is received in response to a control message. However, determining
when a state should no longer be maintained (e.g. how long to wait in
wait-reply state for an ICRP from the peer) before destroying a
session or control connection is an issue that is left to each
implementation.
Appendix B contains examples of control message transmission,
acknowledgement, and retransmission.
5.3 LCCE Authentication
L2TP incorporates a simple, optional, CHAP-like [RFC1994] LCCE
authentication system during control connection establishment. If a
LAC or LNS wishes to authenticate the identity of its peer, a
Challenge AVP is included in the SCCRQ or SCCRP message. If a
Challenge AVP is received in an SCCRQ or SCCRP, a Challenge Response
AVP MUST be sent in the following SCCRP or SCCCN, respectively. If
the expected response and response received from a peer does not
match, establishment of the control connection MUST be disallowed.
To participate in LCCE authentication, a single shared secret MUST
exist between the two LCCEs. This is the same shared secret used for
AVP hiding (see Section 4.3). See Section 4.4.3 for details on
construction of the Challenge and Response AVPs.
5.4 Keepalive (Hello)
A keepalive mechanism is employed by L2TP in order to differentiate
control connection outages from extended periods of no control or
data activity on a control connection. This is accomplished by
injecting HELLO control messages (see Section 6.5) after a specified
period of time has elapsed since the last data message or control
message was received on an L2TP session or control connection,
respectively. As for any other control message, if the HELLO message
is not reliably delivered, the control connection is declared down
and is reset. The delivery reset mechanism along with the injection
of HELLO messages ensures that a connectivity failure between the
LCCEs will be detected at both ends of a control connection.
The sending of HELLO messages and the policy for sending them are
left up to the implementation. A peer MUST NOT expect HELLO messages
at any time or interval. As with all messages sent on the control
connection, the receiver will return either a ZLB ACK or an
(unrelated) message piggybacking the necessary acknowledgement
information.
Since a HELLO is a control message, and since control messages are
reliably sent by the lower level delivery mechanism, this keepalive
Townsley, et al. Standards Track [Page 44]
INTERNET DRAFT L2TP July 2001
function operates by causing the reliable delivery of a message. If
a media interruption has occurred, the delivery mechanism will be
unable to deliver the HELLO across and will clean up the control
connection.
Keepalives for the control connection MAY be implemented by sending a
HELLO if a period of time (a recommended default is 60 seconds, but
SHOULD be configurable) has passed without receiving any message
(data or control) from the peer.
An LCCE running Hello timers across multiple control connections
SHOULD employ a jittered timer mechanism.
5.5 Forwarding Session Frames
Once session establishment is complete, L2 frames are received at the
LAC or LNS, encapsulated in L2TP (with appropriate attention to
framing and L2 dependencies as described in documents for the
particular Pseudo Wire Type), and forwarded over the appropriate
session. The sender of a message associated with a particular
session places the Assigned Session ID (specified by its peer) in the
Session ID field of the L2TP data header for every outgoing message.
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 the same 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. Any received data packets that contain
invalid Session IDs or associated cookie values MUST be dropped.
Finally, the LCCE either processes the encapsulated session frame
locally (i.e. as an LNS) or forwards the frame to a circuit (i.e. as
an LAC).
5.7 In-Band Operation of the Control and Data Channels
Whether the control connection and data channel operate in-band or
out-of-band is determined by the Data Channel Capabilities List AVP
and the Data Channel Type List AVP (see Section 4.4).
To support in-band operation of the control connection and data
channel, the high-order bit of the Assigned Session ID AVP MUST be
set to 0. Control messages can thus be distinguished from data
messages, since all control messages are required to have this bit
set to 1. Drawbacks include a reduction in the number of total
Townsley, et al. Standards Track [Page 45]
INTERNET DRAFT L2TP July 2001
sessions supported by an single LCCE to 2**31 sessions, and the
additional operation of checking this bit for all packets received.
If 2**32 sessions are needed, then the control and data channel MUST
operate out-of-band. It is recommended that implementations choose
to operate in out-of-band mode unless specifically needed for NAT,
firewall, or other requirements. See Section 8 for details about
L2TP over specific media.
6. Control Connection Protocol Specification
The following control messages are used to establish, maintain, and
tear down L2TP control connections. All data are sent in network
order (high order octets first). Any "reserved" or "empty" fields
MUST be sent as 0 values to allow for protocol extensibility.
The exchanges in which these messages are involved are outlined in
Section 3.3.
6.1 Start-Control-Connection-Request (SCCRQ)
Start-Control-Connection-Request (SCCRQ) is a control message used to
initiate a control connection between two LCCEs. It is sent by
either the LAC or the LNS to begin the control connection
establishment process.
The following AVPs MUST be present in the SCCRQ:
Message Type AVP
Protocol Version
Host Name
Assigned Control Connection ID
Data Channel Capabilities List
Pseudo Wire Capabilities List
The following AVPs MAY be present in the SCCRQ:
Receive Window Size
Challenge
Tie Breaker
Firmware Revision
Vendor Name
6.2 Start-Control-Connection-Reply (SCCRP)
Start-Control-Connection-Reply (SCCRP) is a control message sent in
reply to a received SCCRQ message. The SCCRP is used to indicate
that the SCCRQ was accepted and establishment of the control
connection should continue.
Townsley, et al. Standards Track [Page 46]
INTERNET DRAFT L2TP July 2001
The following AVPs MUST be present in the SCCRP:
Message Type
Protocol Version
Host Name
Assigned Control Connection ID
Data Channel Capabilities List
Pseudo Wire Capabilities List
The following AVPs MAY be present in the SCCRP:
Firmware Revision
Vendor Name
Receive Window Size
Challenge
Challenge Response
6.3 Start-Control-Connection-Connected (SCCCN)
Start-Control-Connection-Connected (SCCCN) is a control message sent
in reply to an SCCRP. The SCCCN completes the control connection
establishment process.
The following AVP MUST be present in the SCCCN:
Message Type
The following AVP MAY be present in the SCCCN:
Challenge Response
6.4 Stop-Control-Connection-Notification (StopCCN)
Stop-Control-Connection-Notification (StopCCN) is a control message
sent by either LCCE to inform its peer that the control connection is
being shut down and that the control connection should be closed. In
addition, all active sessions are implicitly cleared (without sending
any explicit session control messages). The reason for issuing this
request is indicated in the Result Code AVP. There is no explicit
reply to the message, only the implicit ACK that is received by the
reliable control message delivery layer.
The following AVPs MUST be present in the StopCCN:
Message Type
Result Code
The Assigned Control Connection ID MUST be present in the StopCCN if
Townsley, et al. Standards Track [Page 47]
INTERNET DRAFT L2TP July 2001
it has been sent in a previous message (see Section 4.4.3).
6.5 Hello (HELLO)
The Hello (HELLO) message is an L2TP control message sent by either
peer of a control connection. This control message is used as a
"keepalive" for the control connection. See Section 5.4 for a
description of the keepalive mechanism.
HELLO messages are global to the control connection. The Session ID
in a HELLO message MUST be 0.
The following AVP MUST be present in the HELLO message:
Message Type
6.6 Incoming-Call-Request (ICRQ)
Incoming-Call-Request (ICRQ) is a control message sent by an LCCE to
a peer when an incoming call is detected (although the ICRQ may also
be sent as a result of a local event). It is the first in a three-
message exchange used for establishing a session via an L2TP control
connection.
The ICRQ is used to indicate that a session is to be established
between an LCCE and a peer. The sender of an ICRQ provides the peer
with parameter information for the session. However, the sender
makes no demands about how the the session is terminated at the peer
(i.e. whether the L2 traffic is processed locally, forwarded, etc.).
The following AVPs MUST be present in the ICRQ:
Message Type
Assigned Session ID
Call Serial Number
Data Channel Type List
Pseudo Wire Type
Assigned Cookie
The following AVP MAY be present in the ICRQ:
End Identifier
Physical Channel ID
6.7 Incoming-Call-Reply (ICRP)
Incoming-Call-Reply (ICRP) is a control message sent by an LCCE in
response to an ICRQ. It is the second in the three-message exchange
Townsley, et al. Standards Track [Page 48]
INTERNET DRAFT L2TP July 2001
used for establishing sessions within an L2TP control connection.
The ICRP is used to indicate that the ICRQ was successful and that
the peer should establish (e.g. answer) the incoming call if it has
not already done so. It also allows the sender to indicate specific
parameters about the L2TP session.
The following AVPs MUST be present in the ICRP:
Message Type
Session ID
Assigned Session ID
Assigned Cookie
The following AVP MAY be present in the ICRP:
End Identifier
6.8 Incoming-Call-Connected (ICCN)
Incoming-Call-Connected (ICCN) is a control message sent by the LCCE
who originally sent an ICRQ, upon receiving an ICRP from its peer.
It is the third message in the three-message exchange used for
establishing sessions within an L2TP control connection.
The ICCN is used to indicate that the ICRP was accepted, that the
call has been established, and that the L2TP session should move to
the established state. It also allows the sender to indicate
specific parameters about the established call (parameters that may
not have been available at the time the ICRQ is issued).
The following AVPs MUST be present in the ICCN:
Message Type
Session ID
(Tx) Connect Speed
The following AVPs MAY be present in the ICCN:
Private Group ID
Rx Connect Speed
6.9 Outgoing-Call-Request (OCRQ)
Outgoing-Call-Request (OCRQ) is a control message sent by an LCCE to
an LAC to indicate that an outbound call at the LAC is to be
established based on specific destination information sent in this
message. It is the first in a three-message exchange used for
Townsley, et al. Standards Track [Page 49]
INTERNET DRAFT L2TP July 2001
establishing a session and placing a call on behalf of the initiating
LCCE.
Note that a call may be any L2 connection requiring well-known
destination information to be sent from an LCCE to an LAC. This
could be a dialup connection to the PSTN, an SVC connection, the IP
address of another LCCE, or any other destination dictated by the
sender of this message.
The following AVPs MUST be present in the OCRQ:
Message Type
Assigned Session ID
Call Serial Number
Minimum BPS
Maximum BPS
Data Channel Type List
Pseudo Wire
Assigned Cookie
The following AVPs MAY be present in the OCRQ:
End Identifier
6.10 Outgoing-Call-Reply (OCRP)
Outgoing-Call-Reply (OCRP) is a control message sent by an LAC to an
LCCE in response to an OCRQ. It is the second in a three-message
exchange used for establishing a session within an L2TP control
connection.
OCRP is used to indicate that the LAC has been able to attempt the
outbound call. The message returns any relevant parameters regarding
the call attempt. Data MUST not be forwarded until the OCCN is
received indicating that the call has been placed.
The following AVPs MUST be present in the OCRP:
Message Type
Session ID
Assigned Session ID
Assigned Cookie
The following AVPs MAY be present in the OCRP:
End Identifier
Physical Channel ID
Townsley, et al. Standards Track [Page 50]
INTERNET DRAFT L2TP July 2001
6.11 Outgoing-Call-Connected (OCCN)
Outgoing-Call-Connected (OCCN) is a control message sent by an LAC to
the an LCCE following the OCRP and after the outgoing call has been
completed. It is the final message in a three-message exchange used
for establishing a session within an L2TP control connection.
OCCN is used to indicate that t.sp
7. Control Connection State Machines
The state tables defined in this section govern the exchange of
control messages defined in Section 6. Tables are defined for
incoming call placement and outgoing call placement, as well as for
initiation of the control connection itself. The state tables do not
encode timeout and retransmission behavior, as this is handled in the
underlying reliable control message delivery mechanism (see Section
5.2).
7.1 Malformed Control Messages
Receipt of an invalid or unrecoverable malformed control message
SHOULD be logged appropriately and the control connection cleared to
ensure recovery to a known state. The control connection may then be
restarted by the initiator.
An invalid control message is defined as (1) a message that contains
a Message Type marked as mandatory (see Section 4.4.1) but that is
unknown to the implementation, or (2) a control message that is
received in the wrong state.
Examples of malformed control messages include (1) a message that has
an invalid value in its header, (2) a message that contains an AVP
that is formatted incorrectly or whose value is out of range, and (3)
a message that is missing a required AVP. A control message with a
malformed header MUST be discarded.
If a malformed AVP is received with the M bit set, the session or
control connection MUST be terminated with a proper Result or Error
Code sent. A malformed yet non-mandatory (M bit is not set) AVP
within a control message should be handled like an unrecognized non-
mandatory AVP. That is, the AVP MUST be ignored (with the exception
of logging a local error message), and the message MUST be accepted.
This policy MUST NOT be considered a license to send malformed AVPs,
but rather, a guide towards how to handle an improperly formatted
message if one is received. It is impossible to list all potential
malformations of a given message and give advice for each. That
said, one example of a recoverable, malformed AVP might be if the Rx
Townsley, et al. Standards Track [Page 51]
INTERNET DRAFT L2TP July 2001
Connect Speed AVP, attribute 38, is received with a length of 8
rather than 10, and the BPS given in 2 octets rather than 4. Since
the Rx Connect Speed is non-mandatory, this condition should not be
considered catastrophic. As such, the control message should be
accepted as if the AVP had not been received (with the exception of a
local error message being logged).
In several cases in the following tables, a protocol message is sent,
and then a "clean up" occurs. Note that, regardless of the initiator
of the control connection destruction, the reliable delivery
mechanism must be allowed to run (see Section 5.8) before destroying
the control connection. This permits the control connection
management messages to be reliably delivered to the peer.
Appendix B.1 contains an example of lock-step control connection
establishment.
7.2 Timing Considerations
Due to the real-time nature of L2 circuit signaling, an LCCE should
be implemented using a multi-threaded architecture such that messages
related to multiple calls are not serialized and blocked. The call
and connection state figures do not specify exceptions caused by
timers.
7.3 Control Connection States
The L2TP control connection protocol is not distinguishable between
the two LCCEs, but is distinguishable between the originator and
receiver. The originating peer is the one that first initiates
establishment of the control connection (in a tie breaker situation,
this is the winner of the tie). Since either the LAC or the LNS can
be the originator, a collision can occur. See the Tie Breaker AVP in
Section 4.4.3 for a description of this and its resolution.
State Event Action New State
----- ----- ------ ---------
idle Local open Send SCCRQ wait-ctl-reply
request
idle Receive SCCRQ, Send SCCRP wait-ctl-conn
acceptable
idle Receive SCCRQ, Send StopCCN, idle
not acceptable clean up
idle Receive SCCRP Send StopCCN, idle
clean up
Townsley, et al. Standards Track [Page 52]
INTERNET DRAFT L2TP July 2001
idle Receive SCCCN Clean up idle
wait-ctl-reply Receive SCCRP, Send SCCCN, established
acceptable send control-conn
open event to
waiting sessions
wait-ctl-reply Receive SCCRP, Send StopCCN, idle
not acceptable clean up
wait-ctl-reply Receive SCCRQ, Clean up, idle
lose tie breaker re-queue SCCRQ
for idle state
wait-ctl-reply Receive SCCCN Send StopCCN, idle
clean up
wait-ctl-conn Receive SCCCN, Send control-conn established
acceptable open event to
waiting sessions
wait-ctl-conn Receive SCCCN, Send StopCCN, idle
not acceptable clean up
wait-ctl-conn Receive SCCRP, Send StopCCN, idle
SCCRQ clean up
established Local open Send control-conn established
request open event to
(new call) waiting sessions
established Administrative Send StopCCN, idle
control-conn clean up
close event
established Receive SCCRQ, Send StopCCN, idle
SCCRP, SCCCN clean up
idle Receive StopCCN Clean up idle
wait-ctl-reply,
wait-ctl-conn,
established
The states associated with an LCCE for control connection
establishment are as follows:
idle
Townsley, et al. Standards Track [Page 53]
INTERNET DRAFT L2TP July 2001
Both initiator and recipient start from this state. An initiator
transmits an SCCRQ, while a recipient remains in the idle state
until receiving an SCCRQ.
wait-ctl-reply
The originator checks to see if another connection has been
requested from the same peer, and if so, handles the collision
situation described in Section 5.8.
When an SCCRP is received, the message is examined for a
compatible protocol version, as specified by the Protocol Version
AVP. If the version of the reply is lower than the version sent
in the request, the older (lower) version should be used, provided
that it is supported. If the version in the reply is earlier and
supported, the originator moves to the established state. If the
version is earlier and not supported, a StopCCN MUST be sent to
the peer and the originator cleans up and terminates the control
connection. (Note that this policy is independent of the
versioning specified by the Ver field in the control message
header, which is examined for L2TPv2/v3 interoperability. See
Section 5.1.)
wait-ctl-conn
Awaiting an SCCCN. Upon receipt, the challenge response contained
in the message is checked. The control connection either is
established if authentication succeeds; otherwise, it is torn
down.
established
An established connection may be terminated by either a local
condition or the receipt of a StopCCN. In the event of a local
termination, the originator MUST send a StopCCN and clean up the
control connection. If the originator receives a StopCCN, it MUST
also clean up the control connection.
7.4 Incoming Calls
An ICRQ is generated by an LCCE, typically in response to an incoming
call or a local event. Once the LCCE sends the ICRQ, it waits for a
response from the peer. However, it may choose to postpone
establishment of the call (e.g. answering the call, or bringing up
the circuit) until the peer has indicated with an ICRP that it will
accept the call. The peer may choose not to accept the call if, for
instance, there are insufficient resources to handle an additional
session.
If the peer chooses to accept the call, it responds with an ICRP.
When the local LCCE receives the ICRP, it attempts to establish the
Townsley, et al. Standards Track [Page 54]
INTERNET DRAFT L2TP July 2001
call. A final call connected message, the ICCN, is sent from the
local LCCE to the peer to indicate that the call states for both
LCCEs should enter the established state. If the call is terminated
before the peer can accept it, a CDN is sent by the local LCCE to
indicate this condition.
When a call transitions to a "disconnected" or "down" state, the call
is cleared normally, and the local LCCE sends a CDN. Similarly, if
the peer wishes to clear a call, it sends a CDN and cleans up its
session.
7.4.1 ICRQ Sender States
State Event Action New State
----- ----- ------ ---------
idle Call signal or Initiate local wait-control-conn
ready to receive control-conn
incoming conn. open
idle Receive ICCN, Clean up idle
ICRP, CDN
wait-control- Bearer line drop Clean up idle
conn or local close
request
wait-control- control-conn-open Send ICRQ wait-reply
conn
wait-reply Receive ICRP, Send ICCN established
acceptable
wait-reply Receive ICRP, Send CDN, idle
Not acceptable clean up
wait-reply Receive ICRQ Send CDN, idle
clean up
wait-reply Receive CDN, Clean up idle
ICCN
wait-reply Local close Send CDN, idle
request clean up
established Receive CDN Clean up idle
established Receive ICRQ, Send CDN, idle
ICRP, ICCN clean up
Townsley, et al. Standards Track [Page 55]
INTERNET DRAFT L2TP July 2001
established Local close Send CDN, idle
request clean up
The states associated with the ICRQ sender are as follows:
idle
The LCCE detects an incoming call on one of its interfaces (e.g.
an analog PSTN line rings, or an ATM PVC is provisioned), or a
local event occurs. The LCCE initiates its control connection
establishment state machine and moves to a state waiting for
confirmation of the existence of a control connection.
wait-control-connection
In this state, the session is waiting for either the control
connection to be opened or for verification that the control
connection is already open. Once an indication that the control
connection has been opened is received, session control messages
may be exchanged. The first of these is the ICRQ.
wait-reply
The ICRQ sender receives either (1) a CDN indicating the peer is
not willing to accept the call (general error or don't accept) and
moves back into the idle state, or (2) an ICRP indicating the call
is accepted. In the latter case, the LCCE sends an ICCN and
enters the established state.
established
Data is exchanged over the session. The call may be cleared by
any of the following:
+ An event on the connected interface: The LCCE sends a CDN.
+ Receipt of a CDN: The LCCE cleans up, disconnecting the call.
+ A local reason: The LCCE sends a CDN.
7.4.2 ICRQ Recipient States
State Event Action New State
----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect
acceptable
idle Receive ICRQ, Send CDN, idle
not acceptable clean up
idle Receive ICRP Send CDN idle
clean up
idle Receive ICCN Clean up idle
Townsley, et al. Standards Track [Page 56]
INTERNET DRAFT L2TP July 2001
wait-connect Receive ICCN Prepare for established
acceptable data
wait-connect Receive ICCN Send CDN, idle
not acceptable clean up
wait-connect Receive ICRQ, Send CDN, idle
ICRP clean up
idle, Receive CDN Clean up idle
wait-connect,
established
wait-connect Local close Send CDN, idle
established request clean up
established Receive ICRQ, Send CDN, idle
ICRP, ICCN clean up
The states associated with the ICRQ recipient are as follows:
idle
An ICRQ is received. If the request is not acceptable, a CDN is
sent back to the peer LCCE, and the local LCCE remains in the idle
state. If the ICRQ is acceptable, an ICRP is sent. The session
moves to the wait-connect state.
wait-connect
The local LCCE is waiting for an ICCN from the peer. Upon receipt
of the ICCN, the local LCCE moves to established state.
established
The session is terminated either by sending a CDN or by receiving
a CDN from the peer. Clean up follows on both sides regardless of
the initiator.
7.5 Outgoing Calls
Outgoing calls are initiated by an LCCE and instruct an LAC to place
a call. There are three messages for outgoing calls: OCRQ, OCRP, and
OCCN. The LCCE first sends an OCRQ to an LAC to request an outgoing
call. The LAC MUST respond to the OCRQ with an OCRP once it
determines that the proper facilities exist to place the call and
that the call is administratively authorized. Once the outbound call
is connected, the LAC sends an OCCN to the peer indicating the final
result of the call attempt.
Townsley, et al. Standards Track [Page 57]
INTERNET DRAFT L2TP July 2001
7.5.1 OCRQ Sender States
State Event Action New State
----- ----- ------ ---------
idle Local open Initiate local wait-control-conn
request control-conn-open
idle Receive OCCN, Clean up idle
OCRP
wait-control- control-conn-open Send OCRQ wait-reply
conn
wait-reply Receive OCRP, none wait-connect
acceptable
wait-reply Receive OCRP, Send CDN, idle
not acceptable clean up
wait-reply Receive OCCN, Send CDN, idle
OCRQ clean up
wait-connect Receive OCCN none established
wait-connect Receive OCRQ, Send CDN, idle
OCRP clean up
idle, Receive CDN Clean up idle
wait-reply,
wait-connect,
established
established Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up
wait-reply, Local close Send CDN, idle
wait-connect, request clean up
established
wait-control- Local close Clean up idle
conn request
The states associated with the OCRQ sender are as follows:
idle, wait-control-conn
When an outgoing call request is initiated, a control connection
is created as described above, if not already present. Once the
control connection is established, an OCRQ is sent to the LAC, and
Townsley, et al. Standards Track [Page 58]
INTERNET DRAFT L2TP July 2001
the session moves into the wait-reply state.
wait-reply
If a CDN is received, the session is cleaned up and returns to
idle state. If an OCRP is received, the call is in progress, and
the session moves to the wait-connect state.
wait-connect
If a CDN is received, the session is cleaned up and returns to
idle state. If an OCCN is received, the call has succeeded, and
the session may now exchange data.
established
If a CDN is received, the session is cleaned up and returns to
idle state. Alternatively, if the LCCE chooses to terminate the
session, it sends a CDN to the LAC, cleans up the session, and
moves the session to idle state.
7.5.2 OCRQ Recipient (LAC) States
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Place call
idle Receive OCRQ, Send CDN, idle
not acceptable clean up
idle Receive OCRP Send CDN, idle
clean up
idle Receive OCCN, Clean up idle
CDN
wait-cs-answer Call placement Send OCCN established
successful
wait-cs-answer Call placement Send CDN, idle
failed clean up
wait-cs-answer Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up
established Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up
wait-cs-answer, Receive CDN Clean up idle
established
Townsley, et al. Standards Track [Page 59]
INTERNET DRAFT L2TP July 2001
established Local close Send CDN, idle
request clean up
The states associated with the LAC for outgoing calls are as follows:
idle
If the OCRQ is received in error, respond with a CDN. Otherwise,
place the call, send an OCRP, and move to the wait-cs-answer
state.
wait-cs-answer
If the call is not completed or a timer expires while waiting for
the call to complete, send a CDN with the appropriate error
condition set, and go to idle state. If a circuit-switched
connection is established, send an OCCN indicating success, and go
to established state.
established
If the LAC receives a CDN from the peer, the call MUST be released
via appropriate mechanisms, and the session cleaned up. If the
call is disconnected because the circuit transitions to a
"disconnected" or "down" state, the LAC MUST send a CDN to the
peer and return to idle state.
7.6 Termination of a Control Connection
The termination of a control connection consists of either peer
issuing a StopCCN. The sender of this message SHOULD wait a finite
period of time for the acknowledgment of this message before
releasing the control information associated with the control
connection. The recipient of this message should send an
acknowledgment of the message to the peer, then release the
associated control information.
When to release a control connection is an implementation issue and
is not specified in this document. A particular implementation may
use whatever policy is appropriate for determining when to release a
control connection. Some implementations may leave a control
connection open for a period of time or perhaps indefinitely after
the last session for that control connection is cleared. Others may
choose to disconnect the control connection immediately after the
last call on the control connection disconnects.
8. L2TP Over Specific Media
L2TP is self-describing, operating at a level above the media over
which it is carried. However, some details of its connection to
media are required to permit interoperable implementations. The
Townsley, et al. Standards Track [Page 60]
INTERNET DRAFT L2TP July 2001
following sections describe details needed to permit interoperability
over specific media.
Note that if the control connection and data channel are carried in-
band over the same media, the policy described in Section 5.7 for
distinguishing control and data messages still applies. Whether the
control connection and data channel are carried in-band or out-of-
band is determined by the Data Channel Capabilities AVP and Data
Channel Type AVP (see Section 4.4).
8.1 L2TP Control Connection over UDP/IP
When operating over an IP network, L2TP control messages MUST be
encapsulated as UDP datagrams utilizing 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. UDP checksums MUST be
enabled for control messages.
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 before choosing an
arbitrary source port. Any NAT device which can pass TFTP traffic
should be able to pass L2TP UDP traffic as they employ similar
policies with regard to UDP port selection.
8.2 L2TP Data Channel over IP
L2TP data messages may be sent directly over IP or as UDP datagrams
(see Section 8.3). When operating directly over IP (Data Channel
Type 1), the IP Protocol ID TBA MUST be used. Note that while there
are certain efficiencies gained by running directly over IP, there
are possible side affects as well. For instance, L2TP over IP is
likely not as NAT or firewall friendly as L2TP over UDP.
IP fragmentation may occur as the L2TP packet travels over the IP
substrate. L2TP makes no special efforts to optimize this.
8.3 L2TP Data Channel over UDP
L2TP data messages may be sent as UDP datagrams, operating in-band or
out-of-band with the control connection.
Townsley, et al. Standards Track [Page 61]
INTERNET DRAFT L2TP July 2001
If operating in-band (Data Channel Type 2), all data messages MUST
use the same UDP ports as the control connection (see Section 5.7).
This method has some inefficencies with regard to packet processing.
However, it is the most NAT-friendly method since there is only one
entry in the NAT table to be kept valid, and the control connection
can provide a keepalive to ensure that the NAT entry remains valid.
Also, firewalls can be configured to pass all control and data
traffic with a single entry rather than separate entries for control
and for data.
When operating over UDP out-of-band (Data Channel Type 3), UDP port
TBA MUST be used as the initial port for the data channel. As with
the control channel, either side may then utilize a free port other
than TBA. All data messages MUST send UDP datagrams with a
destination port equal to the source port of the last packet
received. It is recommended that an implementation always use the
source port of TBA.
UDP-encapsulated data packets MAY turn on UDP checksums. It should
be noted that enabling checksums may significantly increase the
packet processing burden for tunneled packets.
9. Security Considerations
L2TP encounters several security issues in its operation. The
general approach of L2TP to these issues is documented here.
9.1 Control Connection Endpoint Security
The LCCEs may optionally perform an authentication procedure of one
another during control connection establishment. This authentication
has the same security attributes as CHAP, and has reasonable
protection against replay and snooping during the control connection
establishment process. This mechanism is not designed to provide any
authentication beyond control connection establishment; it is fairly
simple for a malicious user who can snoop the control connection
stream to inject packets once an authenticated control connection
establishment has been completed successfully.
For authentication to occur, the LCCE pair MUST share a single
secret. Each side uses this same secret when acting as authenticatee
as well as authenticator. Since a single secret is used, the control
connection authentication AVPs include differentiating values in the
CHAP ID fields for each message digest calculation to guard against
replay attacks.
The Assigned Control Connection ID and Assigned Session ID (see
Section 4.4) SHOULD be selected in an unpredictable manner rather
Townsley, et al. Standards Track [Page 62]
INTERNET DRAFT L2TP July 2001
than sequentially or otherwise. Doing so will help deter hijacking
of a session by a malicious user who does not have access to packet
traces between the LCCEs.
The Assigned Cookie value MUST be selected in an unpredictable
manner. However, the cookie MUST not be regarded as packet-level
authentication or security of any kind. It should be used for
nothing more than simple configuration error detection and
identification of misrouted packets. Since the cookie is sent and
advertised in the clear, it is by no means a true packet-level
security measure, such as that offered by IPsec.
9.2 Packet Level Security
Securing L2TP requires that the underlying transport make available
encryption, integrity and authentication services for all L2TP
traffic. This secure transport operates on the entire L2TP packet
and is functionally independent of the data being carried on an L2TP
data session, between the remote system and an LCCE. As such, L2TP
is only concerned with confidentiality, authenticity, and integrity
of the L2TP packets between two LCCEs, not unlike link-layer
encryption being concerned only about protecting the confidentiality
of traffic between its physical endpoints.
9.3 End-to-End Security
Protecting the L2TP packet stream via a secure transport does, in
turn, also protect the data within the tunneled session packets while
transported from one LCCE to the other. Such protection should not
be considered a substitution for end-to-end security between
communicating hosts or applications.
9.4 L2TP and IPsec
When running over IP, IPsec provides packet-level security via ESP
and/or AH. All L2TP control and data packets for a particular
control connection appear as homogeneous UDP/IP data packets to the
IPsec system.
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
Townsley, et al. Standards Track [Page 63]
INTERNET DRAFT L2TP July 2001
as IP address, ports, etc. In the L2TP tunneling model, analogous
filtering is logically performed at the network layer above L2TP.
These network layer access control features may be handled at an LCCE
via vendor-specific authorization features based upon the
authenticated user, 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.
10. IANA Considerations
This document defines a number of "magic" numbers to be maintained by
the IANA. This section explains the criteria to be used by the IANA
to assign additional numbers in each of these lists. The following
subsections describe the assignment policy for the namespaces defined
elsewhere in this document.
10.1 AVP Attributes
As defined in Section 4.1, AVPs contain Vendor ID, Attribute, and
Value fields. For a Vendor ID value of 0, IANA will maintain a
registry of assigned Attributes and, in some cases, Values.
Attributes 0-39 are assigned as defined in Section 4.4. The
remaining values are available for assignment upon Expert Review [RFC
2434].
10.2 Message Type AVP Values
As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0)
have an associated value maintained by IANA. Values 0-16 are defined
in Section 3.1. The remaining values are available for assignment
upon Expert Review [RFC 2434].
10.3 Result Code AVP Values
As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1)
contain three fields. Two of these fields (the Result Code and Error
Code fields) have associated values maintained by IANA.
10.3.1 Result Code Field Values
The Result Code AVP may be included in CDN and StopCCN messages. The
allowable values for the Result Code field of the AVP differ
depending upon the value of the Message Type AVP. For the StopCCN
message, values 0-7 are defined in Section 4.4.2; for the CDN
message, values 0-11 are defined in the same section. The remaining
values of the Result Code field for both messages are available for
assignment upon Expert Review [RFC 2434].
Townsley, et al. Standards Track [Page 64]
INTERNET DRAFT L2TP July 2001
10.3.2 Error Code Field Values
Values 0-9 are defined in Section 4.4.2. The remaining values are
available for assignment upon Expert Review [RFC 2434].
10.4 AVP Header Bits
There are four remaining reserved bits in the AVP header. Additional
bits should only be assigned via a Standards Action [RFC 2434].
11. References
[DSS1] ITU-T Recommendation, "Digital subscriber Signaling System
No. 1 (DSS 1) - ISDN user-network interface layer 3
specification for basic call control", Rec. Q.931(I.451),
May 1998
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network
Security: Private Communications in a Public World",
Prentice Hall, March 1995, ISBN 0-13-061466-1
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
August 1996.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
Townsley, et al. Standards Track [Page 65]
INTERNET DRAFT L2TP July 2001
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138,
April 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
RFC 2637, July 1999.
[RFC2661] Townsley W., et al., "Layer Two Tunneling Layer Two Tunneling
Protocol (L2TP)", RFC 2661, August 1999.
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The
Protocols", Addison-Wesley Publishing Company, Inc., March
1996, ISBN 0-201-63346-9
12. Editors' Addresses
Jed Lau
cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
Email: jedlau@cisco.com
Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
Townsley, et al. Standards Track [Page 66]
INTERNET DRAFT L2TP July 2001
Email: gurdeep@microsoft.com
Bill Palter
RedBack Networks, Inc
1389 Moffett Park Drive
Sunnyvale, CA 94089
Email: palter@zev.net
Allan Rubens
Email: acr@del.com
W. Mark Townsley
cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
Email: mark@townsley.net
Andrew J. Valencia
P.O. Box 2928
Vashon, WA 98070
Email: vandys@zendo.com
Glen Zorn
cisco Systems
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
Email: gwz@cisco.com
Appendix A: Control Slow Start and Congestion Avoidance
Although each side has indicated the maximum size of its receive
window, it is recommended that a slow start and congestion avoidance
method be used to transmit control packets. The methods described
here are based upon the TCP congestion avoidance algorithm as
described in section 21.6 of TCP/IP Illustrated, Volume I, by
W. Richard Stevens [STEVENS].
Slow start and congestion avoidance make use of several variables.
The congestion window (CWND) defines the number of packets a sender
may send before waiting for an acknowledgment. The size of CWND
expands and contracts as described below. Note however, that CWND is
never allowed to exceed the size of the advertised window obtained
Townsley, et al. Standards Track [Page 67]
INTERNET DRAFT L2TP July 2001
from the Receive Window AVP (in the text below, it is assumed any
increase will be limited by the Receive Window Size). The variable
SSTHRESH determines when the sender switches from slow start to
congestion avoidance. Slow start is used while CWND is less than
SSHTRESH.
A sender starts out in the slow start phase. CWND is initialized to
one packet, and SSHTRESH is initialized to the advertised window
(obtained from the Receive Window AVP). The sender then transmits one
packet and waits for its acknowledgement (either explicit or
piggybacked). When the acknowledgement is received, the congestion
window is incremented from one to two. During slow start, CWND is
increased by one packet each time an ACK (explicit ZLB or piggybacked)
is received. Increasing CWND by one on each ACK has the effect of
doubling CWND with each round trip, resulting in an exponential
increase. When the value of CWND reaches SSHTRESH, the slow start
phase ends and the congestion avoidance phase begins.
During congestion avoidance, CWND expands more slowly. Specifically,
it increases by 1/CWND for every new ACK received. That is, CWND is
increased by one packet after CWND new ACKs have been received.
Window expansion during the congestion avoidance phase is effectively
linear, with CWND increasing by one packet each round trip.
When congestion occurs (indicated by the triggering of a
retransmission) one half of the CWND is saved in SSTHRESH, and CWND is
set to one. The sender then reenters the slow start phase.
Appendix B: Control Message Examples
B.1: Lock-step control connection establishment
In this example, an LCCE establishes a control connection, with the
exchange involving each side alternating in sending messages. This
example shows the final acknowledgment explicitly sent within a ZLB
ACK message. An alternative would be to piggyback the acknowledgement
within a message sent as a reply to the ICRQ or OCRQ that will likely
follow from the side that initiated the control connection.
LCCE A LCCE B
------ ------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ZLB
Townsley, et al. Standards Track [Page 68]
INTERNET DRAFT L2TP July 2001
Nr: 2, Ns: 1
B.2: Lost packet with retransmission
An existing control connection has a new session requested by LCCE A.
The ICRP is lost and must be retransmitted by LCCE B. Note that loss
of the ICRP has two impacts: It not only keeps the upper level state
machine from progressing, but also keeps LCCE A from seeing a timely
lower level acknowledgment of its ICRQ.
LCCE A LCCE B
------ ------
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(pause; LCCE A's timer started first, so fires first)
ICRQ ->
Nr: 1, Ns: 2
(Realizing that it has already seen this packet,
LCCE B discards the packet and sends a ZLB)
<- ZLB
Nr: 3, Ns: 2
(LCCE B's retransmit timer fires)
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ZLB
Nr: 4, Ns: 2
Appendix C: Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
Townsley, et al. Standards Track [Page 69]
INTERNET DRAFT L2TP July 2001
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat."
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Townsley, et al. Standards Track [Page 70]
