As per Relevance of the word establish, we have this rfc below:
Network Working Group W.
Request for Comments: 2661 A.
Category: Standards Track cisco
A.
Ascend
G.
G.
Microsoft
B.
Redback
August 1999
Layer Two Tunneling Protocol "L2TP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document describes the Layer Two Tunneling Protocol (L2TP).
51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2
facilitates the tunneling of PPP packets across an
network in a way that is as transparent as possible to both end-
and applications
Table of
1.0 Introduction.......................................... 3
1.1 Specification of Requirements......................... 4
1.2 Terminology........................................... 4
2.0 Topology.............................................. 8
3.0 Protocol Overview..................................... 9
3.1 L2TP Header Format.................................... 9
3.2 Control Message Types................................. 11
4.0 Control Message Attribute Value Pairs................. 12
4.1 AVP Format............................................ 13
4.2 Mandatory AVPs........................................ 14
4.3 Hiding of AVP Attribute Values........................ 14
Townsley, et al. Standards Track [Page 1]
RFC 2661 L2TP August 1999
4.4 AVP Summary........................................... 17
4.4.1 AVPs Applicable To All Control Messages.......... 17
4.4.2 Result and Error Codes........................... 18
4.4.3 Control Connection Management AVPs............... 20
4.4.4 Call Management AVPs............................. 27
4.4.5 Proxy LCP and Authentication AVPs................ 34
4.4.6 Call Status AVPs................................. 39
5.0 Protocol Operation.................................... 41
5.1 Control Connection Establishment...................... 41
5.1.1 Tunnel Authentication............................ 42
5.2 Session Establishment................................. 42
5.2.1 Incoming Call Establishment...................... 42
5.2.2 Outgoing Call Establishment...................... 43
5.3 Forwarding PPP Frames................................. 43
5.4 Using Sequence Numbers on the Data Channel............ 44
5.5 Keepalive (Hello)..................................... 44
5.6 Session Teardown...................................... 45
5.7 Control Connection Teardown........................... 45
5.8 Reliable Delivery of Control Messages................. 46
6.0 Control Connection Protocol Specification............. 48
6.1 Start-Control-Connection-Request (SCCRQ).............. 48
6.2 Start-Control-Connection-Reply (SCCRP)................ 48
6.3 Start-Control-Connection-Connected (SCCCN)............ 49
6.4 Stop-Control-Connection-Notification (StopCCN)........ 49
6.5 Hello (HELLO)......................................... 49
6.6 Incoming-Call-Request (ICRQ).......................... 50
6.7 Incoming-Call-Reply (ICRP)............................ 51
6.8 Incoming-Call-Connected (ICCN)........................ 51
6.9 Outgoing-Call-Request (OCRQ).......................... 52
6.10 Outgoing-Call-Reply (OCRP)........................... 53
6.11 Outgoing-Call-Connected (OCCN)....................... 53
6.12 Call-Disconnect-Notify (CDN)......................... 53
6.13 WAN-Error-Notify (WEN)............................... 54
6.14 Set-Link-Info (SLI).................................. 54
7.0 Control Connection State Machines..................... 54
7.1 Control Connection Protocol Operation................. 55
7.2 Control Connection States............................. 56
7.2.1 Control Connection Establishment................. 56
7.3 Timing considerations................................. 58
7.4 Incoming calls........................................ 58
7.4.1 LAC Incoming Call States......................... 60
7.4.2 LNS Incoming Call States......................... 62
7.5 Outgoing calls........................................ 63
7.5.1 LAC Outgoing Call States......................... 64
7.5.2 LNS Outgoing Call States......................... 66
7.6 Tunnel Disconnection.................................. 67
8.0 L2TP Over Specific Media.............................. 67
8.1 L2TP over UDP/IP...................................... 68
Townsley, et al. Standards Track [Page 2]
RFC 2661 L2TP August 1999
8.2 IP.................................................... 69
9.0 Security Considerations............................... 69
9.1 Tunnel Endpoint Security.............................. 70
9.2 Packet Level Security................................. 70
9.3 End to End Security................................... 70
9.4 L2TP and IPsec........................................ 71
9.5 Proxy PPP Authentication.............................. 71
10.0 IANA Considerations.................................. 71
10.1 AVP Attributes....................................... 71
10.2 Message Type AVP Values.............................. 72
10.3 Result Code AVP Values............................... 72
10.3.1 Result Code Field Values........................ 72
10.3.2 Error Code Field Values......................... 72
10.4 Framing Capabilities & Bearer Capabilities........... 72
10.5 Proxy Authen Type AVP Values......................... 72
10.6 AVP Header Bits...................................... 73
11.0 References........................................... 73
12.0 Acknowledgments...................................... 74
13.0 Authors' Addresses................................... 75
Appendix A: Control Channel Slow Start and
Avoidance..................................... 76
Appendix B: Control Message Examples...................... 77
Appendix C: Intellectual Property Notice.................. 79
Full Copyright Statement.................................. 80
1.0
PPP [RFC1661] defines an encapsulation mechanism for
multiprotocol packets across layer 2 (L2) point-to-point links
Typically, a user obtains a L2 connection to a Network Access
(NAS) using one of a number of techniques (e.g., dialup POTS, ISDN
ADSL, etc.) and then runs PPP over that connection. In such
configuration, the L2 termination point and PPP session
reside on the same physical device (i.e., the NAS).
L2TP extends the PPP model by allowing the L2 and PPP endpoints
reside on different devices interconnected by a packet-
network. With L2TP, a user has an L2 connection to an
concentrator (e.g., modem bank, ADSL DSLAM, etc.), and
concentrator then tunnels individual PPP frames to the NAS.
allows the actual processing of PPP packets to be divorced from
termination of the L2 circuit
One obvious benefit of such a separation is that instead of
the L2 connection terminate at the NAS (which may require
long-distance toll charge), the connection may terminate at a (local
circuit concentrator, which then extends the logical PPP session
Townsley, et al. Standards Track [Page 3]
RFC 2661 L2TP August 1999
a shared infrastructure such as frame relay circuit or the Internet
From the user's perspective, there is no functional difference
having the L2 circuit terminate in a NAS directly or using L2TP
L2TP may also solve the multilink hunt-group splitting problem
Multilink PPP [RFC1990] requires that all channels composing
multilink bundle be grouped at a single Network Access Server (NAS).
Due to its ability to project a PPP session to a location other
the point at which it was physically received, L2TP can be used
make all channels terminate at a single NAS. This allows
operation even when the calls are spread across distinct
NASs
This document defines the necessary control protocol for on-
creation of tunnels between two nodes and the
encapsulation for multiplexing multiple, tunneled PPP sessions
1.1 Specification of
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
1.2
Analog
A circuit-switched communication path which is intended to
3.1 kHz audio in each direction
Attribute Value Pair (AVP
The variable length concatenation of a unique
(represented by an integer) and a Value containing the
value identified by the attribute. Multiple AVPs make up
Messages which are used in the establishment, maintenance,
teardown of tunnels
A connection (or attempted connection) between a Remote System
LAC. For example, a telephone call through the PSTN. A
(Incoming or Outgoing) which is successfully established between
Remote System and LAC results in a corresponding L2TP
within a previously established Tunnel between the LAC and LNS
(See also: Session, Incoming Call, Outgoing Call).
Townsley, et al. Standards Track [Page 4]
RFC 2661 L2TP August 1999
Called
An indication to the receiver of a call as to what
number the caller used to reach it
Calling
An indication to the receiver of a call as to the telephone
of the caller
Challenge Handshake Authentication Protocol [RFC1994], a
cryptographic challenge/response authentication protocol in
the cleartext password is not passed over the line
Control
A control connection operates in-band over a tunnel to control
establishment, release, and maintenance of sessions and of
tunnel itself
Control
Control messages are exchanged between LAC and LNS pairs
operating in-band within the tunnel protocol. Control
govern aspects of the tunnel and sessions within the tunnel
Digital
A circuit-switched communication path which is intended to
digital information in each direction
Digital Subscriber Line (DSL) Access Module. A network device
in the deployment of DSL service. This is typically a
of individual DSL lines located in a central office (CO) or
exchange
Incoming
A Call received at an LAC to be tunneled to an LNS (see Call
Outgoing Call).
Townsley, et al. Standards Track [Page 5]
RFC 2661 L2TP August 1999
L2TP Access Concentrator (LAC
A node that acts as one side of an L2TP tunnel endpoint and is
peer to the L2TP Network Server (LNS). The LAC sits between
LNS and a remote system and forwards packets to and from each
Packets sent from the LAC to the LNS requires tunneling with
L2TP protocol as defined in this document. The connection
the LAC to the remote system is either local (see: Client LAC)
a PPP link
L2TP Network Server (LNS
A node that acts as one side of an L2TP tunnel endpoint and is
peer to the L2TP Access Concentrator (LAC). The LNS is
logical termination point of a PPP session that is being
from the remote system by the LAC
Management Domain (MD
A network or networks under the control of a
administration, policy or system. For example, an LNS's
Domain might be the corporate network it serves. An LAC'
Management Domain might be the Internet Service Provider that
and manages it
Network Access Server (NAS
A device providing local network access to users across a
access network such as the PSTN. An NAS may also serve as an LAC
LNS or both
Outgoing
A Call placed by an LAC on behalf of an LNS (see Call,
Call).
When used in context with L2TP, peer refers to either the LAC
LNS. An LAC's Peer is an LNS and vice versa. When used in
with PPP, a peer is either side of the PPP connection
Plain Old Telephone Service
Townsley, et al. Standards Track [Page 6]
RFC 2661 L2TP August 1999
Remote
An end-system or router attached to a remote access network (i.e
a PSTN), which is either the initiator or recipient of a call
Also referred to as a dial-up or virtual dial-up client
L2TP is connection-oriented. The LNS and LAC maintain state
each Call that is initiated or answered by an LAC. An L2TP
is created between the LAC and LNS when an end-to-end
connection is established between a Remote System and the LNS
Datagrams related to the PPP connection are sent over the
between the LAC and LNS. There is a one to one
between established L2TP Sessions and their associated Calls. (
also: Call).
A Tunnel exists between a LAC-LNS pair. The Tunnel consists of
Control Connection and zero or more L2TP Sessions. The
carries encapsulated PPP datagrams and Control Messages
the LAC and the LNS
Zero-Length Body (ZLB)
A control packet with only an L2TP header. ZLB messages are
for explicitly acknowledging packets on the reliable
channel
Townsley, et al. Standards Track [Page 7]
RFC 2661 L2TP August 1999
2.0
The following diagram depicts a typical L2TP scenario. The goal is
tunnel PPP frames between the Remote System or LAC Client and an
located at a Home LAN
[Home LAN
[LAC Client]----------+ |
____|_____ +--[Host
| | |
[LAC]---------| Internet |-----[LNS]-----+
| |__________| |
_____|_____ :
| |
| PSTN |
[Remote]--| Cloud |
[System] | | [Home LAN
|___________| |
| ______________ +---[Host
| | | |
[LAC]-------| Frame Relay |---[LNS]-----+
| or ATM Cloud | |
|______________| :
The Remote System initiates a PPP connection across the PSTN Cloud
an LAC. The LAC then tunnels the PPP connection across the Internet
Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN
obtained. The Remote System is provided addresses from the HOME
via PPP NCP negotiation. Authentication, Authorization and
may be provided by the Home LAN's Management Domain as if the
were connected to a Network Access Server directly
A LAC Client (a Host which runs L2TP natively) may also
in tunneling to the Home LAN without use of a separate LAC. In
case, the Host containing the LAC Client software already has
connection to the public Internet. A "virtual" PPP connection is
created and the local L2TP LAC Client software creates a tunnel
the LNS. As in the above case, Addressing, Authentication
Authorization and Accounting will be provided by the Home LAN'
Management Domain
Townsley, et al. Standards Track [Page 8]
RFC 2661 L2TP August 1999
3.0 Protocol
L2TP utilizes two types of messages, control messages and
messages. Control messages are used in the establishment,
and clearing of tunnels and calls. Data messages are used
encapsulate PPP frames being carried over the tunnel.
messages utilize a reliable Control Channel within L2TP to
delivery (see section 5.1 for details). Data messages are
retransmitted when packet loss occurs
+-------------------+
| PPP Frames |
+-------------------+ +-----------------------+
| L2TP Data Messages| | L2TP Control Messages |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+------------------------------------------------+
| Packet Transport (UDP, FR, ATM, etc.) |
+------------------------------------------------+
Figure 3.0 L2TP Protocol
Figure 3.0 depicts the relationship of PPP frames and
Messages over the L2TP Control and Data Channels. PPP Frames
passed over an unreliable Data Channel encapsulated first by an L2
header and then a Packet Transport such as UDP, Frame Relay, ATM
etc. Control messages are sent over a reliable L2TP Control
which transmits packets in-band over the same Packet Transport
Sequence numbers are required to be present in all control
and are used to provide reliable delivery on the Control Channel
Data Messages may use sequence numbers to reorder packets and
lost packets
All values are placed into their respective fields and sent
network order (high order octets first).
3.1 L2TP Header
L2TP packets for the control channel and data channel share a
header format. In each case where a field is optional, its space
not exist in the message if the field is marked not present.
that while optional on data messages, the Length, Ns, and Nr
marked as optional below, are required to be present on all
messages
Townsley, et al. Standards Track [Page 9]
RFC 2661 L2TP August 1999
This header is formatted
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|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.1 L2TP Message
The Type (T) bit indicates the type of message. It is set to 0 for
data message and 1 for a control message
If the Length (L) bit is 1, the Length field is present. This
MUST be set to 1 for control messages
The x bits are reserved for future extensions. All reserved bits
be set to 0 on outgoing messages and ignored on incoming messages
If the Sequence (S) bit is set to 1 the Ns and Nr fields are present
The S bit MUST be set to 1 for control messages
If the Offset (O) bit is 1, the Offset Size field is present. The
bit MUST be set to 0 (zero) for control messages
If the Priority (P) bit is 1, this data message should
preferential treatment in its local queuing and transmission.
echo requests used as a keepalive for the link, for instance,
generally be sent with this bit set to 1. Without it, a
interval of local congestion could result in interference
keepalive messages and unnecessary loss of the link. This feature
only for use with data messages. The P bit MUST be set to 0 for
control messages
Ver MUST be 2, indicating the version of the L2TP data message
described in this document. The value 1 is reserved to
detection of L2F [RFC2341] packets should they arrive intermixed
L2TP packets. Packets received with an unknown Ver field MUST
discarded
The Length field indicates the total length of the message in octets
Townsley, et al. Standards Track [Page 10]
RFC 2661 L2TP August 1999
Tunnel ID indicates the identifier for the control connection. L2
tunnels are named by identifiers that have local significance only
That is, the same tunnel will be given different Tunnel IDs by
end of the tunnel. Tunnel ID in each message is that of the
recipient, not the sender. Tunnel IDs are selected and exchanged
Assigned Tunnel ID AVPs during the creation of a tunnel
Session ID indicates the identifier for a session within a tunnel
L2TP sessions are named by identifiers that have local
only. That is, the same session will be given different Session
by each end of the session. Session ID in each message is that of
intended recipient, not the sender. Session IDs are selected
exchanged as Assigned Session ID AVPs during the creation of
session
Ns indicates the sequence number for this data or control message
beginning at zero and incrementing by one (modulo 2**16) for
message sent. See Section 5.8 and 5.4 for more information on
this field
Nr indicates the sequence number expected in the next control
to be received. Thus, Nr is set to the Ns of the last in-
message received plus one (modulo 2**16). In data messages, Nr
reserved and, if present (as indicated by the S-bit), MUST be
upon receipt. See section 5.8 for more information on using
field in control messages
The Offset Size field, if present, specifies the number of
past the L2TP header at which the payload data is expected to start
Actual data within the offset padding is undefined. If the
field is present, the L2TP header ends after the last octet of
offset padding
3.2 Control Message
The Message Type AVP (see section 4.4.1) defines the specific type
control message being sent. Recall from section 3.1 that this is
for control messages, that is, messages with the T-bit set to 1.
Townsley, et al. Standards Track [Page 11]
RFC 2661 L2TP August 1999
This document defines the following control message types (
Section 6.1 through 6.14 for details on the construction and use
each message):
Control Connection
0 (reserved
1 (SCCRQ) Start-Control-Connection-
2 (SCCRP) Start-Control-Connection-
3 (SCCCN) Start-Control-Connection-
4 (StopCCN) Stop-Control-Connection-
5 (reserved
6 (HELLO)
Call
7 (OCRQ) Outgoing-Call-
8 (OCRP) Outgoing-Call-
9 (OCCN) Outgoing-Call-
10 (ICRQ) Incoming-Call-
11 (ICRP) Incoming-Call-
12 (ICCN) Incoming-Call-
13 (reserved
14 (CDN) Call-Disconnect-
Error
15 (WEN) WAN-Error-
PPP Session
16 (SLI) Set-Link-
4.0 Control Message Attribute Value
To maximize extensibility while still permitting interoperability,
uniform method for encoding message types and bodies is
throughout L2TP. This encoding will be termed AVP (Attribute-
Pair) in the remainder of this document
Townsley, et al. Standards Track [Page 12]
RFC 2661 L2TP August 1999
4.1 AVP
Each AVP is encoded as
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Attribute Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[until Length is reached]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first six bits are a bit mask, describing the general
of the AVP
Two bits are defined in this document, the remaining are reserved
future extensions. Reserved bits MUST be set to 0. An AVP
with a reserved bit set to 1 MUST be treated as an unrecognized AVP
Mandatory (M) bit: Controls the behavior required of
implementation which receives an AVP which it does not recognize.
the M bit is set on an unrecognized AVP within a message
with a particular session, the session associated with this
MUST be terminated. If the M bit is set on an unrecognized AVP
a message associated with the overall tunnel, the entire tunnel (
all sessions within) MUST be terminated. If the M bit is not set,
unrecognized AVP MUST be ignored. The control message must
continue to be processed as if the AVP had not been present
Hidden (H) bit: Identifies the hiding of data in the Attribute
field of an AVP. This capability can be used to avoid the passing
sensitive data, such as user passwords, as cleartext in an AVP
Section 4.3 describes the procedure for performing AVP hiding
Length: Encodes the number of octets (including the Overall
and bitmask fields) contained in this AVP. The Length may
calculated as 6 + the length of the Attribute Value field in octets
The field itself is 10 bits, permitting a maximum of 1023 octets
data in a single AVP. The minimum Length of an AVP is 6. If
length is 6, then the Attribute Value field is absent
Vendor ID: The IANA assigned "SMI Network Management
Enterprise Codes" [RFC1700] value. The value 0, corresponding
IETF adopted attribute values, is used for all AVPs defined
this document. Any vendor wishing to implement their own L2
extensions can use their own Vendor ID along with private
Townsley, et al. Standards Track [Page 13]
RFC 2661 L2TP August 1999
values, guaranteeing that they will not collide with any
vendor's extensions, nor with future IETF extensions. Note that
are 16 bits allocated for the Vendor ID, thus limiting this
to the first 65,535 enterprises
Attribute Type: A 2 octet value with a unique interpretation
all AVPs defined under a given Vendor ID
Attribute Value: This is the actual value as indicated by the
ID and Attribute Type. It follows immediately after the
Type field, and runs for the remaining octets indicated in the
(i.e., Length minus 6 octets of header). This field is absent if
Length is 6.
4.2 Mandatory
Receipt of an unknown AVP that has the M-bit set is catastrophic
the session or tunnel it is associated with. Thus, the M bit
only be defined for AVPs which are absolutely crucial to
operation of the session or tunnel. Further, in the case where
LAC or LNS receives an unknown AVP with the M-bit set and shuts
the session or tunnel accordingly, it is the full responsibility
the peer sending the Mandatory AVP to accept fault for causing
non-interoperable situation. Before defining an AVP with the M-
set, particularly a vendor-specific AVP, be sure that this is
intended consequence
When an adequate alternative exists to use of the M-bit, it should
utilized. For example, rather than simply sending an AVP with the M
bit set to determine if a specific extension exists, availability
be identified by sending an AVP in a request message and expecting
corresponding AVP in a reply message
Use of the M-bit with new AVPs (those not defined in this document
MUST provide the ability to configure the associated feature off
such that the AVP is either not sent, or sent with the M-bit not set
4.3 Hiding of AVP Attribute
The H bit in the header of each AVP provides a mechanism to
to the receiving peer whether the contents of the AVP are hidden
present in cleartext. This feature can be used to hide
control message data such as user passwords or user IDs
The H bit MUST only be set if a shared secret exists between the
and LNS. The shared secret is the same secret that is used for
authentication (see Section 5.1.1). If the H bit is set in
Townsley, et al. Standards Track [Page 14]
RFC 2661 L2TP August 1999
AVP(s) in a given control message, a Random Vector AVP must also
present in the message and MUST precede the first AVP having an H
of 1.
Hiding an AVP value is done in several steps. The first step is
take the length and value fields of the original (cleartext) AVP
encode them into a Hidden AVP Subformat as follows
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Original Value | Original Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of Original Attribute Value: This is length of the
Attribute Value to be obscured in octets. This is necessary
determine the original length of the Attribute Value which is
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
Attribute Value that is being hidden
To mask the size of the data being hidden, the resulting
MAY be padded as shown above. Padding does NOT alter the value
in the Length of Original Attribute Value field, but does alter
length of the resultant AVP that is being created. For example, If
Attribute Value to be hidden is 4 octets in length, the unhidden
length would be 10 octets (6 + Attribute Value length). After hiding
the length of the AVP will become 6 + Attribute Value length +
of the Length of Original Attribute Value field + Padding. Thus,
Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24
octets
Next, An MD5 hash is performed on the concatenation of
+ the 2 octet Attribute number of the
+ the shared
+ an arbitrary length random
The value of the random vector used in this hash is passed in
value field of a Random Vector AVP. This Random Vector AVP must
placed in the message by the sender before any hidden AVPs. The
random vector may be used for more than one hidden AVP in the
Townsley, et al. Standards Track [Page 15]
RFC 2661 L2TP August 1999
message. If a different random vector is used for the hiding
subsequent AVPs then a new Random Vector AVP must be placed in
command message before the first AVP to which it applies
The MD5 hash value is then XORed with the first 16 octet (or less
segment of the Hidden AVP Subformat and placed in the Attribute
field of the Hidden AVP. If the Hidden AVP Subformat is less than 16
octets, the Subformat is transformed as if the Attribute Value
had been padded to 16 octets before the XOR, but only the
octets present in the Subformat are modified, and the length of
AVP is not altered
If the Subformat is longer than 16 octets, a second one-way MD5
is calculated over a stream of octets consisting of the shared
followed by the result of the first XOR. That hash is XORed with
second 16 octet (or less) segment of the Subformat and placed in
corresponding octets of the Value field of the Hidden AVP
If necessary, this operation is repeated, with the shared secret
along with each XOR result to generate the next hash to XOR the
segment of the value with
The hiding method was adapted from RFC 2138 [RFC2138] which was
from the "Mixing in the Plaintext" section in the book "
Security" by Kaufman, Perlman and Speciner [KPS]. A
explanation of the method follows
Call the shared secret S, the Random Vector RV, and the
Value AV. Break the value field into 16-octet chunks p1, p2, etc
with the last one padded at the end with random data to a 16-
boundary. Call the ciphertext blocks c(1), c(2), etc. We will
define intermediate values b1, b2, etc
b1 = MD5(AV + S + RV) c(1) = p1 xor b
b2 = MD5(S + c(1)) c(2) = p2 xor b
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor
The String will contain c(1)+c(2)+...+c(i) where +
concatenation
On receipt, the random vector is taken from the last Random
AVP encountered in the message prior to the AVP to be unhidden.
above process is then reversed to yield the original value
Townsley, et al. Standards Track [Page 16]
RFC 2661 L2TP August 1999
4.4 AVP
The following sections contain a list of all L2TP AVPs defined
this document
Following the name of the AVP is a list indicating the message
that utilize each AVP. After each AVP title follows a
description of the purpose of the AVP, a detail (including a graphic
of the format for the Attribute Value, and any additional
needed for proper use of the avp
4.4.1 AVPs Applicable To All Control
Message Type (All Messages
The Message Type AVP, Attribute Type 0, identifies the
message herein and defines the context in which the exact
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
section 3.1). See Section 3.2 for the list of defined
message types and their identifiers
The Mandatory (M) bit within the Message Type AVP has
meaning. Rather than an indication as to whether the AVP
should be ignored if not recognized, it is an indication as
whether the control message itself should be ignored. Thus, if
M-bit is set within the Message Type AVP and the Message Type
unknown to the implementation, the tunnel MUST be cleared. If
M-bit is not set, then the implementation may ignore an
message type. The M-bit MUST be set to 1 for all message
defined in this document. This AVP may not be hidden (the H-
MUST be 0). The Length of this AVP is 8.
Townsley, et al. Standards Track [Page 17]
RFC 2661 L2TP August 1999
Random Vector (All Messages
The Random Vector AVP, Attribute Type 36, is used to enable
hiding of the Attribute Value of arbitrary AVPs
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Random Octet String may be of arbitrary length, although
random vector of at least 16 octets is recommended. The
contains the random vector for use in computing the MD5 hash
retrieve or hide the Attribute Value of a hidden AVP (see
4.2).
More than one Random Vector AVP may appear in a message, in
case a hidden AVP uses the Random Vector AVP most
preceding it. This AVP MUST precede the first AVP with the H
set
The M-bit for this AVP MUST be set to 1. This AVP MUST NOT
hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus
length of the Random Octet String
4.4.2 Result and Error
Result Code (CDN, StopCCN
The Result Code AVP, Attribute Type 1, indicates the reason
terminating the control channel or session
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (opt) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Result Code is a 2 octet unsigned integer. The optional
Code is a 2 octet unsigned integer. An optional Error Message
follow the Error Code field. Presence of the Error Code
Townsley, et al. Standards Track [Page 18]
RFC 2661 L2TP August 1999
Message are indicated by the AVP Length field. The Error
contains an arbitrary string providing further (human readable
text associated with the condition. Human readable text in
error messages MUST be provided in the UTF-8 charset using
Default Language [RFC2277].
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit
this AVP MUST be set to 1. The Length is 8 if there is no
Code or Message, 10 if there is an Error Code and no Error
or 10 + the length of the Error Message if there is an Error
and Message
Defined Result Code values for the StopCCN message are
0 -
1 - General request to clear control
2 - General error--Error Code indicates the
3 - Control channel already
4 - Requester is not authorized to establish a
5 - The protocol version of the requester is
Error Code indicates highest version
6 - Requester is being shut
7 - Finite State Machine
Defined Result Code values for the CDN message are
0 -
1 - Call disconnected due to loss of
2 - Call disconnected for the reason
in error
3 - Call disconnected for administrative
4 - Call failed due to lack of appropriate
being available (temporary condition
5 - Call failed due to lack of appropriate facilities
available (permanent condition
6 - Invalid
7 - Call failed due to no carrier
8 - Call failed due to detection of a busy
9 - Call failed due to lack of a dial
10 - Call was not established within time allotted by
11 - Call was connected but no appropriate framing
The Error Codes defined below pertain to types of errors that
not specific to any particular L2TP request, but rather
protocol or message format errors. If an L2TP reply indicates
Townsley, et al. Standards Track [Page 19]
RFC 2661 L2TP August 1999
its Result Code that a general error occurred, the General
value should be examined to determine what the error was.
currently defined General Error codes and their meanings are
0 - No general
1 - No control connection exists yet for this LAC-LNS
2 - Length is
3 - One of the field values was out of range
reserved field was non-
4 - Insufficient resources to handle this operation
5 - The Session ID is invalid in this
6 - A generic vendor-specific error occurred in the
7 - Try another. If LAC is aware of other possible
destinations, it should try one of them. This can
used to guide an LAC based on LNS policy, for instance
the existence of multilink PPP bundles
8 - Session or tunnel was shutdown due to receipt of an
AVP with the M-bit set (see section 4.2). The Error
SHOULD contain the attribute of the offending AVP in (
readable) text form
When a General Error Code of 6 is used, additional
about the error SHOULD be included in the Error Message field
4.4.3 Control Connection Management
Protocol Version (SCCRP, SCCRQ
The Protocol Version AVP, Attribute Type 2, indicates the L2
protocol version of the sender
The Attribute Value field for this AVP has the following format
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rev |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Ver field is a 1 octet unsigned integer containing the
1. Rev field is a 1 octet unsigned integer containing 0.
pertains to L2TP protocol version 1, revision 0. Note this is
the same version number that is included in the header of
message
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit
this AVP MUST be set to 1. The Length of this AVP is 8.
Townsley, et al. Standards Track [Page 20]
RFC 2661 L2TP August 1999
Framing Capabilities (SCCRP, SCCRQ
The Framing Capabilities AVP, Attribute Type 3, provides the
with an indication of the types of framing that will be
or requested 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future framing type definitions |A|S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute Value field is a 32-bit mask, with two bits defined
If bit A is set, asynchronous framing is supported. If bit S
set, synchronous framing is supported
A peer MUST NOT request an incoming or outgoing call with
Framing Type AVP specifying a value not advertised in the
Capabilities AVP it received during control
establishment. Attempts to do so will result in the call
rejected
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) is 10.
Bearer Capabilities (SCCRP, SCCRQ
The Bearer Capabilities AVP, Attribute Type 4, provides the
with an indication of the bearer device types supported by
hardware interfaces of the sender for outgoing calls
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future bearer type definitions |A|D
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is a 32-bit mask, with two bits defined. If bit A is set
analog access is supported. If bit D is set, digital access
supported
Townsley, et al. Standards Track [Page 21]
RFC 2661 L2TP August 1999
An LNS should not request an outgoing call specifying a value
the Bearer Type AVP for a device type not advertised in the
Capabilities AVP it received from the LAC during
connection establishment. Attempts to do so will result in
call being rejected
This AVP MUST be present if the sender can place outgoing
when requested
Note that an LNS that cannot act as an LAC as well will
support hardware devices for handling incoming and outgoing
and should therefore set the A and D bits of this AVP to 0,
should not send the AVP at all. An LNS that can also act as an
and place outgoing calls should set A or D as appropriate
Presence of this message is not a guarantee that a given
call will be placed by the sender if requested, just that
physical capability exists
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) is 10.
Tie Breaker (SCCRQ
The Tie Breaker AVP, Attribute Type 5, indicates that the
wishes a single tunnel to exist between the given LAC-LNS pair
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tie Break Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...(64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tie Breaker Value is an 8 octet value that is used to choose
single tunnel where both LAC and LNS request a
concurrently. The recipient of a SCCRQ must check to see if
SCCRQ has been sent to the peer, and if so, must compare its
Breaker value with the received one. The lower value "wins",
the "loser" MUST silently discard its tunnel. In the case where
tie breaker is present on both sides, and the value is equal,
sides MUST discard their tunnels
Townsley, et al. Standards Track [Page 22]
RFC 2661 L2TP August 1999
If a tie breaker is received, and an outstanding SCCRQ had no
breaker value, the initiator which included the Tie Breaker
"wins". If neither side issues a tie breaker, then two
tunnels are opened
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit
this AVP MUST be set to 0. The Length of this AVP is 14.
Firmware Revision (SCCRP, SCCRQ
The Firmware Revision AVP, Attribute Type 6, indicates
firmware revision of the issuing device
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Firmware Revision is a 2 octet unsigned integer encoded in
vendor specific format
For devices which do not have a firmware revision (general
computers running L2TP software modules, for instance),
revision of the L2TP software module may be reported instead
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 0. The Length (before hiding) is 8.
Host Name (SCCRP, SCCRQ
The Host Name AVP, Attribute Type 7, indicates the name of
issuing LAC or LNS
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name ... (arbitrary number of octets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Host Name is of arbitrary length, but MUST be at least 1
octet
Townsley, et al. Standards Track [Page 23]
RFC 2661 L2TP August 1999
This name should be as broadly unique as possible; for
participating in DNS [RFC1034], a hostname with fully
domain would be appropriate
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit
this AVP MUST be set to 1. The Length of this AVP is 6 plus
length of the Host Name
Vendor Name (SCCRP, SCCRQ
The Vendor Name AVP, Attribute Type 8, contains a vendor
(possibly human readable) string describing the type of LAC or
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
vendor string. Human readable text for this AVP MUST be
in the UTF-8 charset using the Default Language [RFC2277].
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 0. The Length (before hiding) of this
is 6 plus the length of the Vendor Name
Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN
The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID
assigned to this tunnel by the sender
The Attribute Value field for this AVP has the following format
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Tunnel ID is a 2 octet non-zero unsigned integer
The Assigned Tunnel ID AVP establishes a value used to
and demultiplex multiple tunnels between the LNS and LAC. The L2
peer MUST place this value in the Tunnel ID header field of
Townsley, et al. Standards Track [Page 24]
RFC 2661 L2TP August 1999
control and data messages that it subsequently transmits over
associated tunnel. Before the Assigned Tunnel ID AVP is
from a peer, messages MUST be sent to that peer with a Tunnel
value of 0 in the header of all control messages
In the StopCCN control message, the Assigned Tunnel ID AVP MUST
the same as the Assigned Tunnel ID AVP first sent to the
peer, permitting the peer to identify the appropriate tunnel
if a StopCCN is sent before an Assigned Tunnel ID AVP is received
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 8.
Receive Window Size (SCCRQ, SCCRP
The Receive Window Size AVP, Attribute Type 10, specifies
receive window size being offered to the remote peer
The Attribute Value field for this AVP has the following format
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Window Size is a 2 octet unsigned integer
If absent, the peer must assume a Window Size of 4 for
transmit window. The remote peer may send the specified number
control messages before it must wait for an acknowledgment
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit
this AVP MUST be set to 1. The Length of this AVP is 8.
Challenge (SCCRP, SCCRQ
The Challenge AVP, Attribute Type 11, indicates that the
peer wishes to authenticate the tunnel endpoints using a CHAP
style authentication mechanism
Townsley, et al. Standards Track [Page 25]
RFC 2661 L2TP August 1999
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ... (arbitrary number of octets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is one or more octets of random data
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 6 plus the length of the Challenge
Challenge Response (SCCCN, SCCRP
The Response AVP, Attribute Type 13, provides a response to
challenge received
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a 16 octet value reflecting the CHAP-
[RFC1994] response to the challenge
This AVP MUST be present in an SCCRP or SCCCN if a challenge
received in the preceding SCCRQ or SCCRP. For purposes of the
value in the CHAP response calculation, the value of the
Type AVP for this message is used (e.g. 2 for an SCCRP, and 3
an SCCCN).
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 22.
Townsley, et al. Standards Track [Page 26]
RFC 2661 L2TP August 1999
4.4.4 Call Management
Q.931 Cause Code (CDN
The Q.931 Cause Code AVP, Attribute Type 12, is used to
additional information in case of unsolicited call disconnection
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Msg | Advisory Msg...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code is the returned Q.931 Cause code, and Cause Msg is
returned Q.931 message code (e.g., DISCONNECT) associated with
Cause Code. Both values are returned in their native
encodings [DSS1]. An additional ASCII text Advisory Message
also be included (presence indicated by the AVP Length) to
explain the reason for disconnecting
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit
this AVP MUST be set to 1. The Length of this AVP is 9, plus
size of the Advisory Message
Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ
The Assigned Session ID AVP, Attribute Type 14, encodes the
being assigned to this session by the sender
The Attribute Value field for this AVP has the following format
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Session ID is a 2 octet non-zero unsigned integer
The Assigned Session ID AVP is establishes a value used
multiplex and demultiplex data sent over a tunnel between the
and LAC. The L2TP peer MUST place this value in the Session
header field of all control and data messages that it
transmits over the tunnel that belong to this session. Before
Townsley, et al. Standards Track [Page 27]
RFC 2661 L2TP August 1999
Assigned Session ID AVP is received from a peer, messages MUST
sent to that peer with a Session ID of 0 in the header of
control messages
In the CDN control message, the same Assigned Session ID AVP
sent to the receiving peer is used, permitting the peer
identify the appropriate tunnel even if CDN is sent before
Assigned Session ID is received
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 8.
Call Serial Number (ICRQ, OCRQ
The Call Serial Number AVP, Attribute Type 15, encodes
identifier assigned by the LAC or LNS to this call
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Call Serial Number is a 32 bit value
The Call Serial Number is intended to be an easy reference
administrators on both ends of a tunnel to use when
call failure problems. Call Serial Numbers should be set
progressively increasing values, which are likely to be unique
a significant period of time across all interconnected LNSs
LACs
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 10.
Minimum BPS (OCRQ
The Minimum BPS AVP, Attribute Type 16, encodes the
acceptable line speed for this call
Townsley, et al. Standards Track [Page 28]
RFC 2661 L2TP August 1999
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum BPS is a 32 bit value indicates the speed in bits
second
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 10.
Maximum BPS (OCRQ
The Maximum BPS AVP, Attribute Type 17, encodes the
acceptable line speed for this call
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Maximum BPS is a 32 bit value indicates the speed in bits
second
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 10.
Bearer Type (ICRQ, OCRQ
The Bearer Type AVP, Attribute Type 18, encodes the bearer
for the incoming or outgoing call
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future Bearer Types |A|D
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Townsley, et al. Standards Track [Page 29]
RFC 2661 L2TP August 1999
The Bearer Type is a 32-bit bit mask, which indicates the
capability of the call (ICRQ) or required for the call (OCRQ).
set, bit A indicates that the call refers to an analog channel.
set, bit D indicates that the call refers to a digital channel
Both may be set, indicating that the call was
indistinguishable, or can be placed on either type of channel
Bits in the Value field of this AVP MUST only be set by the
for an OCRQ if it was set in the Bearer Capabilities AVP
from the LAC during control connection establishment
It is valid to set neither the A nor D bits in an ICRQ. Such
setting may indicate that the call was not received over
physical link (e.g if the LAC and PPP are located in the
subsystem).
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 10.
Framing Type (ICCN, OCCN, OCRQ
The Framing Type AVP, Attribute Type 19, encodes the framing
for the incoming or outgoing call
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future Framing Types |A|S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Framing Type is a 32-bit mask, which indicates the type of
framing requested for an OCRQ, or the type of PPP
negotiated for an OCCN or ICCN. The framing type MAY be used as
indication to PPP on the LNS as to what link options to use
LCP negotiation [RFC1662].
Bit A indicates asynchronous framing. Bit S indicates
framing. For an OCRQ, both may be set, indicating that either
of framing may be used
Bits in the Value field of this AVP MUST only be set by the
for an OCRQ if it was set in the Framing Capabilities AVP
from the LAC during control connection establishment
Townsley, et al. Standards Track [Page 30]
RFC 2661 L2TP August 1999
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 10.
Called Number (ICRQ, OCRQ
The Called Number AVP, Attribute Type 21, encodes the
number to be called for an OCRQ, and the Called number for
ICRQ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Called Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Called Number is an ASCII string. Contact between
administrator of the LAC and the LNS may be necessary
coordinate interpretation of the value needed in this AVP
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 6 plus the length of the Called Number
Calling Number (ICRQ
The Calling Number AVP, Attribute Type 22, encodes the
number for the incoming call
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calling Number is an ASCII string. Contact between
administrator of the LAC and the LNS may be necessary
coordinate interpretation of the value in this AVP
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 6 plus the length of the Calling Number
Townsley, et al. Standards Track [Page 31]
RFC 2661 L2TP August 1999
Sub-Address (ICRQ, OCRQ
The Sub-Address AVP, Attribute Type 23, encodes additional
information
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Address ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sub-Address is an ASCII string. Contact between
administrator of the LAC and the LNS may be necessary
coordinate interpretation of the value in this AVP
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 6 plus the length of the Sub-Address
(Tx) Connect Speed (ICCN, OCCN
The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes
speed of the facility chosen for the connection attempt
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The (Tx) Connect Speed BPS is a 4 octet value indicating the
in bits per second
When the optional Rx Connect Speed AVP is present, the value
this AVP represents the transmit connect speed, from
perspective of the LAC (e.g. data flowing from the LAC to
remote system). When the optional Rx Connect Speed AVP is
present, the connection speed between the remote system and LAC
assumed to be symmetric and is represented by the single value
this AVP
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
this AVP MUST be set to 1. The Length (before hiding) of this
is 10.
Townsley, et al. Standards Track [Page 32]
RFC 2661 L2TP August 1999
Rx Connect Speed (ICCN, OCCN
The Rx Connect Speed AVP, Attribute Type 38, represents the
of the connection from the perspective of the LAC (e.g.
flowing from the remote system to the LAC).
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (H) | BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BPS is a 4 octet value indicating the speed in bits per second
Presence of this AVP implies that the connection speed may
asymmetric with respect to the transmit connect speed given in
(Tx) Connect Speed AVP
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit
this AVP MUST be set to 0. The Length (before hiding) of this
is 10.
Physical Channel ID (ICRQ, OCRP
The Physical Channel ID AVP, Attribute Type 25, encodes the
specific physical channel number used for a call
The Attribute Value field for this AVP has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Physical Channel ID is a 4 octet value intended to be used
logging 