RFC 3931 - Layer Two Tunneling Protocol - Version 3 (L2TPv3)
(Formats: TXT)
Network Working Group J. Lau, Ed.
Request for Comments: 3931 M. Townsley, Ed.
Category: Standards Track Cisco Systems
I. Goyret, Ed.
Lucent Technologies
March 2005
|
Layer Two Tunneling Protocol - Version 3 (L2TPv3)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes "version 3" of the Layer Two Tunneling
Protocol (L2TPv3). L2TPv3 defines the base control protocol and
encapsulation for tunneling multiple Layer 2 connections between two
IP nodes. Additional documents detail the specifics for each data
link type being emulated.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes from RFC 2661. . . . . . . . . . . . . . . . . . 4
1.2. Specification of Requirements. . . . . . . . . . . . . . 4
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Control Message Types. . . . . . . . . . . . . . . . . . 10
3.2. L2TP Header Formats. . . . . . . . . . . . . . . . . . . 11
3.2.1. L2TP Control Message Header. . . . . . . . . . . 11
3.2.2. L2TP Data Message. . . . . . . . . . . . . . . . 12
3.3. Control Connection Management. . . . . . . . . . . . . . 13
3.3.1. Control Connection Establishment . . . . . . . . 14
3.3.2. Control Connection Teardown. . . . . . . . . . . 14
3.4. Session Management . . . . . . . . . . . . . . . . . . . 15
3.4.1. Session Establishment for an Incoming Call . . . 15
3.4.2. Session Establishment for an Outgoing Call . . . 15
Lau, et al. Standards Track [Page 1]
RFC 3931 L2TPv3 March 2005
3.4.3. Session Teardown . . . . . . . . . . . . . . . . 16
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
4.1. L2TP Over Specific Packet-Switched Networks (PSNs) . . . 16
4.1.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 17
4.1.2. L2TP over UDP. . . . . . . . . . . . . . . . . . 18
4.1.3. L2TP and IPsec . . . . . . . . . . . . . . . . . 20
4.1.4. IP Fragmentation Issues. . . . . . . . . . . . . 21
4.2. Reliable Delivery of Control Messages. . . . . . . . . . 23
4.3. Control Message Authentication . . . . . . . . . . . . . 25
4.4. Keepalive (Hello). . . . . . . . . . . . . . . . . . . . 26
4.5. Forwarding Session Data Frames . . . . . . . . . . . . . 26
4.6. Default L2-Specific Sublayer . . . . . . . . . . . . . . 27
4.6.1. Sequencing Data Packets. . . . . . . . . . . . . 28
4.7. L2TPv2/v3 Interoperability and Migration . . . . . . . . 28
4.7.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 29
4.7.2. L2TPv3 over UDP. . . . . . . . . . . . . . . . . 29
4.7.3. Automatic L2TPv2 Fallback. . . . . . . . . . . . 29
5. Control Message Attribute Value Pairs. . . . . . . . . . . . . 30
5.1. AVP Format . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Mandatory AVPs and Setting the M Bit . . . . . . . . . . 32
5.3. Hiding of AVP Attribute Values . . . . . . . . . . . . . 33
5.4. AVP Summary. . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. General Control Message AVPs . . . . . . . . . . 36
5.4.2. Result and Error Codes . . . . . . . . . . . . . 40
5.4.3. Control Connection Management AVPs . . . . . . . 43
5.4.4. Session Management AVPs. . . . . . . . . . . . . 48
5.4.5. Circuit Status AVPs. . . . . . . . . . . . . . . 57
6. Control Connection Protocol Specification. . . . . . . . . . . 59
6.1. Start-Control-Connection-Request (SCCRQ) . . . . . . . . 60
6.2. Start-Control-Connection-Reply (SCCRP) . . . . . . . . . 60
6.3. Start-Control-Connection-Connected (SCCCN) . . . . . . . 61
6.4. Stop-Control-Connection-Notification (StopCCN) . . . . . 61
6.5. Hello (HELLO). . . . . . . . . . . . . . . . . . . . . . 61
6.6. Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . 62
6.7. Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . 63
6.8. Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . 63
6.9. Outgoing-Call-Request (OCRQ) . . . . . . . . . . . . . . 64
6.10. Outgoing-Call-Reply (OCRP) . . . . . . . . . . . . . . . 65
6.11. Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . 65
6.12. Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . 66
6.13. WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . 66
6.14. Set-Link-Info (SLI). . . . . . . . . . . . . . . . . . . 67
6.15. Explicit-Acknowledgement (ACK) . . . . . . . . . . . . . 67
7. Control Connection State Machines. . . . . . . . . . . . . . . 68
7.1. Malformed AVPs and Control Messages. . . . . . . . . . . 68
7.2. Control Connection States. . . . . . . . . . . . . . . . 69
7.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 71
7.3.1. ICRQ Sender States . . . . . . . . . . . . . . . 72
Lau, et al. Standards Track [Page 2]
RFC 3931 L2TPv3 March 2005
7.3.2. ICRQ Recipient States. . . . . . . . . . . . . . 73
7.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 74
7.4.1. OCRQ Sender States . . . . . . . . . . . . . . . 75
7.4.2. OCRQ Recipient (LAC) States. . . . . . . . . . . 76
7.5. Termination of a Control Connection. . . . . . . . . . . 77
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 78
8.1. Control Connection Endpoint and Message Security . . . . 78
8.2. Data Packet Spoofing . . . . . . . . . . . . . . . . . . 78
9. Internationalization Considerations. . . . . . . . . . . . . . 79
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 80
10.1. Control Message Attribute Value Pairs (AVPs) . . . . . . 80
10.2. Message Type AVP Values. . . . . . . . . . . . . . . . . 81
10.3. Result Code AVP Values . . . . . . . . . . . . . . . . . 81
10.4. AVP Header Bits. . . . . . . . . . . . . . . . . . . . . 82
10.5. L2TP Control Message Header Bits . . . . . . . . . . . . 82
10.6. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 83
10.7. Circuit Status Bits. . . . . . . . . . . . . . . . . . . 83
10.8. Default L2-Specific Sublayer bits. . . . . . . . . . . . 84
10.9. L2-Specific Sublayer Type. . . . . . . . . . . . . . . . 84
10.10 Data Sequencing Level. . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . 85
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 87
Appendix A: Control Slow Start and Congestion Avoidance. . . . . . 89
Appendix B: Control Message Examples . . . . . . . . . . . . . . . 90
Appendix C: Processing Sequence Numbers. . . . . . . . . . . . . . 91
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 94
1. Introduction
The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism
for tunneling Layer 2 (L2) "circuits" across a packet-oriented data
network (e.g., over IP). L2TP, as originally defined in RFC 2661, is
a standard method for tunneling Point-to-Point Protocol (PPP)
[RFC1661] sessions. L2TP has since been adopted for tunneling a
number of other L2 protocols. In order to provide greater
modularity, this document describes the base L2TP protocol,
independent of the L2 payload that is being tunneled.
The base L2TP protocol defined in this document consists of (1) the
control protocol for dynamic creation, maintenance, and teardown of
L2TP sessions, and (2) the L2TP data encapsulation to multiplex and
demultiplex L2 data streams between two L2TP nodes across an IP
network. Additional documents are expected to be published for each
L2 data link emulation type (a.k.a. pseudowire-type) supported by
L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents will
Lau, et al. Standards Track [Page 3]
RFC 3931 L2TPv3 March 2005
contain any pseudowire-type specific details that are outside the
scope of this base specification.
When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as
defined in RFC 2661 will be referred to as "L2TPv2", corresponding to
the value in the Version field of an L2TP header. (Layer 2
Forwarding, L2F, [RFC2341] was defined as "version 1".) At times,
L2TP as defined in this document will be referred to as "L2TPv3".
Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in
general.
1.1. Changes from RFC 2661
Many of the protocol constructs described in this document are
carried over from RFC 2661. Changes include clarifications based on
years of interoperability and deployment experience as well as
modifications to either improve protocol operation or provide a
clearer separation from PPP. The intent of these modifications is to
achieve a healthy balance between code reuse, interoperability
experience, and a directed evolution of L2TP as it is applied to new
tasks.
Notable differences between L2TPv2 and L2TPv3 include the following:
Separation of all PPP-related AVPs, references, etc., including a
portion of the L2TP data header that was specific to the needs of
PPP. The PPP-specific constructs are described in a companion
document.
Transition from a 16-bit Session ID and Tunnel ID to a 32-bit
Session ID and Control Connection ID, respectively.
Extension of the Tunnel Authentication mechanism to cover the
entire control message rather than just a portion of certain
messages.
Details of these changes and a recommendation for transitioning to
L2TPv3 are discussed in Section 4.7.
1.2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Lau, et al. Standards Track [Page 4]
RFC 3931 L2TPv3 March 2005
1.3. Terminology
Attribute Value Pair (AVP)
The variable-length concatenation of a unique Attribute
(represented by an integer), a length field, and a Value
containing the actual value identified by the attribute. Zero or
more AVPs make up the body of control messages, which are used in
the establishment, maintenance, and teardown of control
connections. This basic construct is sometimes referred to as a
Type-Length-Value (TLV) in some specifications. (See also:
Control Connection, Control Message.)
Call (Circuit Up)
The action of transitioning a circuit on an L2TP Access
Concentrator (LAC) to an "up" or "active" state. A call may be
dynamically established through signaling properties (e.g., an
incoming or outgoing call through the Public Switched Telephone
Network (PSTN)) or statically configured (e.g., provisioning a
Virtual Circuit on an interface). A call is defined by its
properties (e.g., type of call, called number, etc.) and its data
traffic. (See also: Circuit, Session, Incoming Call, Outgoing
Call, Outgoing Call Request.)
Circuit
A general term identifying any one of a wide range of L2
connections. A circuit may be virtual in nature (e.g., an ATM
PVC, an IEEE 802 VLAN, or an L2TP session), or it may have direct
correlation to a physical layer (e.g., an RS-232 serial line).
Circuits may be statically configured with a relatively long-lived
uptime, or dynamically established with signaling to govern the
establishment, maintenance, and teardown of the circuit. For the
purposes of this document, a statically configured circuit is
considered to be essentially the same as a very simple, long-
lived, dynamic circuit. (See also: Call, Remote System.)
Client
(See Remote System.)
Control Connection
An L2TP control connection is a reliable control channel that is
used to establish, maintain, and release individual L2TP sessions
as well as the control connection itself. (See also: Control
Message, Data Channel.)
Lau, et al. Standards Track [Page 5]
RFC 3931 L2TPv3 March 2005
Control Message
An L2TP message used by the control connection. (See also:
Control Connection.)
Data Message
Message used by the data channel. (a.k.a. Data Packet, See also:
Data Channel.)
Data Channel
The channel for L2TP-encapsulated data traffic that passes between
two LCCEs over a Packet-Switched Network (i.e., IP). (See also:
Control Connection, Data Message.)
Incoming Call
The action of receiving a call (circuit up event) on an LAC. The
call may have been placed by a remote system (e.g., a phone call
over a PSTN), or it may have been triggered by a local event
(e.g., interesting traffic routed to a virtual interface). An
incoming call that needs to be tunneled (as determined by the LAC)
results in the generation of an L2TP ICRQ message. (See also:
Call, Outgoing Call, Outgoing Call Request.)
L2TP Access Concentrator (LAC)
If an L2TP Control Connection Endpoint (LCCE) is being used to
cross-connect an L2TP session directly to a data link, we refer to
it as an L2TP Access Concentrator (LAC). An LCCE may act as both
an L2TP Network Server (LNS) for some sessions and an LAC for
others, so these terms must only be used within the context of a
given set of sessions unless the LCCE is in fact single purpose
for a given topology. (See also: LCCE, LNS.)
L2TP Control Connection Endpoint (LCCE)
An L2TP node that exists at either end of an L2TP control
connection. May also be referred to as an LAC or LNS, depending
on whether tunneled frames are processed at the data link (LAC) or
network layer (LNS). (See also: LAC, LNS.)
L2TP Network Server (LNS)
If a given L2TP session is terminated at the L2TP node and the
encapsulated network layer (L3) packet processed on a virtual
interface, we refer to this L2TP node as an L2TP Network Server
Lau, et al. Standards Track [Page 6]
RFC 3931 L2TPv3 March 2005
(LNS). A given LCCE may act as both an LNS for some sessions and
an LAC for others, so these terms must only be used within the
context of a given set of sessions unless the LCCE is in fact
single purpose for a given topology. (See also: LCCE, LAC.)
Outgoing Call
The action of placing a call by an LAC, typically in response to
policy directed by the peer in an Outgoing Call Request. (See
also: Call, Incoming Call, Outgoing Call Request.)
Outgoing Call Request
A request sent to an LAC to place an outgoing call. The request
contains specific information not known a priori by the LAC (e.g.,
a number to dial). (See also: Call, Incoming Call, Outgoing
Call.)
Packet-Switched Network (PSN)
A network that uses packet switching technology for data delivery.
For L2TPv3, this layer is principally IP. Other examples include
MPLS, Frame Relay, and ATM.
Peer
When used in context with L2TP, Peer refers to the far end of an
L2TP control connection (i.e., the remote LCCE). An LAC's peer
may be either an LNS or another LAC. Similarly, an LNS's peer may
be either an LAC or another LNS. (See also: LAC, LCCE, LNS.)
Pseudowire (PW)
An emulated circuit as it traverses a PSN. There is one
Pseudowire per L2TP Session. (See also: Packet-Switched Network,
Session.)
Pseudowire Type
The payload type being carried within an L2TP session. Examples
include PPP, Ethernet, and Frame Relay. (See also: Session.)
Remote System
An end system or router connected by a circuit to an LAC.
Lau, et al. Standards Track [Page 7]
RFC 3931 L2TPv3 March 2005
Session
An L2TP session is the entity that is created between two LCCEs in
order to exchange parameters for and maintain an emulated L2
connection. Multiple sessions may be associated with a single
Control Connection.
Zero-Length Body (ZLB) Message
A control message with only an L2TP header. ZLB messages are used
only to acknowledge messages on the L2TP reliable control
connection. (See also: Control Message.)
2. Topology
L2TP operates between two L2TP Control Connection Endpoints (LCCEs),
tunneling traffic across a packet network. There are three
predominant tunneling models in which L2TP operates: LAC-LNS (or vice
versa), LAC-LAC, and LNS-LNS. These models are diagrammed below.
(Dotted lines designate network connections. Solid lines designate
circuit connections.)
Figure 2.0: L2TP Reference Models
(a) LAC-LNS Reference Model: On one side, the LAC receives traffic
from an L2 circuit, which it forwards via L2TP across an IP or other
packet-based network. On the other side, an LNS logically terminates
the L2 circuit locally and routes network traffic to the home
network. The action of session establishment is driven by the LAC
(as an incoming call) or the LNS (as an outgoing call).
+-----+ L2 +-----+ +-----+
| |------| LAC |.........[ IP ].........| LNS |...[home network]
+-----+ +-----+ +-----+
remote
system
|<-- emulated service -->|
|<----------- L2 service ------------>|
(b) LAC-LAC Reference Model: In this model, both LCCEs are LACs.
Each LAC forwards circuit traffic from the remote system to the peer
LAC using L2TP, and vice versa. In its simplest form, an LAC acts as
a simple cross-connect between a circuit to a remote system and an
L2TP session. This model typically involves symmetric establishment;
that is, either side of the connection may initiate a session at any
time (or simultaneously, in which a tie breaking mechanism is
utilized).
Lau, et al. Standards Track [Page 8]
RFC 3931 L2TPv3 March 2005
+-----+ L2 +-----+ +-----+ L2 +-----+
| |------| LAC |........[ IP ]........| LAC |------| |
+-----+ +-----+ +-----+ +-----+
remote remote
system system
|<- emulated service ->|
|<----------------- L2 service ----------------->|
(c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A
user-level, traffic-generated, or signaled event typically drives
session establishment from one side of the tunnel. For example, a
tunnel generated from a PC by a user, or automatically by customer
premises equipment.
+-----+ +-----+
[home network]...| LNS |........[ IP ]........| LNS |...[home network]
+-----+ +-----+
|<- emulated service ->|
|<---- L2 service ---->|
Note: In L2TPv2, user-driven tunneling of this type is often referred
to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as
part of a software package on a host is sometimes referred to as an
"LAC Client" [RFC2661].
3. Protocol Overview
L2TP is comprised of two types of messages, control messages and data
messages (sometimes referred to as "control packets" and "data
packets", respectively). Control messages are used in the
establishment, maintenance, and clearing of control connections and
sessions. These messages utilize a reliable control channel within
L2TP to guarantee delivery (see Section 4.2 for details). Data
messages are used to encapsulate the L2 traffic being carried over
the L2TP session. Unlike control messages, data messages are not
retransmitted when packet loss occurs.
The L2TPv3 control message format defined in this document borrows
largely from L2TPv2. These control messages are used in conjunction
with the associated protocol state machines that govern the dynamic
setup, maintenance, and teardown for L2TP sessions. The data message
format for tunneling data packets may be utilized with or without the
L2TP control channel, either via manual configuration or via other
signaling methods to pre-configure or distribute L2TP session
information. Utilization of the L2TP data message format with other
signaling methods is outside the scope of this document.
Lau, et al. Standards Track [Page 9]
RFC 3931 L2TPv3 March 2005
Figure 3.0: L2TPv3 Structure
+-------------------+ +-----------------------+
| Tunneled Frame | | L2TP Control Message |
+-------------------+ +-----------------------+
| L2TP Data Header | | L2TP Control Header |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+-------------------+----+-----------------------+
| Packet-Switched Network (IP, FR, MPLS, etc.) |
+------------------------------------------------+
Figure 3.0 depicts the relationship of control messages and data
messages over the L2TP control and data channels, respectively. Data
messages are passed over an unreliable data channel, encapsulated by
an L2TP header, and sent over a Packet-Switched Network (PSN) such as
IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over
a reliable L2TP control channel, which operates over the same PSN.
The necessary setup for tunneling a session with L2TP consists of two
steps: (1) Establishing the control connection, and (2) establishing
a session as triggered by an incoming call or outgoing call. An L2TP
session MUST be established before L2TP can begin to forward session
frames. Multiple sessions may be bound to a single control
connection, and multiple control connections may exist between the
same two LCCEs.
3.1. Control Message Types
The Message Type AVP (see Section 5.4.1) defines the specific type of
control message being sent.
This document defines the following control message types (see
Sections 6.1 through 6.15 for details on the construction and use of
each message):
Control Connection Management
0 (reserved)
1 (SCCRQ) Start-Control-Connection-Request
2 (SCCRP) Start-Control-Connection-Reply
3 (SCCCN) Start-Control-Connection-Connected
4 (StopCCN) Stop-Control-Connection-Notification
5 (reserved)
6 (HELLO) Hello
20 (ACK) Explicit Acknowledgement
Lau, et al. Standards Track [Page 10]
RFC 3931 L2TPv3 March 2005
Call Management
7 (OCRQ) Outgoing-Call-Request
8 (OCRP) Outgoing-Call-Reply
9 (OCCN) Outgoing-Call-Connected
10 (ICRQ) Incoming-Call-Request
11 (ICRP) Incoming-Call-Reply
12 (ICCN) Incoming-Call-Connected
13 (reserved)
14 (CDN) Call-Disconnect-Notify
Error Reporting
15 (WEN) WAN-Error-Notify
Link Status Change Reporting
16 (SLI) Set-Link-Info
3.2. L2TP Header Formats
This section defines header formats for L2TP control messages and
L2TP data messages. All values are placed into their respective
fields and sent in network order (high-order octets first).
3.2.1. L2TP Control Message Header
The L2TP control message header provides information for the reliable
transport of messages that govern the establishment, maintenance, and
teardown of L2TP sessions. By default, control messages are sent
over the underlying media in-band with L2TP data messages.
The L2TP control message header is formatted as follows:
Figure 3.2.1: L2TP Control Message Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 1, indicating that this is a control
message.
Lau, et al. Standards Track [Page 11]
RFC 3931 L2TPv3 March 2005
The L and S bits MUST be set to 1, indicating that the Length field
and sequence numbers are present.
The x bits are reserved for future extensions. All reserved bits
MUST be set to 0 on outgoing messages and ignored on incoming
messages.
The Ver field indicates the version of the L2TP control message
header described in this document. On sending, this field MUST be
set to 3 for all messages (unless operating in an environment that
includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section
4.1 for details).
The Length field indicates the total length of the message in octets,
always calculated from the start of the control message header itself
(beginning with the T bit).
The Control Connection ID field contains the identifier for the
control connection. L2TP control connections are named by
identifiers that have local significance only. That is, the same
control connection will be given unique Control Connection IDs by
each LCCE from within each endpoint's own Control Connection ID
number space. As such, the Control Connection ID in each message is
that of the intended recipient, not the sender. Non-zero Control
Connection IDs are selected and exchanged as Assigned Control
Connection ID AVPs during the creation of a control connection.
Ns indicates the sequence number for this control message, beginning
at zero and incrementing by one (modulo 2**16) for each message sent.
See Section 4.2 for more information on using this field.
Nr indicates the sequence number expected in the next control message
to be received. Thus, Nr is set to the Ns of the last in-order
message received plus one (modulo 2**16). See Section 4.2 for more
information on using this field.
3.2.2. L2TP Data Message
In general, an L2TP data message consists of a (1) Session Header,
(2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as
depicted below.
Lau, et al. Standards Track [Page 12]
RFC 3931 L2TPv3 March 2005
Figure 3.2.2: L2TP Data Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Session Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2TP Session Header is specific to the encapsulating PSN over
which the L2TP traffic is delivered. The Session Header MUST provide
(1) a method of distinguishing traffic among multiple L2TP data
sessions and (2) a method of distinguishing data messages from
control messages.
Each type of encapsulating PSN MUST define its own session header,
clearly identifying the format of the header and parameters necessary
to setup the session. Section 4.1 defines two session headers, one
for transport over UDP and one for transport over IP.
The L2-Specific Sublayer is an intermediary layer between the L2TP
session header and the start of the tunneled frame. It contains
control fields that are used to facilitate the tunneling of each
frame (e.g., sequence numbers or flags). The Default L2-Specific
Sublayer for L2TPv3 is defined in Section 4.6.
The Data Message Header is followed by the Tunnel Payload, including
any necessary L2 framing as defined in the payload-specific companion
documents.
3.3. Control Connection Management
The L2TP control connection handles dynamic establishment, teardown,
and maintenance of the L2TP sessions and of the control connection
itself. The reliable delivery of control messages is described in
Section 4.2.
This section describes typical control connection establishment and
teardown exchanges. It is important to note that, in the diagrams
that follow, the reliable control message delivery mechanism exists
independently of the L2TP state machine. For instance, Explicit
Acknowledgement (ACK) messages may be sent after any of the control
messages indicated in the exchanges below if an acknowledgment is not
piggybacked on a later control message.
Lau, et al. Standards Track [Page 13]
RFC 3931 L2TPv3 March 2005
LCCEs are identified during control connection establishment either
by the Host Name AVP, the Router ID AVP, or a combination of the two
(see Section 5.4.3). The identity of a peer LCCE is central to
selecting proper configuration parameters (i.e., Hello interval,
window size, etc.) for a control connection, as well as for
determining how to set up associated sessions within the control
connection, password lookup for control connection authentication,
control connection level tie breaking, etc.
3.3.1. Control Connection Establishment
Establishment of the control connection involves an exchange of AVPs
that identifies the peer and its capabilities.
A three-message exchange is used to establish the control connection.
The following is a typical message exchange:
LCCE A LCCE B
------ ------
SCCRQ ->
<- SCCRP
SCCCN ->
3.3.2. Control Connection Teardown
Control connection teardown may be initiated by either LCCE and is
accomplished by sending a single StopCCN control message. As part of
the reliable control message delivery mechanism, the recipient of a
StopCCN MUST send an ACK message to acknowledge receipt of the
message and maintain enough control connection state to properly
accept StopCCN retransmissions over at least a full retransmission
cycle (in case the ACK message is lost). The recommended time for a
full retransmission cycle is at least 31 seconds (see Section 4.2).
The following is an example of a typical control message exchange:
LCCE A LCCE B
------ ------
StopCCN ->
(Clean up)
(Wait)
(Clean up)
An implementation may shut down an entire control connection and all
sessions associated with the control connection by sending the
StopCCN. Thus, it is not necessary to clear each session
individually when tearing down the whole control connection.
Lau, et al. Standards Track [Page 14]
RFC 3931 L2TPv3 March 2005
3.4. Session Management
After successful control connection establishment, individual
sessions may be created. Each session corresponds to a single data
stream between the two LCCEs. This section describes the typical
call establishment and teardown exchanges.
3.4.1. Session Establishment for an Incoming Call
A three-message exchange is used to establish the session. The
following is a typical sequence of events:
LCCE A LCCE B
------ ------
(Call
Detected)
ICRQ ->
<- ICRP
(Call
Accepted)
ICCN ->
3.4.2. Session Establishment for an Outgoing Call
A three-message exchange is used to set up the session. The
following is a typical sequence of events:
LCCE A LCCE B
------ ------
<- OCRQ
OCRP ->
(Perform
Call
Operation)
OCCN ->
(Call Operation
Completed
Successfully)
Lau, et al. Standards Track [Page 15]
RFC 3931 L2TPv3 March 2005
3.4.3. Session Teardown
Session teardown may be initiated by either the LAC or LNS and is
accomplished by sending a CDN control message. After the last
session is cleared, the control connection MAY be torn down as well
(and typically is). The following is an example of a typical control
message exchange:
LCCE A LCCE B
------ ------
CDN ->
(Clean up)
(Clean up)
4. Protocol Operation
4.1. L2TP Over Specific Packet-Switched Networks (PSNs)
L2TP may operate over a variety of PSNs. There are two modes
described for operation over IP, L2TP directly over IP (see Section
4.1.1) and L2TP over UDP (see Section 4.1.2). L2TPv3 implementations
MUST support L2TP over IP and SHOULD support L2TP over UDP for better
NAT and firewall traversal, and for easier migration from L2TPv2.
L2TP over other PSNs may be defined, but the specifics are outside
the scope of this document. Examples of L2TPv2 over other PSNs
include [RFC3070] and [RFC3355].
The following field definitions are defined for use in all L2TP
Session Header encapsulations.
Session ID
A 32-bit field containing a non-zero identifier for a session.
L2TP sessions are named by identifiers that have local
significance only. That is, the same logical session will be
given different Session IDs by each end of the control connection
for the life of the session. When the L2TP control connection is
used for session establishment, Session IDs are selected and
exchanged as Local Session ID AVPs during the creation of a
session. The Session ID alone provides the necessary context for
all further packet processing, including the presence, size, and
value of the Cookie, the type of L2-Specific Sublayer, and the
type of payload being tunneled.
Lau, et al. Standards Track [Page 16]
RFC 3931 L2TPv3 March 2005
Cookie
The optional Cookie field contains a variable-length value
(maximum 64 bits) used to check the association of a received data
message with the session identified by the Session ID. The Cookie
MUST be set to the configured or signaled random value for this
session. The Cookie provides an additional level of guarantee
that a data message has been directed to the proper session by the
Session ID. A well-chosen Cookie may prevent inadvertent
misdirection of stray packets with recently reused Session IDs,
Session IDs subject to packet corruption, etc. The Cookie may
also provide protection against some specific malicious packet
insertion attacks, as described in Section 8.2.
When the L2TP control connection is used for session
establishment, random Cookie values are selected and exchanged as
Assigned Cookie AVPs during session creation.
4.1.1. L2TPv3 over IP
L2TPv3 over IP (both versions) utilizes the IANA-assigned IP protocol
ID 115.
4.1.1.1. L2TPv3 Session Header Over IP
Unlike L2TP over UDP, the L2TPv3 session header over IP is free of
any restrictions imposed by coexistence with L2TPv2 and L2F. As
such, the header format has been designed to optimize packet
processing. The following session header format is utilized when
operating L2TPv3 over IP:
Figure 4.1.1.1: L2TPv3 Session Header Over IP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session ID and Cookie fields are as defined in Section 4.1. The
Session ID of zero is reserved for use by L2TP control messages (see
Section 4.1.1.2).
Lau, et al. Standards Track [Page 17]
RFC 3931 L2TPv3 March 2005
4.1.1.2. L2TP Control and Data Traffic over IP
Unlike L2TP over UDP, which uses the T bit to distinguish between
L2TP control and data packets, L2TP over IP uses the reserved Session
ID of zero (0) when sending control messages. It is presumed that
checking for the zero Session ID is more efficient -- both in header
size for data packets and in processing speed for distinguishing
between control and data messages -- than checking a single bit.
The entire control message header over IP, including the zero session
ID, appears as follows:
Figure 4.1.1.2: L2TPv3 Control Message Header Over IP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (32 bits of zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Named fields are as defined in Section 3.2.1. Note that the Length
field is still calculated from the beginning of the control message
header, beginning with the T bit. It does NOT include the "(32 bits
of zeros)" depicted above.
When operating directly over IP, L2TP packets lose the ability to
take advantage of the UDP checksum as a simple packet integrity
check, which is of particular concern for L2TP control messages.
Control Message Authentication (see Section 4.3), even with an empty
password field, provides for a sufficient packet integrity check and
SHOULD always be enabled.
4.1.2. L2TP over UDP
L2TPv3 over UDP must consider other L2 tunneling protocols that may
be operating in the same environment, including L2TPv2 [RFC2661] and
L2F [RFC2341].
While there are efficiencies gained by running L2TP directly over IP,
there are possible side effects as well. For instance, L2TP over IP
is not as NAT-friendly as L2TP over UDP.
Lau, et al. Standards Track [Page 18]
RFC 3931 L2TPv3 March 2005
4.1.2.1. L2TP Session Header Over UDP
The following session header format is utilized when operating L2TPv3
over UDP:
Figure 4.1.2.1: L2TPv3 Session Header over UDP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 0, indicating that this is a data message.
The x bits and Reserved field are reserved for future extensions.
All reserved values MUST be set to 0 on outgoing messages and ignored
on incoming messages.
The Ver field MUST be set to 3, indicating an L2TPv3 message.
Note that the initial bits 1, 4, 6, and 7 have meaning in L2TPv2
[RFC2661], and are deprecated and marked as reserved in L2TPv3.
Thus, for UDP mode on a system that supports both versions of L2TP,
it is important that the Ver field be inspected first to determine
the Version of the header before acting upon any of these bits.
The Session ID and Cookie fields are as defined in Section 4.1.
4.1.2.2. UDP Port Selection
The method for UDP Port Selection defined in this section is
identical to that defined for L2TPv2 [RFC2661].
When negotiating a control connection over UDP, control messages MUST
be sent as UDP datagrams using the registered UDP port 1701
[RFC1700]. The initiator of an L2TP control connection picks an
available source UDP port (which may or may not be 1701) and sends to
the desired destination address at port 1701. The recipient picks a
free port on its own system (which may or may not be 1701) and sends
its reply to the initiator's UDP port and address, setting its own
source port to the free port it found.
Lau, et al. Standards Track [Page 19]
RFC 3931 L2TPv3 March 2005
Any subsequent traffic associated with this control connection
(either control traffic or data traffic from a session established
through this control connection) must use these same UDP ports.
It has been suggested that having the recipient choose an arbitrary
source port (as opposed to using the destination port in the packet
initiating the control connection, i.e., 1701) may make it more
difficult for L2TP to traverse some NAT devices. Implementations
should consider the potential implication of this capability before
choosing an arbitrary source port. A NAT device that can pass TFTP
traffic with variant UDP ports should be able to pass L2TP UDP
traffic since both protocols employ similar policies with regard to
UDP port selection.
4.1.2.3. UDP Checksum
The tunneled frames that L2TP carry often have their own checksums or
integrity checks, rendering the UDP checksum redundant for much of
the L2TP data message contents. Thus, UDP checksums MAY be disabled
in order to reduce the associated packet processing burden at the
L2TP endpoints.
The L2TP header itself does not have its own checksum or integrity
check. However, use of the L2TP Session ID and Cookie pair guards
against accepting an L2TP data message if corruption of the Session
ID or associated Cookie has occurred. When the L2-Specific Sublayer
is present in the L2TP header, there is no built-in integrity check
for the information contained therein if UDP checksums or some other
integrity check is not employed. IPsec (see Section 4.1.3) may be
used for strong integrity protection of the entire contents of L2TP
data messages.
UDP checksums MUST be enabled for L2TP control messages.
4.1.3. L2TP and IPsec
The L2TP data channel does not provide cryptographic security of any
kind. If the L2TP data channel operates over a public or untrusted
IP network where privacy of the L2TP data is of concern or
sophisticated attacks against L2TP are expected to occur, IPsec
[RFC2401] MUST be made available to secure the L2TP traffic.
Either L2TP over UDP or L2TP over IP may be secured with IPsec.
[RFC3193] defines the recommended method for securing L2TPv2. L2TPv3
possesses identical characteristics to IPsec as L2TPv2 when running
over UDP and implementations MUST follow the same recommendation.
When operating over IP directly, [RFC3193] still applies, though
references to UDP source and destination ports (in particular, those
Lau, et al. Standards Track [Page 20]
RFC 3931 L2TPv3 March 2005
in Section 4, "IPsec Filtering details when protecting L2TP") may be
ignored. Instead, the selectors used to identify L2TPv3 traffic are
simply the source and destination IP addresses for the tunnel
endpoints together with the L2TPv3 IP protocol type, 115.
In addition to IP transport security, IPsec defines a mode of
operation that allows tunneling of IP packets. The packet-level
encryption and authentication provided by IPsec tunnel mode and that
provided by L2TP secured with IPsec provide an equivalent level of
security for these requirements.
IPsec also defines access control features that are required of a
compliant IPsec implementation. These features allow filtering of
packets based upon network and transport layer characteristics such
as IP address, ports, etc. In the L2TP tunneling model, analogous
filtering may be performed at the network layer above L2TP. These
network layer access control features may be handled at an LCCE via
vendor-specific authorization features, or at the network layer
itself by using IPsec transport mode end-to-end between the
communicating hosts. The requirements for access control mechanisms
are not a part of the L2TP specification, and as such, are outside
the scope of this document.
Protecting the L2TP packet stream with IPsec does, in turn, also
protect the data within the tunneled session packets while
transported from one LCCE to the other. Such protection must not be
considered a substitution for end-to-end security between
communicating hosts or applications.
4.1.4. IP Fragmentation Issues
Fragmentation and reassembly in network equipment generally require
significantly greater resources than sending or receiving a packet as
a single unit. As such, fragmentation and reassembly should be
avoided whenever possible. Ideal solutions for avoiding
fragmentation include proper configuration and management of MTU
sizes among the Remote System, the LCCE, and the IP network, as well
as adaptive measures that operate with the originating host (e.g.,
[RFC1191], [RFC1981]) to reduce the packet sizes at the source.
An LCCE MAY fragment a packet before encapsulating it in L2TP. For
example, if an IPv4 packet arrives at an LCCE from a Remote System
that, after encapsulation with its associated framing, L2TP, and IP,
does not fit in the available path MTU towards its LCCE peer, the
local LCCE may perform IPv4 fragmentation on the packet before tunnel
encapsulation. This creates two (or more) L2TP packets, each
Lau, et al. Standards Track [Page 21]
RFC 3931 L2TPv3 March 2005
carrying an IPv4 fragment with its associated framing. This
ultimately has the effect of placing the burden of fragmentation on
the LCCE, while reassembly occurs on the IPv4 destination host.
If an IPv6 packet arrives at an LCCE from a Remote System that, after
encapsulation with associated framing, L2TP and IP, does not fit in
the available path MTU towards its L2TP peer, the Generic Packet
Tunneling specification [RFC2473], Section 7.1 SHOULD be followed.
In this case, the LCCE should either send an ICMP Packet Too Big
message to the data source, or fragment the resultant L2TP/IP packet
(for reassembly by the L2TP peer).
If the amount of traffic requiring fragmentation and reassembly is
rather light, or there are sufficiently optimized mechanisms at the
tunnel endpoints, fragmentation of the L2TP/IP packet may be
sufficient for accommodating mismatched MTUs that cannot be managed
by more efficient means. This method effectively emulates a larger
MTU between tunnel endpoints and should work for any type of L2-
encapsulated packet. Note that IPv6 does not support "in-flight"
fragmentation of data packets. Thus, unlike IPv4, the MTU of the
path towards an L2TP peer must be known in advance (or the last
resort IPv6 minimum MTU of 1280 bytes utilized) so that IPv6
fragmentation may occur at the LCCE.
In summary, attempting to control the source MTU by communicating
with the originating host, forcing that an MTU be sufficiently large
on the path between LCCE peers to tunnel a frame from any other
interface without fragmentation, fragmenting IP packets before
encapsulation with L2TP/IP, or fragmenting the resultant L2TP/IP
packet between the tunnel endpoints, are all valid methods for
managing MTU mismatches. Some are clearly better than others
depending on the given deployment. For example, a passive monitoring
application using L2TP would certainly not wish to have ICMP messages
sent to a traffic source. Further, if the links connecting a set of
LCCEs have a very large MTU (e.g., SDH/SONET) and it is known that
the MTU of all links being tunneled by L2TP have smaller MTUs (e.g.,
1500 bytes), then any IP fragmentation and reassembly enabled on the
participating LCCEs would never be utilized. An implementation MUST
implement at least one of the methods described in this section for
managing mismatched MTUs, based on careful consideration of how the
final product will be deployed.
L2TP-specific fragmentation and reassembly methods, which may or may
not depend on the characteristics of the type of link being tunneled
(e.g., judicious packing of ATM cells), may be defined as well, but
these methods are outside the scope of this document.
Lau, et al. Standards Track [Page 22]
RFC 3931 L2TPv3 March 2005
4.2. Reliable Delivery of Control Messages
L2TP provides a lower level reliable delivery service for all control
messages. The Nr and Ns fields of the control message header (see
Section 3.2.1) belong to this delivery mechanism. The upper level
functions of L2TP are not concerned with retransmission or ordering
of control messages. The reliable control messaging mechanism is a
sliding window mechanism that provides control message retransmission
and congestion control. Each peer maintains separate sequence number
state for each control connection.
The message sequence number, Ns, begins at 0. Each subsequent
message is sent with the next increment of the sequence number. The
sequence number is thus a free-running counter represented modulo
65536. The sequence number in the header of a received message is
considered less than or equal to the last received number if its
value lies in the range of the last received number and the preceding
32767 values, inclusive. For example, if the last received sequence
number was 15, then messages with sequence numbers 0 through 15, as
well as 32784 through 65535, would be considered less than or equal.
Such a message would be considered a duplicate of a message already
received and ignored from processing. However, in order to ensure
that all messages are acknowledged properly (particularly in the case
of a lost ACK message), receipt of duplicate messages MUST be
acknowledged by the reliable delivery mechanism. This acknowledgment
may either piggybacked on a message in queue or sent explicitly via
an ACK message.
All control messages take up one slot in the control message sequence
number space, except the ACK message. Thus, Ns is not incremented
after an ACK message is sent.
The last received message number, Nr, is used to acknowledge messages
received by an L2TP peer. It contains the sequence number of the
message the peer expects to receive next (e.g., the last Ns of a
non-ACK message received plus 1, modulo 65536). While the Nr in a
received ACK message is used to flush messages from the local
retransmit queue (see below), the Nr of the next message sent is not
updated by the Ns of the ACK message. Nr SHOULD be sanity-checked
before flushing the retransmit queue. For instance, if the Nr
received in a control message is greater than the last Ns sent plus 1
modulo 65536, the control message is clearly invalid.
The reliable delivery mechanism at a receiving peer is responsible
for making sure that control messages are delivered in order and
without duplication to the upper level. Messages arriving out-of-
order may be queued for in-order delivery when the missing messages
Lau, et al. Standards Track [Page 23]
RFC 3931 L2TPv3 March 2005
are received. Alternatively, they may be discarded, thus requiring a
retransmission by the peer. When dropping out-of-order control
packets, Nr MAY be updated before the packet is discarded.
Each control connection maintains a queue of control messages to be
transmitted to its peer. The message at the front of the queue is
sent with a given Ns value and is held until a control message
arrives from the peer in which the Nr field indicates receipt of this
message. After a period of time (a recommended default is 1 second
but SHOULD be configurable) passes without acknowledgment, the
message is retransmitted. The retransmitted message contains the
same Ns value, but the Nr value MUST be updated with the sequence
number of the next expected message.
Each subsequent retransmission of a message MUST employ an
exponential backoff interval. Thus, if the first retransmission
occurred after 1 second, the next retransmission should occur after 2
seconds has elapsed, then 4 seconds, etc. An implementation MAY
place a cap upon the maximum interval between retransmissions. This
cap SHOULD be no less than 8 seconds per retransmission. If no peer
response is detected after several retransmissions (a recommended
default is 10, but MUST be configurable), the control connection and
all associated sessions MUST be cleared. As it is the first message
to establish a control connection, the SCCRQ MAY employ a different
retransmission maximum than other control messages in order to help
facilitate failover to alternate LCCEs in a timely fashion.
When a control connection is being shut down for reasons other than
loss of connectivity, the state and reliable delivery mechanisms MUST
be maintained and operated for the full retransmission interval after
the final message StopCCN message has been sent (e.g., 1 + 2 + 4 + 8
+ 8... seconds), or until the StopCCN message itself has been
acknowledged.
A sliding window mechanism is used for control message transmission
and retransmission. Consider two peers, A and B. Suppose A
specifies a Receive Window Size AVP with a value of N in the SCCRQ or
SCCRP message. B is now allowed to have a maximum of N outstanding
(i.e., unacknowledged) control messages. Once N messages have been
sent, B must wait for an acknowledgment from A that advances the
window before sending new control messages. An implementation may
advertise a non-zero receive window as small or as large as it
wishes, depending on its own ability to process incoming messages
before sending an acknowledgement. Each peer MUST limit the number
of unacknowledged messages it will send before receiving an
acknowledgement by this Receive Window Size. The actual internal
Lau, et al. Standards Track [Page 24]
RFC 3931 L2TPv3 March 2005
unacknowledged message send-queue depth may be further limited by
local resource allocation or by dynamic slow-start and congestion-
avoidance mechanisms.
When retransmitting control messages, a slow start and congestion
avoidance window adjustment procedure SHOULD be utilized. A
recommended procedure is described in Appendix A. A peer MAY drop
messages, but MUST NOT actively delay acknowledgment of messages as a
technique for flow control of control messages. Appendix B contains
examples of control message transmission, acknowledgment, and
retransmission.
4.3. Control Message Authentication
L2TP incorporates an optional authentication and integrity check for
all control messages. This mechanism consists of a computed one-way
hash over the header and body of the L2TP control message, a pre-
configured shared secret, and a local and remote nonce (random value)
exchanged via the Control Message Authentication Nonce AVP. This
per-message authentication and integrity check is designed to perform
a mutual authentication between L2TP nodes, perform integrity
checking of all control messages, and guard against control message
spoofing and replay attacks that would otherwise be trivial to mount.
At least one shared secret (password) MUST exist between
communicating L2TP nodes to enable Control Message Authentication.
See Section 5.4.3 for details on calculation of the Message Digest
and construction of the Control Message Authentication Nonce and
Message Digest AVPs.
L2TPv3 Control Message Authentication is similar to L2TPv2 [RFC2661]
Tunnel Authentication in its use of a shared secret and one-way hash
calculation. The principal difference is that, instead of computing
the hash over selected contents of a received control message (e.g.,
the Challenge AVP and Message Type) as in L2TPv2, the entire message
is used in the hash in L2TPv3. In addition, instead of including the
hash digest in just the SCCRP and SCCCN messages, it is now included
in all L2TP messages.
The Control Message Authentication mechanism is optional, and may be
disabled if both peers agree. For example, if IPsec is already being
used for security and integrity checking between the LCCEs, the
function of the L2TP mechanism becomes redundant and may be disabled.
Presence of the Control Message Authentication Nonce AVP in an SCCRQ
or SCCRP message serves as indication to a peer that Control Message
Authentication is enabled. If an SCCRQ or SCCRP contains a Control
Message Authentication Nonce AVP, the receiver of the message MUST
Lau, et al. Standards Track [Page 25]
RFC 3931 L2TPv3 March 2005
respond with a Message Digest AVP in all subsequent messages sent.
Control Message Authentication is always bidirectional; either both
sides participate in authentication, or neither does.
If Control Message Authentication is disabled, the Message Digest AVP
still MAY be sent as an integrity check of the message. The
integrity check is calculated as in Section 5.4.3, with an empty
zero-length shared secret, local nonce, and remote nonce. If an
invalid Message Digest is received, it should be assumed that the
message has been corrupted in transit and the message dropped
accordingly.
Implementations MAY rate-limit control messages, particularly SCCRQ
messages, upon receipt for performance reasons or for protection
against denial of service attacks.
4.4. Keepalive (Hello)
L2TP employs a keepalive mechanism to detect loss of connectivity
between a pair of LCCEs. This is accomplished by injecting Hello
control messages (see Section 6.5) after a period of time has elapsed
since the last data message or control message was received on an
L2TP session or control connection, respectively. As with any other
control message, if the Hello message is not reliably delivered, the
sending LCCE declares that the control connection is down and resets
its state for the control connection. This behavior ensures that a
connectivity failure between the LCCEs is detected independently by
each end of a control connection.
Since the control channel is operated in-band with data traffic over
the PSN, this single mechanism can be used to infer basic data
connectivity between a pair of LCCEs for all sessions associated with
the control connection.
Periodic keepalive for the control connection MUST be implemented by
sending a Hello if a period of time (a recommended default is 60
seconds, but MUST be configurable) has passed without receiving any
message (data or control) from the peer. An LCCE sending Hello
messages across multiple control connections between the same LCCE
endpoints MUST employ a jittered timer mechanism to prevent grouping
of Hello messages.
4.5. Forwarding Session Data Frames
Once session establishment is complete, circuit frames are received
at an LCCE, encapsulated in L2TP (with appropriate attention to
framing, as described in documents for the particular pseudowire
type), and forwarded over the appropriate session. For every
Lau, et al. Standards Track [Page 26]
RFC 3931 L2TPv3 March 2005
outgoing data message, the sender places the identifier specified in
the Local Session ID AVP (received from peer during session
establishment) in the Session ID field of the L2TP data header. In
this manner, session frames are multiplexed and demultiplexed between
a given pair of LCCEs. Multiple control connections may exist
between a given pair of LCCEs, and multiple sessions may be
associated with a given control connection.
The peer LCCE receiving the L2TP data packet identifies the session
with which the packet is associated by the Session ID in the data
packet's header. The LCCE then checks the Cookie field in the data
packet against the Cookie value received in the Assigned Cookie AVP
during session establishment. It is important for implementers to
note that the Cookie field check occurs after looking up the session
context by the Session ID, and as such, consists merely of a value
match of the Cookie field and that stored in the retrieved context.
There is no need to perform a lookup across the Session ID and Cookie
as a single value. Any received data packets that contain invalid
Session IDs or associated Cookie values MUST be dropped. Finally,
the LCCE either forwards the network packet within the tunneled frame
(e.g., as an LNS) or switches the frame to a circuit (e.g., as an
LAC).
4.6. Default L2-Specific Sublayer
This document defines a Default L2-Specific Sublayer format (see
Section 3.2.2) that a pseudowire may use for features such as
sequencing support, L2 interworking, OAM, or other per-data-packet
operations. The Default L2-Specific Sublayer SHOULD be used by a
given PW type to support these features if it is adequate, and its
presence is requested by a peer during session negotiation.
Alternative sublayers MAY be defined (e.g., an encapsulation with a
larger Sequence Number field or timing information) and identified
for use via the L2-Specific Sublayer Type AVP.
Figure 4.6: Default L2-Specific Sublayer Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The S (Sequence) bit is set to 1 when the Sequence Number contains a
valid number for this sequenced frame. If the S bit is set to zero,
the Sequence Number contents are undefined and MUST be ignored by the
receiver.
Lau, et al. Standards Track [Page 27]
RFC 3931 L2TPv3 March 2005
The Sequence Number field contains a free-running counter of 2^24
sequence numbers. If the number in this field is valid, the S bit
MUST be set to 1. The Sequence Number begins at zero, which is a
valid sequence number. (In this way, implementations inserting
sequence numbers do not have to "skip" zero when incrementing.) The
sequence number in the header of a received message is considered
less than or equal to the last received number if its value lies in
the range of the last received number and the preceding (2^23-1)
values, inclusive.
4.6.1. Sequencing Data Packets
The Sequence Number field may be used to detect lost, duplicate, or
out-of-order packets within a given session.
When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP
data channel, this part of the link has the characteristic of being
able to reorder, duplicate, or silently drop packets. Reordering may
break some non-IP protocols or L2 control traffic being carried by
the link. Silent dropping or duplication of packets may break
protocols that assume per-packet indications of error, such as TCP
header compression. While a common mechanism for packet sequence
detection is provided, the sequence dependency characteristics of
individual protocols are outside the scope of this document.
If any protocol being transported by over L2TP data channels cannot
tolerate misordering of data packets, packet duplication, or silent
packet loss, sequencing may be enabled on some or all packets by
using the S bit and Sequence Number field defined in the Default L2-
Specific Sublayer (see Section 4.6). For a given L2TP session, each
LCCE is responsible for communicating to its peer the level of
sequencing support that it requires of data packets that it receives.
Mechanisms to advertise this information during session negotiation
are provided (see Data Sequencing AVP in Section 5.4.4).
When determining whether a packet is in or out of sequence, an
implementation SHOULD utilize a method that is resilient to temporary
dropouts in connectivity coupled with high per-session packet rates.
The recommended method is outlined in Appendix C.
4.7. L2TPv2/v3 Interoperability and Migration
L2TPv2 and L2TPv3 environments should be able to coexist while a
migration to L2TPv3 is made. Migration issues are discussed for each
media type in this section. Most issues apply only to
implementations that require both L2TPv2 and L2TPv3 operation.
Lau, et al. Standards Track [Page 28]
RFC 3931 L2TPv3 March 2005
However, even L2TPv3-only implementations must at least be mindful of
these issues in order to interoperate with implementations that
support both versions.
4.7.1. L2TPv3 over IP
L2TPv3 implementations running strictly over IP with no desire to
interoperate with L2TPv2 implementations may safely disregard most
migration issues from L2TPv2. All control messages and data messages
are sent as described in this document, without normative reference
to RFC 2661.
If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only
if it is not available, then L2TPv3 over UDP with automatic fallback
(see Section 4.7.3) MUST be used. There is no deterministic method
for automatic fallback from L2TPv3 over IP to either L2TPv2 or L2TPv3
over UDP. One could infer whether L2TPv3 over IP is supported by
sending an SCCRQ and waiting for a response, but this could be
problematic during periods of packet loss between L2TP nodes.
4.7.2. L2TPv3 over UDP
The format of the L2TPv3 over UDP header is defined in Section
4.1.2.1.
When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2
and shares the first two octets of header format with L2TPv2. The
Ver field is used to distinguish L2TPv2 packets from L2TPv3 packets.
If an implementation is capable of operating in L2TPv2 or L2TPv3
modes, it is possible to automatically detect whether a peer can
support L2TPv2 or L2TPv3 and operate accordingly. The details of
this fallback capability is defined in the following section.
4.7.3. Automatic L2TPv2 Fallback
When running over UDP, an implementation may detect whether a peer is
L2TPv3-capable by sending a special SCCRQ that is properly formatted
for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ
with its Ver field set to 2 (for L2TPv2), and ensuring that any
L2TPv3-specific AVPs (i.e., AVPs present within this document and not
defined within RFC 2661) in the message are sent with each M bit set
to 0, and that all L2TPv2 AVPs are present as they would be for
L2TPv2. This is done so that L2TPv3 AVPs will be ignored by an
L2TPv2-only implementation. Note that, in both L2TPv2 and L2TPv3,
the value contained in the space of the control message header
utilized by the 32-bit Control Connection ID in L2TPv3, and the 16-
bit Tunnel ID and
Lau, et al. Standards Track [Page 29]
RFC 3931 L2TPv3 March 2005
16-bit Session ID in L2TPv2, are always 0 for an SCCRQ. This
effectively hides the fact that there are a pair of 16-bit fields in
L2TPv2, and a single 32-bit field in L2TPv3.
If the peer implementation is L2TPv3-capable, a control message with
the Ver field set to 3 and an L2TPv3 header and message format will
be sent in response to the SCCRQ. Operation may then continue as
L2TPv3. If a message is received with the Ver field set to 2, it
must be assumed that the peer implementation is L2TPv2-only, thus
enabling fallback to L2TPv2 mode to safely occur.
Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3
implementations over UDP be liberal in accepting an SCCRQ control
message with the Ver field set to 2 or 3 and the presence of L2TPv2-
specific AVPs. An L2TPv3-only implementation MUST ignore all L2TPv2
AVPs (e.g., those defined in RFC 2661 and not in this document)
within an SCCRQ with the Ver field set to 2 (even if the M bit is set
on the L2TPv2-specific AVPs).
5. Control Message Attribute Value Pairs
To maximize extensibility while permitting interoperability, a
uniform method for encoding message types is used throughout L2TP.
This encoding will be termed AVP (Attribute Value Pair) for the
remainder of this document.
5.1. AVP Format
Each AVP is encoded as follows:
Figure 5.1: AVP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(until Length is reached) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first six bits comprise a bit mask that describes 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 when sent and ignored upon receipt.
Lau, et al. Standards Track [Page 30]
RFC 3931 L2TPv3 March 2005
Mandatory (M) bit: Controls the behavior required of an
implementation that receives an unrecognized AVP. The M bit of a
given AVP MUST only be inspected and acted upon if the AVP is
unrecognized (see Section 5.2).
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 5.3 describes the procedure for performing AVP hiding.
Length: Contains 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.
In the event that the 16-bit Vendor ID space is exhausted, vendor-
specific AVPs with a 32-bit Vendor ID MUST be encapsulated in the
following manner:
Lau, et al. Standards Track [Page 31]
RFC 3931 L2TPv3 March 2005
Figure 5.2: Extended Vendor ID AVP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 58 | 32-bit Vendor ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(until Length is reached) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP encodes a vendor-specific AVP with a 32-bit Vendor ID space
within the Attribute Value field. Multiple AVPs of this type may
exist in any message. The 16-bit Vendor ID MUST be 0, indicating
that this is an IETF-defined AVP, and the Attribute Type MUST be 58,
indicating that what follows is a vendor-specific AVP with a 32-bit
Vendor ID code. This AVP MAY be hidden (the H bit MAY be 0 or 1).
The M bit for this AVP MUST be set to 0. The Length of the AVP is 12
plus the length of the Attribute Value.
5.2. Mandatory AVPs and Setting the M Bit
If the M bit is set on an AVP that is unrecognized by its recipient,
the session or control connection associated with the control message
containing the AVP MUST be shut down. If the control message
containing the unrecognized AVP is associated with a session (e.g.,
an ICRQ, ICRP, ICCN, SLI, etc.), then the session MUST be issued a
CDN with a Result Code of 2 and Error Code of 8 (as defined in
Section 5.4.2) and shut down. If the control message containing the
unrecognized AVP is associated with establishment or maintenance of a
Control Connection (e.g., SCCRQ, SCCRP, SCCCN, Hello), then the
associated Control Connection MUST be issued a StopCCN with Result
Code of 2 and Error Code of 8 (as defined in Section 5.4.2) and shut
down. If the M bit is not set on an unrecognized AVP, the AVP MUST
be ignored when received, processing the control message as if the
AVP were not present.
Receipt of an unrecognized 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 set for AVPs that are deemed crucial
to proper operation of the session or control connection by the
sender. AVPs that are considered crucial by the sender may vary by
application and configured options. In no case shall a receiver of
Lau, et al. Standards Track [Page 32]
RFC 3931 L2TPv3 March 2005
an AVP "validate" if the M bit is set on a recognized AVP. If the
AVP is recognized (as all AVPs defined in this document MUST be for a
compliant L2TPv3 specification), then by definition, the M bit is of
no consequence.
The sender of an AVP is free to set its M bit to 1 or 0 based on
whether the configured application strictly requires the value
contained in the AVP to be recognized or not. For example,
"Automatic L2TPv2 Fallback" in Section 4.7.3 requires the setting of
the M bit on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is
supported and desired, and 1 if not.
The M bit is useful as extra assurance for support of critical AVP
extensions. However, more explicit methods may be available to
determine support for a given feature rather than using the M bit
alone. For example, if a new AVP is defined in a message for which
there is always a message reply (i.e., an ICRQ, ICRP, SCCRQ, or SCCRP
message), rather than simply sending an AVP in the message with the M
bit set, availability of the extension may be identified by sending
an AVP in the request message and expecting a corresponding AVP in a
reply message. This more explicit method, when possible, is
preferred.
The M bit also plays a role in determining whether or not a malformed
or out-of-range value within an AVP should be ignored or should
result in termination of a session or control connection (see Section
7.1 for more details).
5.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, IDs, or other vital
information.
The H bit MUST only be set if (1) a shared secret exists between the
LCCEs and (2) Control Message Authentication is enabled (see Section
4.3). If the H bit is set in any AVP(s) in a given control message,
at least one Random Vector AVP must also be present in the message
and MUST precede the first AVP having an H bit of 1.
Lau, et al. Standards Track [Page 33]
RFC 3931 L2TPv3 March 2005
The shared secret between LCCEs is used to derive a unique shared key
for hiding and unhiding calculations. The derived shared key is
obtained via an HMAC-MD5 keyed hash [RFC2104], with the key
consisting of the shared secret, and with the data being hashed
consisting of a single octet containing the value 1.
shared_key = HMAC_MD5 (shared_secret, 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 the Hidden AVP Subformat, which appears as follows:
Figure 5.3: Hidden AVP Subformat
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 would become 6 +
Attribute Value length + size of the Length of Original Attribute
Value field + Padding. Thus, if Padding is 12 octets, the AVP length
would be 6 + 4 + 2 + 12 = 24 octets.
Lau, et al. Standards Track [Page 34]
RFC 3931 L2TPv3 March 2005
Next, an MD5 [RFC1321] hash is performed (in network byte order) on
the concatenation of the following:
+ the 2-octet Attribute number of the AVP
+ the shared key
+ 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, but not for hiding two or more instances of an AVP with the
same Attribute Type unless the Attribute Values in the two AVPs are
also identical. When a different random vector is used for the
hiding of subsequent AVPs, a new Random Vector AVP MUST be placed in
the control 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
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 key
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 key 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 [RFC2865], 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 key S, the Random Vector RV, and the Attribute Type
A. Break the value field into 16-octet chunks p_1, p_2, 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 b_1, b_2, etc.
Lau, et al. Standards Track [Page 35]
RFC 3931 L2TPv3 March 2005
b_1 = MD5 (A + S + RV) c_1 = p_1 xor b_1
b_2 = MD5 (S + c_1) c_2 = p_2 xor b_2
. .
. .
. .
b_i = MD5 (S + c_i-1) c_i = p_i xor b_i
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.
5.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.
5.4.1. General Control Message AVPs
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.
Lau, et al. Standards Track [Page 36]
RFC 3931 L2TPv3 March 2005
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, 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 MUST 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 5.1). The Message Type AVP MUST still
be the first AVP in the control message.
Message Digest (All Messages)
The Message Digest AVP, Attribute Type 59 is used as an integrity
and authentication check of the L2TP Control Message header and
body.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest Type | Message Digest ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 or 20 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Digest Type is a one-octet integer indicating the Digest
calculation algorithm:
0 HMAC-MD5 [RFC2104]
1 HMAC-SHA-1 [RFC2104]
Digest Type 0 (HMAC-MD5) MUST be supported, while Digest Type 1
(HMAC-SHA-1) SHOULD be supported.
The Message Digest is of variable length and contains the result
of the control message authentication and integrity calculation.
For Digest Type 0 (HMAC-MD5), the length of the digest MUST be 16
Lau, et al. Standards Track [Page 37]
RFC 3931 L2TPv3 March 2005
bytes. For Digest Type 1 (HMAC-SHA-1) the length of the digest
MUST be 20 bytes.
If Control Message Authentication is enabled, at least one Message
Digest AVP MUST be present in all messages and MUST be placed
immediately after the Message Type AVP. This forces the Message
Digest AVP to begin at a well-known and fixed offset. A second
Message Digest AVP MAY be present in a message and MUST be placed
directly after the first Message Digest AVP.
The shared secret between LCCEs is used to derive a unique shared
key for Control Message Authentication calculations. The derived
shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with
the key consisting of the shared secret, and with the data being
hashed consisting of a single octet containing the value 2.
shared_key = HMAC_MD5 (shared_secret, 2)
Calculation of the Message Digest is as follows for all messages
other than the SCCRQ (where "+" refers to concatenation):
Message Digest = HMAC_Hash (shared_key, local_nonce +
remote_nonce + control_message)
HMAC_Hash: HMAC Hashing algorithm identified by the Digest Type
(MD5 or SHA1)
local_nonce: Nonce chosen locally and advertised to the remote
LCCE.
remote_nonce: Nonce received from the remote LCCE
(The local_nonce and remote_nonce are advertised via the
Control Message Authentication Nonce AVP, also defined in this
section.)
shared_key: Derived shared key for this control connection
control_message: The entire contents of the L2TP control
message, including the control message header and all AVPs.
Note that the control message header in this case begins after
the all-zero Session ID when running over IP (see Section
4.1.1.2), and after the UDP header when running over UDP (see
Section 4.1.2.1).
When calculating the Message Digest, the Message Digest AVP MUST
be present within the control message with the Digest Type set to
its proper value, but the Message Digest itself set to zeros.
Lau, et al. Standards Track [Page 38]
RFC 3931 L2TPv3 March 2005
When receiving a control message, the contents of the Message
Digest AVP MUST be compared against the expected digest value
based on local calculation. This is done by performing the same
digest calculation above, with the local_nonce and remote_nonce
reversed. This message authenticity and integrity checking MUST
be performed before utilizing any information contained within the
control message. If the calculation fails, the message MUST be
dropped.
The SCCRQ has special treatment as it is the initial message
commencing a new control connection. As such, there is only one
nonce available. Since the nonce is present within the message
itself as part of the Control Message Authentication Nonce AVP,
there is no need to use it in the calculation explicitly.
Calculation of the SCCRQ Message Digest is performed as follows:
Message Digest = HMAC_Hash (shared_key, control_message)
To allow for graceful switchover to a new shared secret or hash
algorithm, two Message Digest AVPs MAY be present in a control
message, and two shared secrets MAY be configured for a given
LCCE. If two Message Digest AVPs are received in a control
message, the message MUST be accepted if either Message Digest is
valid. If two shared secrets are configured, each (separately)
MUST be used for calculating a digest to be compared to the
Message Digest(s) received. When calculating a digest for a
control message, the Value field for both of the Message Digest
AVPs MUST be set to zero.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type
2 (HMAC-SHA-1).
Control Message Authentication Nonce (SCCRQ, SCCRP)
The Control Message Authentication Nonce AVP, Attribute Type 73,
MUST contain a cryptographically random value [RFC1750]. This
value is used for Control Message Authentication.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lau, et al. Standards Track [Page 39]
RFC 3931 L2TPv3 March 2005
The Nonce is of arbitrary length, though at least 16 octets is
recommended. The Nonce contains the random value for use in the
Control Message Authentication hash calculation (see Message
Digest AVP definition in this section).
If Control Message Authentication is enabled, this AVP MUST be
present in the SCCRQ and SCCRP messages.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 6 plus the length of the Nonce.
Random Vector (All Messages)
The Random Vector AVP, Attribute Type 36, MUST contain a
cryptographically random value [RFC1750]. This value is used for
AVP Hiding.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octet String ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Random Octet String is of arbitrary length, though 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 5.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. As such, at least one Random Vector AVP MUST
precede the first AVP with the H bit set.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 6 plus the length of the Random Octet
String.
5.4.2. Result and Error Codes
Result Code (StopCCN, CDN)
The Result Code AVP, Attribute Type 1, indicates the reason for
terminating the control connection or session.
Lau, et al. Standards Track [Page 40]
RFC 3931 L2TPv3 March 2005
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 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message ... (optional, arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 is 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 [RFC3629]
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, but MAY vary (see Section 5.2). The
Length is 8 if there is no Error Code or Message, 10 if there is
an Error Code and no Error Message, or 10 plus 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 connection already exists.
4 - Requester is not authorized to establish a control
connection.
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 or timeout
General Result Code values for the CDN message are as follows:
0 - Reserved.
1 - Session disconnected due to loss of carrier or
circuit disconnect.
2 - Session disconnected for the reason indicated in Error
Code.
3 - Session disconnected for administrative reasons.
4 - Session establishment failed due to lack of appropriate
facilities being available (temporary condition).
Lau, et al. Standards Track [Page 41]
RFC 3931 L2TPv3 March 2005
5 - Session establishment failed due to lack of appropriate
facilities being available (permanent condition).
13 - Session not established due to losing tie breaker.
14 - Session not established due to unsupported PW type.
15 - Session not established, sequencing required without
valid L2-Specific Sublayer.
16 - Finite state machine error or timeout.
Additional service-specific Result Codes are defined outside this
document.
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.
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 shut down due to receipt
of an unknown AVP with the M bit set (see Section 5.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 (e.g., "192.0.2.1, 192.0.2.2,
192.0.2.3") in the UTF-8 charset [RFC3629] using the Default
Language [RFC2277]. If there are no servers for the LAC or
LNS to suggest, then Error Code 7 should be used. For IPv4,
the delimiter between addresses MUST be precisely a single
comma and a single space. For IPv6, each literal address MUST
be enclosed in "[" and "]" characters, following the encoding
described in [RFC2732].
Lau, et al. Standards Track [Page 42]
RFC 3931 L2TPv3 March 2005
When a General Error Code of 6 is used, additional information
about the error SHOULD be included in the Error Message field. A
vendor-specific AVP MAY be sent to more precisely detail a
vendor-specific problem.
5.4.3. Control Connection Management AVPs
Control Connection Tie Breaker (SCCRQ)
The Control Connection Tie Breaker AVP, Attribute Type 5,
indicates that the sender desires a single control connection to
exist between a given pair of LCCEs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection Tie Breaker Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control Connection Tie Breaker Value is an 8-octet random
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; if
so, a tie has been detected. In this case, the LCCE must compare
its Control Connection Tie Breaker value with the one received in
the SCCRQ. The lower value "wins", and the "loser" MUST discard
its control connection. A StopCCN SHOULD be sent by the winner as
an explicit rejection for the losing SCCRQ. 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 with a new, random tie breaker
value.
If a tie breaker is received and an outstanding SCCRQ has no tie
breaker value, the initiator that included the Control Connection
Tie Breaker AVP "wins". If neither side issues a tie breaker,
then two separate control connections are opened.
Applications that employ a distinct and well-known initiator have
no need for tie breaking, and MAY omit this AVP or disable tie
breaking functionality. Applications that require tie breaking
also require that an LCCE be uniquely identifiable upon receipt of
an SCCRQ. For L2TP over IP, this MUST be accomplished via the
Router ID AVP.
Lau, et al. Standards Track [Page 43]
RFC 3931 L2TPv3 March 2005
Note that in [RFC2661], this AVP is referred to as the "Tie
Breaker AVP" and is applicable only to a control connection. In
L2TPv3, the AVP serves the same purpose of tie breaking, but is
applicable to a control connection or a session. The Control
Connection Tie Breaker AVP (present only in Control Connection
messages) and Session Tie Breaker AVP (present only in Session
messages), are described separately in this document, but share
the same Attribute type of 5.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
length of this AVP is 14.
Host Name (SCCRQ, SCCRP)
The Host Name AVP, Attribute Type 7, indicates the name of the
issuing LAC or LNS, encoded in the US-ASCII charset.
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 host name with fully qualified
domain would be appropriate. The Host Name AVP and/or Router ID
AVP MUST be used to identify an LCCE as described in Section 3.3.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 6 plus the length of the Host Name.
Router ID (SCCRQ, SCCRP)
The Router ID AVP, Attribute Type 60, is an identifier used to
identify an LCCE for control connection setup, tie breaking,
and/or tunnel authentication.
Lau, et al. Standards Track [Page 44]
RFC 3931 L2TPv3 March 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Router Identifier is a 4-octet unsigned integer. Its value is
unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host
Name AVP and/or Router ID AVP MUST be used to identify an LCCE as
described in Section 3.3.
Implementations MUST NOT assume that Router Identifier is a valid
IP address. The Router Identifier for L2TP over IPv6 can be
obtained from an IPv4 address (if available) or via unspecified
implementation-specific means.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 10.
Vendor Name (SCCRQ, SCCRP)
The Vendor Name AVP, Attribute Type 8, contains a vendor-specific
(possibly human-readable) string describing the type of LAC or LNS
being used.
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 US-ASCII charset [RFC1958, 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, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 6 plus the length of the
Vendor Name.
Lau, et al. Standards Track [Page 45]
RFC 3931 L2TPv3 March 2005
Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN)
The Assigned Control Connection ID AVP, Attribute Type 61,
contains 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 the identifier
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.
Under certain circumstances, an LCCE may need to send a StopCCN to
a peer without having yet received an Assigned Control Connection
ID AVP from the peer (i.e., SCCRQ sent, no SCCRP received yet).
In this case, the Assigned Control Connection ID AVP that had been
sent to the peer earlier (i.e., in the SCCRQ) MUST be sent as the
Assigned Control Connection ID AVP in the StopCCN. This policy
allows the peer to try to identify the appropriate control
connection via a reverse lookup.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). 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.
Lau, et al. Standards Track [Page 46]
RFC 3931 L2TPv3 March 2005
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. See Section 4.2 for
more information on reliable control message delivery.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 8.
Pseudowire Capabilities List (SCCRQ, SCCRP)
The Pseudowire Capabilities List (PW Capabilities List) AVP,
Attribute Type 62, indicates the L2 payload types the sender can
support. The specific payload type of a given session is
identified by the Pseudowire 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PW Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Defined PW types that may appear in this list are managed by IANA
and will appear in associated pseudowire-specific documents for
each PW type.
If a sender includes a given PW type in the PW Capabilities List
AVP, the sender assumes full responsibility for supporting that
particular payload, such as any payload-specific AVPs, L2-Specific
Sublayer, or control messages that may be defined in the
appropriate companion document.
Lau, et al. Standards Track [Page 47]
|
