Network Working Group J. Lau
Internet-Draft M. Townsley
Category: Standards Track A. Valencia
<draft-ietf-l2tpext-l2tp-ppp-01.txt> G. Zorn
cisco Systems
M. Verma
CommWorks, a 3Com company
I. Goyret
Lucent Technologies
G. Pall
Microsoft Corporation
A. Rubens
Nexthop
B. Palter
Redback Networks
November 2001
PPP Tunneling Using Layer Two Tunneling Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress''.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-l2tpext-l2tp-ppp-01.txt> and expires May 2002. Please send
comments to the L2TP mailing list (l2tp@l2tp.net).
Copyright Notice
Townsley, et al. Standards Track [Page 1]
INTERNET DRAFT L2TP November 2001
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document describes the use of Layer Two Tunneling Protocol
(L2TP) to tunnel PPP packets.
Townsley, et al. Standards Track [Page 2]
INTERNET DRAFT L2TP November 2001
Contents
Status of this Memo.......................................... 1
1. Introduction.............................................. 3
1.1 Specification of Requirements......................... 4
1.2 Terminology........................................... 4
2. Topology.................................................. 5
3. Control Channel Specifics for PPP......................... 5
4. Data Channel Specifics for PPP............................ 6
4.1 PPP-Specific Sublayer................................. 6
4.2 Forwarding PPP Frames................................. 7
5. AVP Description........................................... 7
5.1 PPP-Specific AVPs..................................... 8
5.1.1 Control Connection Management AVPs............... 8
5.1.2 Call Management AVPs............................. 9
5.1.3 Proxy LCP and Authentication AVPs................ 13
5.1.4 Call Status AVPs................................. 17
5.2 Service Type Independent AVPs......................... 18
6. Data Channel Sequencing................................... 19
6.1 Sequence Numbers...................................... 19
6.2 Data Channel Sequencing over Specific Media........... 20
7. IANA Considerations....................................... 21
7.1 AVP Attributes........................................ 21
7.2 SLI Message Type...................................... 21
7.3 Framing Capabilities and Bearer Capabilities.......... 21
7.4 Framing Type and Bearer Type.......................... 21
7.5 Proxy Authen Type AVP Values.......................... 22
7.6 PPP Sublayer Header Bits.............................. 22
8. References................................................ 22
9. Acknowledgments........................................... 23
10. Authors' Addresses....................................... 24
1. Introduction
The Point-to-Point Protocol (PPP) is a data link layer protocol that
provides a standard method for carrying multiprotocol packets across
point-to-point links. It is the most commonly used protocol to
provide remote access over various access media such as dial-up POTS,
Townsley, et al. Standards Track [Page 3]
INTERNET DRAFT L2TP November 2001
ISDN, ADSL, etc.
Typically, a user obtains a Layer 2 (L2) connection to a Network
Access Server (NAS) using one of a number of techniques (e.g. dial-up
POTS, ISDN, ADSL, etc.), then runs PPP over that connection. In such
a configuration, the L2 termination point and PPP session endpoint
reside on the same physical device (i.e. the NAS).
Tunneling protocols, such as the Layer Two Tunneling Protocol defined
in [L2TP], extend PPP by allowing the L2 and PPP endpoints to reside
on different devices that are interconnected by a network. This
separation allows the actual processing of PPP packets to be divorced
from the termination of the L2 circuit.
This document defines the specific mechanisms for tunneling of PPP
using L2TP.
This is a companion document to be read in conjunction with [L2TP].
A large part of this document is derived from [RFC2661], which
describes the L2TP protocol signaling as well as the encapsulation
method to tunnel PPP sessions. This document is a result of the
rewriting of [RFC2661] to separate the base L2TP protocol from the
PPP tunneling details.
1.1 Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2 Terminology
This document uses terminology defined in [L2TP]. Additional
terminology is defined here.
Called Number
The telephone number dialed by a caller to reach the receiver of
the call.
Calling Number
The telephone number of the caller.
CHAP
Challenge Handshake Authentication Protocol [RFC1994], a point-to-
point cryptographic challenge/response authentication protocol in
Townsley, et al. Standards Track [Page 4]
INTERNET DRAFT L2TP November 2001
which the cleartext password is not passed over the line.
DSLAM
Digital Subscriber Line (DSL) Access Module. A network device
used in the deployment of DSL service. This is typically a
concentrator of individual DSL lines located in a central office
(CO) or local exchange.
Network Access Server (NAS)
A device providing local network access to users across a remote
access network, such as the PSTN.
POTS
Plain Old Telephone Service.
2. Topology
Although PPP tunneling can be deployed in all of the different
tunneling models specified in [L2TP], it is most commonly deployed in
the LAC-LNS reference model. The LAC physically terminates the L2
connection and tunnels the PPP packets to the LNS. The LNS then
terminates the logical PPP connection.
3. Control Channel Specifics for PPP
When PPP is tunneled through L2TP, a session control message, Set-
Link-Info (SLI), is used to send PPP-specific link level information
from the LNS to the LAC.
The SLI is sent by the LNS to the LAC to set any PPP-negotiated
options. It is sent after the last LCP CONFACK is received during
PPP LCP negotiation. This AVP contains any relevant link level
parameters of which the LAC may need to be aware (e.g. ACCM info).
If there is no relevant information to be sent in the SLI, then the
sending of this message MAY be omitted. Since LCP may be
renegotiated at any time, an SLI may be sent at any time during the
life of the call. For this reason, the LAC MUST be able to update
its internal call information and behavior on an active session.
Furthermore, if there are packets in queue at the LAC when an SLI is
received, these must be flushed before applying the SLI information
to the link.
If the PPP session at the LNS renegotiates LCP during the call, an
SLI MUST be sent to the LAC to return link level information to the
initial default values while the negotiation occurs. However, if the
Townsley, et al. Standards Track [Page 5]
INTERNET DRAFT L2TP November 2001
last SLI sent was already set to default values or no SLI was sent at
all, this step MAY be omitted.
The following AVPs MUST be present in the SLI:
Message Type
This AVP is described in [L2TP]. In the SLI, the value of this
attribute is 16.
ACCM
This AVP is described in Section 5.1.4.
4. Data Channel Specifics for PPP
This section describes the encapsulation mechanism for forwarding PPP
frames over the L2TP data channel.
4.1 PPP-Specific Sublayer
According to the base L2TP specification [L2TP], the header format for
the data messages consists of a fixed header followed by a L2-specific
sublayer. The PPP sublayer is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|S|x|x| OffSz | Reserved | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset padding... (optional, up to 15 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4.1: PPP Sublayer in L2TP Data Message Header
If the Priority (P) bit is 1, this data message should receive
preferential treatment in its local queuing and transmission.
If the Sequence (S) bit is 1, it indicates that the Sequence Number
field has meaningful data and that the receiver of this data packet
should interpret it accordingly.
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 Offset Size (OffSz) field specifies the number of octets past the
PPP sublayer header at which the payload data is expected to start.
Townsley, et al. Standards Track [Page 6]
INTERNET DRAFT L2TP November 2001
An Offset Size of 0 indicates no offset. Otherwise, the PPP sublayer
header ends after the last octet of the Offset Padding. The maximum
offset value that may be specified is 15 octets.
The Sequence Number field indicates the sequence number for this data
message, beginning at zero and incrementing by one (modulo 2**16) for
each message sent. See Section 6.1 for more information on using
this field.
The minimum length for the PPP sublayer is 4 octets (corresponding to
an Offset Size of 0).
4.2 Forwarding PPP Frames
PPP tunneling via L2TP utilizes both the control connection for
session management and the base L2TP encapsulation to tunnel the PPP
frames. Both of these mechanisms are defined in [L2TP].
After L2TP control channel establishment (see [L2TP] for details on
control channel establishment), PPP frames are tunneled.
The PPP frames from the remote system are received at the LAC,
stripped of CRC, link framing, and transparency bytes, encapsulated
with the PPP sublayer header followed by the fixed L2TP data header
[L2TP], and forwarded over the session. The LNS receives the L2TP
packet and processes the encapsulated PPP frame as if it were
received on a local PPP interface. The LNS assumes the operation of
PPP over HDLC and performs the HDLC Address and Control field
processing for PPP frames. Besides this HDLC processing, all other
framing operations (e.g. CRC, character escaping, etc.) are handled
by the LAC.
When encapsulating the PPP frame in L2TP, both the LAC and the LNS
MUST always include the HDLC header (Address and Control fields) as
well as the PPP Protocol ID fields along with the PPP frame. This
implies that the LNS MUST always reject the Address and Control Field
Compression (ACFC) as well as the Protocol Field Compression (PFC)
LCP options. For non-HDLC connections between the LAC and the remote
systems, the LAC MUST translate the addressing method to HDLC
addressing.
5. AVP Description
The base L2TP specification [L2TP] describes the use of service type
specific Attribute Value Pairs (AVPs). These AVPs are specific to
the L2 payload carried by the L2TP sessions. This section provides a
description of all PPP-specific AVPs. It also provides additional
PPP-specific information about certain other service-independent AVPs
Townsley, et al. Standards Track [Page 7]
INTERNET DRAFT L2TP November 2001
when PPP is tunneled by L2TP.
Following the name of each AVP is a list indicating the message types
that utilize each AVP. These message types are described in the base
L2TP specification [L2TP]. 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.1 PPP-Specific AVPs
5.1.1 Control Connection Management AVPs
The AVPs described in this section are included in the control
connection messages.
Framing Capabilities (SCCRP, SCCRQ)
The Framing Capabilities AVP, Attribute Type 3, provides the peer
with an indication of the types of PPP framing that will be supported
for outgoing call requests.
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 is set,
synchronous framing is supported.
The framing capabilities defined in this AVP refer only to the
physical interfaces available for dialout usage on an LAC. An LNS
MUST not send an OCRQ with a Framing Type AVP specifying a value not
advertised in this AVP. Presence of this message is not a guarantee
that a given outgoing call will be placed by the sender if requested,
just that the physical capability exists.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for 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 peer with
an indication of the bearer device types supported by the hardware
Townsley, et al. Standards Track [Page 8]
INTERNET DRAFT L2TP November 2001
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 |V|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 is
supported. If bit V is set, virtual access is supported. (Virtual
access refers to access in which there is no physical point-to-point
link.)
The bearer capabilities defined in this AVP refer only to the
physical interfaces available for dialout usage on an LAC. An LNS
MUST not send an OCRQ with a Bearer Type AVP specifying a value not
advertised in this AVP.
This AVP MUST be present if the sender can place outgoing calls when
requested. Presence of this message is not a guarantee that a given
outgoing call will be placed by the sender if requested, just that
the physical capability exists.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP MUST be set to 1. The Length (before hiding) is 10.
5.1.2 Call Management AVPs
Bearer Type (ICRQ, OCRQ)
The Bearer Type AVP, Attribute Type 18, encodes the bearer type 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 |V|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Bearer Type is a 32-bit bit mask indicating the bearer capability
of the call (ICRQ) or required for the call (OCRQ). Bit A refers to
an analog channel. Bit D refers to a digital channel. Bit V
(virtual) refers to a channel for which there is no physical point-
Townsley, et al. Standards Track [Page 9]
INTERNET DRAFT L2TP November 2001
to-point link.
Bits set in the Bearer Type AVP in an OCRQ message indicate the
bearer type(s) on which an outgoing call may be placed. If more than
one bit is set, the LAC may choose the bearer type with which to
place the call. If no bits are set, any type of available channel
may be used.
Bits in the Value field of this AVP MUST only be set by the LNS for
an OCRQ if the same bit was set in the Bearer Capabilities AVP
received from the LAC during control connection establishment.
Bits set in the Bearer Type AVP in an ICRQ message indicate the
bearer type on which an incoming call was received at the LAC. If no
bits are set in an ICRQ, then it is assumed that the bearer type was
indeterminable.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
Framing Type (ICCN, OCCN, OCRQ)
The Framing Type AVP, Attribute Type 19, encodes the framing type 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 PPP
framing requested for an OCRQ, or the type of PPP framing negotiated
for an OCCN or ICCN.
Bit A indicates asynchronous framing. Bit S indicates synchronous
framing. For an OCRQ, both may be set, indicating that the LAC may
decide the type of framing to be used.
For an ICRQ, only one framing type bit may be set. The framing type
SHOULD be used as an indication to PPP on the LNS as to what link
options to use for LCP negotiation [RFC1662]. For example, if the A
bit is not set in the Framing Type AVP in an ICRQ message and an ACCM
LCP option is requested by the PPP client, then the LNS should try to
respond with no bits set in the ACCM mask, since the LAC will not
likely perform async mapping on a non-async interface. Similarly, if
Townsley, et al. Standards Track [Page 10]
INTERNET DRAFT L2TP November 2001
the S bit is set, PPP may wish to reject address field compression
and protocol field compression options.
Bits in the Value field of this AVP MUST only be set by the LNS for
an OCRQ if it was set in the Framing Capabilities AVP received from
the LAC during control connection establishment.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
Called Number (ICRQ, OCRQ)
The Called Number AVP, Attribute Type 21, encodes the telephone
number to be called for an OCRQ, and the called number for an 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 the
administrator of the LAC and the LNS may be necessary to 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 for this
AVP MUST be set to 1. The Length (before hiding) of this AVP is 6
plus the length of the Called Number.
Calling Number (ICRQ)
The Calling Number AVP, Attribute Type 22, encodes the originating
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Calling Number is an ASCII string. Contact between the
administrator of the LAC and the LNS may be necessary to coordinate
interpretation of the value in this AVP.
Townsley, et al. Standards Track [Page 11]
INTERNET DRAFT L2TP November 2001
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP MUST be set to 1. The Length (before hiding) of this AVP is 6
plus the length of the Calling Number.
Sub-Address (ICRQ, OCRQ)
The Sub-Address AVP, Attribute Type 23, encodes additional dialing
information. For instance, it can be used by the LNS to encode the
ISDN sub-address information for an outgoing call request.
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 the
administrator of the LAC and the LNS may be necessary to coordinate
interpretation of the value in this AVP.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP MUST be set to 1. The Length (before hiding) of this AVP is 6
plus the length of the Sub-Address.
Q.931 Cause Code (CDN)
The Q.931 Cause Code AVP, Attribute Type 12, is used to give
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Cause Code field is the returned Q.931 cause code, and the Cause
Msg field is the returned Q.931 message code (e.g., DISCONNECT)
associated with the cause code. Both values are returned in their
native ITU encodings [DSS1]. An additional ASCII text Advisory
Message may also be included (presence indicated by the AVP Length)
to further explain the reason for disconnecting.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP MUST be set to 1. The Length of this AVP is 9, plus the
Townsley, et al. Standards Track [Page 12]
INTERNET DRAFT L2TP November 2001
size of the Advisory Message.
Sequencing Required (ICCN, OCCN, ICRP, OCRQ)
The Sequencing Required AVP, Attribute Type 39, indicates to the peer
that Sequence Numbers MUST always be present on the data channel.
This AVP has no Attribute Value field.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP MUST be set to 1. The Length of this AVP is 6.
5.1.3 Proxy LCP and Authentication AVPs
The LAC may have answered the call and negotiated LCP with the remote
system, perhaps in order to establish the system's apparent identity.
In this case, these AVPs may be included to indicate, first, the link
properties the remote system initially requested, and second, the
properties the remote system and LAC ultimately negotiated. In
addition, the authentication information can be sent by the LAC by
including the proxy authentication AVPs. This information may be
used to initiate the PPP LCP and authentication states on the LNS,
allowing PPP to continue without renegotiation of LCP. Note that the
LNS policy may be to enter an additional round of LCP negotiation
and/or authentication if the LAC is not trusted.
Initial Received LCP CONFREQ (ICCN)
In the Initial Received LCP CONFREQ AVP, Attribute Type 26, the LAC
provides the LNS with the Initial CONFREQ received by the LAC from
the PPP Peer.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LCP CONFREQ is a copy of the body of the initial CONFREQ
received, starting at the first option within the body of the LCP
message.
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 (before hiding) of this AVP is 6
plus the length of the CONFREQ.
Townsley, et al. Standards Track [Page 13]
INTERNET DRAFT L2TP November 2001
Last Sent LCP CONFREQ (ICCN)
In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the LNS
with the Last CONFREQ sent by the LAC to the PPP Peer.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LCP CONFREQ is a copy of the body of the final CONFREQ sent to
the client to complete LCP negotiation, starting at the first option
within the body of the LCP message.
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 (before hiding) of this AVP is 6
plus the length of the CONFREQ.
Last Received LCP CONFREQ (ICCN)
The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the
LNS with the Last CONFREQ received by the LAC from the PPP Peer.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LCP CONFREQ is a copy of the body of the final CONFREQ received
from the client to complete LCP negotiation, starting at the first
option within the body of the LCP message.
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 (before hiding) of this AVP is 6
plus the length of the CONFREQ.
Proxy Authen Type (ICCN)
The Proxy Authen Type AVP, Attribute Type 29, indicates the type of
authentication that was performed for this call by the LAC, if any.
The Attribute Value field for this AVP has the following format:
Townsley, et al. Standards Track [Page 14]
INTERNET DRAFT L2TP November 2001
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authen Type is a 2-octet unsigned integer.
Defined Authen Type values are:
0 - Reserved
1 - Textual username/password exchange
2 - PPP CHAP
3 - PPP PAP
4 - No authentication
5 - Microsoft CHAP Version 1 (MSCHAPv1)
TBA - Microsoft CHAP Version 2 (MSCHAPv2)
TBA - PPP EAP
TBA - Others
This AVP MUST be present if proxy authentication is to be utilized.
If it is not present, then it is assumed that this peer cannot
perform proxy authentication. In this case, a restart of the
authentication phase at the LNS is required if the client has already
entered this phase with the LAC (which may be determined by the
presence of the Proxy LCP AVP).
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 (before hiding) of this AVP is 8.
Associated AVPs for each type of authentication follow.
Proxy Authen Name (ICCN)
The Proxy Authen Name AVP, Attribute Type 30, specifies the name of
the authenticating client when using proxy 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Name... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authen Name is a string of octets of arbitrary length. It contains
the name specified in the client's authentication response.
This AVP MUST be present in messages containing a Proxy Authen Type
Townsley, et al. Standards Track [Page 15]
INTERNET DRAFT L2TP November 2001
AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable to
employ AVP hiding for obscuring the cleartext name.
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 (before hiding) is 6 plus the
length of the cleartext name.
Proxy Authen Challenge (ICCN)
The Proxy Authen Challenge AVP, Attribute Type 31, specifies the
challenge sent by the LAC to the PPP Peer when using proxy
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is a string of one or more octets.
This AVP MUST be present for Proxy Authen Types 2 and 5. The
Challenge field contains the CHAP challenge presented to the client
by the LAC.
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 (before hiding) of this AVP is 6,
plus the length of the Challenge.
Proxy Authen ID (ICCN)
The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value of
the PPP Authentication that was started between the LAC and the PPP
Peer when proxy authentication is being used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID is a 2-octet unsigned integer. The most significant octet MUST be
0.
Townsley, et al. Standards Track [Page 16]
INTERNET DRAFT L2TP November 2001
The Proxy Authen ID AVP MUST be present for Proxy Authen Types 2, 3
and 5. For 2 and 5, the ID field contains the byte ID value
presented to the client by the LAC in its Challenge. For 3, it is
the Identifier value of the Authenticate-Request.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP MUST be set to 0.
Proxy Authen Response (ICCN)
The Proxy Authen Response AVP, Attribute Type 33, specifies the PPP
Authentication response received by the LAC from the PPP Peer, when
proxy authentication is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a string of octets.
This AVP MUST be present for Proxy Authen Types 1, 2, 3 and 5. The
Response field contains the client's response to the challenge. For
Proxy Authen Types 2 and 5, this field contains the response value
received by the LAC. For 1 and 3, it contains the cleartext password
received from the client by the LAC. In the case of cleartext
passwords, AVP hiding is recommended.
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 (before hiding) of this AVP is 6
plus the length of the Response.
5.1.4 Call Status AVPs
ACCM (SLI)
The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC of
the ACCM negotiated with the PPP Peer by the LNS.
The Attribute Value field for this AVP has the following format:
Townsley, et al. Standards Track [Page 17]
INTERNET DRAFT L2TP November 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Send ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM (L) | Receive ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Send ACCM and Receive ACCM fields are 4-octet values preceded by
a 2-octet reserved quantity. The Send ACCM value should be used by
the LAC to process packets it sends on the connection. The Receive
ACCM value should be used by the LAC to process incoming packets on
the connection. The default values used by the LAC for both these
fields are 0xFFFFFFFF. The LAC should honor these fields unless it
has specific configuration information to indicate that the requested
mask must be modified to permit operation.
This AVP may be hidden (the H bit MAY be 1 or 0). The M bit for this
AVP MUST be set to 1. The Length of this AVP is 16.
5.2 Service Type Independent AVPs
The base L2TP specification [L2TP] gives a detailed description of
these AVPs. However, the AVP values described in [L2TP] should be
interpreted differently for different service type payloads carried
by L2TP. This section describes the AVP values in the context of PPP
payload. This section should be read in conjunction with the
relevant sections from [L2TP].
Minimum BPS (OCRQ)
The Minimum BPS AVP, Attribute Type 16, encodes the lowest acceptable
line speed for this call over a dial-up network. This is the lowest
acceptable line speed in the transmit direction (i.e. the direction
from the LAC to the user).
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 indicating the speed in bits per
second.
Townsley, et al. Standards Track [Page 18]
INTERNET DRAFT L2TP November 2001
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
Maximum BPS (OCRQ)
The Maximum BPS AVP, Attribute Type 17, encodes the highest
acceptable line speed for this call in the transmit direction (i.e.
from LAC to the user).
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 indicating the speed in bits per
second. This speed is the line speed (for example, modem connect
speed) in the transmit direction.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
6. Data Channel Sequencing
This section describes the method for using sequence numbers on the
L2TP data plane carrying PPP frames. It also provides guidelines on
when to use these sequence numbers.
6.1 Sequence Numbers
The Sequence Number field defined in the PPP sublayer header allows
an LCCE to convey sequence information to a peer. Unlike the L2TP
control plane, the L2TP data plane carrying PPP frames does not use
sequencing to retransmit lost data messages. Rather, sequencing may
be used to detect lost packets and/or restore the original sequence
of packets that may have been reordered during traversal of the
packet network.
The sequence number 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 2**16. 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**16 - 1)
values, inclusive. For example, if the last received sequence number
was 15, then messages with sequence numbers 0 through 15, as well as
Townsley, et al. Standards Track [Page 19]
INTERNET DRAFT L2TP November 2001
32784 through 65535, would be considered less than or equal.
Usage of this field is a matter of local policy for each LCCE. An
LCCE SHOULD update the Sequence Number field in the manner described
above for outgoing packets. If an LCCE chooses to update the Sequence
Number field for outgoing packets, it MUST set the Sequence bit in
the PPP sublayer header to 1 (see Section 4.1). In the other
direction, an LCCE may choose to honor the sequence numbers received
in incoming messages. The precise mechanism for dealing with
reordered or lost packets is also a matter of local policy.
Alternatively, an LCCE may choose to ignore sequence numbers
altogether.
One LCCE may convey to its peer that the Sequence Number field will
be honored for incoming data messages by sending the Sequencing
Required AVP. If this AVP is sent during session establishment, it
is recommended that the peer update the Sequence Number field in the
manner described above.
6.2 Data Channel Sequencing over Specific Media
When PPP frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP
data channel to the PPP client, this link has the characteristic of
being able to reorder or silently drop packets. Reordering may break
non-IP protocols being carried by PPP, especially LAN-centric ones
such as bridging. Silent dropping of packets may break protocols
that assume per-packet indication of error, such as TCP header
compression.
If any protocol being transported by PPP over these L2TP data
channels cannot tolerate reordering, sequencing may be turned on by
using the sequence number field in the PPP sublayer header. The
sequence dependency characteristics of individual protocols are
outside the scope of this document.
Allowing packets to be dropped silently is perhaps more problematic
with some protocols. If PPP reliable delivery [RFC1663] is enabled,
no upper PPP protocol will encounter lost packets. If sequence
numbers are enabled, L2TP can detect the packet loss. In the case of
an LNS, the PPP and L2TP stacks are both present within the LNS, and
packet loss signaling may occur precisely as if a packet was received
with a CRC error. Where the LAC and PPP stack are co-resident, this
technique also applies. Where the LAC and PPP client are physically
distinct, the analogous signaling MAY be accomplished by sending a
packet with a CRC error to the PPP client. Note that this would
greatly increase the complexity of debugging client line problems,
since the client statistics could not distinguish between true media
errors and LAC-initiated ones. Further, this technique is not
Townsley, et al. Standards Track [Page 20]
INTERNET DRAFT L2TP November 2001
possible on all hardware.
If VJ compression is used, and neither PPP reliable delivery nor
sequence numbers are enabled, each lost packet results in a 1 in
2**16 chance of a TCP segment being forwarded with incorrect contents
[RFC1144]. Where the combination of the packet loss rate with this
statistical exposure is unacceptable, TCP header compression SHOULD
NOT be used.
In general, it is wise to remember that the L2TP-over-IP as well as
the L2TP-over-UDP/IP transports are unreliable transport media. As
with any PPP medium that is subject to loss, care should be taken
when using protocols that are particularly loss-sensitive. Such
protocols include compression and encryption protocols that employ
history.
7. IANA Considerations
This document defines "magic" numbers to be maintained by the IANA.
This section explains the criteria to be used by the IANA to assign
additional numbers in each of these lists. The following subsections
describe the assignment policy for the namespaces defined elsewhere
in this document.
7.1 AVP Attributes
As defined in [L2TP], AVPs contain Vendor ID, Attribute, and Value
fields. For a Vendor ID value of 0, IANA will maintain a registry of
assigned Attributes for PPP-specific AVPs described in Section 3.1,
and in some cases, values for those attributes.
7.2 SLI Message Type
Section 3 of this document defines the value 16 for the SLI message
type. This value will be maintained by the IANA.
7.3 Framing Capabilities and Bearer Capabilities
The Framing Capabilities AVP and Bearer Capabilities AVP (defined in
Section 5.1) both contain 32-bit bitmasks. Additional bits should
only be defined via a Standards Action [RFC 2434].
7.4 Framing Type and Bearer Type
The Framing Type AVP and Bearer Type AVP (defined in Section 5.1)
both contain 32-bit bitmasks. Additional bits should only be defined
via a Standards Action [RFC 2434].
Townsley, et al. Standards Track [Page 21]
INTERNET DRAFT L2TP November 2001
7.5 Proxy Authen Type AVP Values
The Proxy Authen Type AVP (Attribute Type 29) has an associated value
maintained by IANA. Values 0-5 are defined in Section 5.1, the
remaining values are available for assignment upon Expert Review [RFC
2434].
7.6 PPP Sublayer Header Bits
There are three remaining reserved bits in the PPP Sublayer header.
Additional bits should only be assigned via a Standards Action [RFC
2434].
8. References
[L2TP] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, G. Singh
Pall, A. Rubens, B. Palter, "Layer Two Tunneling Protocol (L2TP)",
<draft-ietf-l2tpext-l2tp-base-00.txt>, July 2001
[RFC2661] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall,
G. Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)",
RFC 2661, August 1999
[DSS1] ITU-T Recommendation, "Digital subscriber Signaling System
No. 1 (DSS 1) - ISDN user-network interface layer 3
specification for basic call control", Rec. Q.931(I.451),
May 1998
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network
Security: Private Communications in a Public World",
Prentice Hall, March 1995, ISBN 0-13-061466-1
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
Townsley, et al. Standards Track [Page 22]
INTERNET DRAFT L2TP November 2001
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
August 1996.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138,
April 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
RFC 2637, July 1999.
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The
Protocols", Addison-Wesley Publishing Company, Inc., March
1996, ISBN 0-201-63346-9
9. Acknowledgments
The basic concept for L2TP and many of its protocol constructs were
adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these are
A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W.
Townsley, et al. Standards Track [Page 23]
INTERNET DRAFT L2TP November 2001
Verthein, J. Taarud, W. Little, and G. Zorn.
The L2TP rewrite team for splitting RFC2661 into the base and
companion PPP specifications consisted of Ignacio Goyret, Jed Lau,
Bill Palter, Mark Townsley, and Madhvi Verma.
This document was based upon RFC2661, for which a number of people
provided valuable input and effort.
John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege,
Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and
review at the 43rd IETF in Orlando, FL., which led to improvement of
the overall readability and clarity of RFC2661.
Thomas Narten provided a great deal of critical review, formatting,
and wrote the IANA Considerations section.
Dory Leifer made valuable refinements to the protocol definition of
L2TP and contributed to the editing of early drafts leading to
RFC2661.
Steve Cobb and Evan Caves redesigned the state machine tables.
Barney Wolff provided a great deal of design input on the endpoint
authentication mechanism.
10. Authors' Addresses
Ignacio Goyret
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA 94502
Email: igoyret@lucent.com
Jed Lau
cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
Email: jedlau@cisco.com
Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
Email: gurdeep@microsoft.com
Townsley, et al. Standards Track [Page 24]
INTERNET DRAFT L2TP November 2001
Bill Palter
RedBack Networks, Inc
1389 Moffett Park Drive
Sunnyvale, CA 94089
Email: palter@zev.net
Allan Rubens
Email: acr@del.com
W. Mark Townsley
cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
Email: mark@townsley.net
Andrew J. Valencia
P.O. Box 2928
Vashon, WA 98070
Email: vandys@zendo.com
Madhvi Verma
CommWorks, a 3Com company
3800 Golf Road
Rolling Meadows, IL 60008
Email: madhvi_verma@3com.com
Glen Zorn
cisco Systems
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
Email: gwz@cisco.com
Townsley, et al. Standards Track [Page 25]
