Proxy Authen Name
Proxy Authen Challenge
Proxy Authen ID
Proxy Authen Response
Private Group ID
Rx Connect Speed
Sequencing Required
6.9 Outgoing-Call-Request (OCRQ)
Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to
the LAC to indicate that an outbound call from the LAC is to be
established. It is the first in a three message exchange used for
establishing a session within an L2TP tunnel.
OCRQ is used to indicate that a session is to be established between
the LNS and LAC for this call and provides the LAC with parameter
information for both the L2TP session, and the call that is to be
placed
An LNS MUST have received a Bearer Capabilities AVP during tunnel
establishment from an LAC in order to request an outgoing call to
that LAC.
The following AVPs MUST be present in the OCRQ:
Message Type
Assigned Session ID
Call Serial Number
Minimum BPS
Maximum BPS
Bearer Type
Framing Type
Called Number
The following AVPs MAY be present in the OCRQ:
Sub-Address
6.10 Outgoing-Call-Reply (OCRP)
Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to
the LNS in response to a received OCRQ message. It is the second in a
three message exchange used for establishing a session within an L2TP
tunnel.
OCRP is used to indicate that the LAC is able to attempt the outbound
call and returns certain parameters regarding the call attempt.
The following AVPs MUST be present in the OCRP:
Message Type
Assigned Session ID
The following AVPs MAY be present in the OCRP:
Physical Channel ID
6.11 Outgoing-Call-Connected (OCCN)
Outgoing-Call-Connected (OCCN) is a control message sent by the LAC
to the LNS following the OCRP and after the outgoing call has been
completed. It is the final message in a three message exchange used
for establishing a session within an L2TP tunnel.
OCCN is used to indicate that the result of a requested outgoing call
was successful. It also provides information to the LNS about the
particular parameters obtained after the call was established.
The following AVPs MUST be present in the OCCN:
Message Type
(Tx) Connect Speed
Framing Type
The following AVPs MAY be present in the OCCN:
Rx Connect Speed
Sequencing Required
6.12 Call-Disconnect-Notify (CDN)
The Call-Disconnect-Notify (CDN) message is an L2TP control message
sent by either the LAC or LNS to request disconnection of a specific
call within the tunnel. Its purpose is to inform the peer of the
disconnection and the reason why the disconnection occurred. The peer
MUST clean up any resources, and does not send back any indication of
success or failure for such cleanup.
The following AVPs MUST be present in the CDN:
Message Type
Result Code
Assigned Session ID
The following AVPs MAY be present in the CDN:
Q.931 Cause Code
6.13 WAN-Error-Notify (WEN)
The WAN-Error-Notify message is an L2TP control message sent by the
LAC to the LNS to indicate WAN error conditions (conditions that
occur on the interface supporting PPP). The counters in this message
are cumulative. This message should only be sent when an error
occurs, and not more than once every 60 seconds. The counters are
reset when a new call is established.
The following AVPs MUST be present in the WEN:
Message Type
Call Errors
6.14 Set-Link-Info (SLI)
The Set-Link-Info message is an L2TP control message sent by the LNS
to the LAC to set PPP-negotiated options. These options can change
at any time during the life of the call, thus the LAC MUST be able to
update its internal call information and behavior on an active PPP
session.
The following AVPs MUST be present in the SLI:
Message Type
ACCM
7.0 Control Connection State Machines
The control messages defined in section 6 are exchanged by way of
state tables defined in this section. Tables are defined for incoming
call placement, outgoing call placement, as well as for initiation of
the tunnel itself. The state tables do not encode timeout and
retransmission behavior, as this is handled in the underlying
semantics defined in Section 5.8.
7.1 Control Connection Protocol Operation
This section describes the operation of various L2TP control
connection functions and the Control Connection messages which are
used to support them.
Receipt of an invalid or unrecoverable malformed control message
should be logged appropriately and the control connection cleared to
ensure recovery to a known state. The control connection may then be
restarted by the initiator.
An invalid control message is defined as a message which contains a
Message Type that is marked mandatory (see Section 4.4.1) and is
unknown to the implementation, or a control message that is received
in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ).
Examples of a malformed control message include one that has an
invalid value in its header, contains an AVP that is formatted
incorrectly or whose value is out of range, or a message that is
missing a required AVP. A control message with a malformed header
should be discarded. A control message with an invalid AVP should
look to the M-bit for that AVP to determine whether the error is
recoverable or not.
A malformed yet recoverable non-mandatory (M-bit is not set) AVP
within a control message should be treated in a similar manner as an
unrecognized non-mandatory AVP. Thus, if a malformed AVP is received
with the M-bit set, the session or tunnel should be terminated with a
proper Result or Error Code sent. If the M-bit is not set, the AVP
should be ignored (with the exception of logging a local error
message) and the message accepted.
This MUST NOT be considered a license to send malformed AVPs, but
simply a guide towards how to handle an improperly formatted message
if one is received. It is impossible to list all potential
malformations of a given message and give advice for each. That said,
one example of a recoverable, malformed AVP might be if the Rx
Connect Speed AVP, attribute 38, is received with a length of 8
rather than 10 and the BPS given in 2 octets rather than 4. Since the
Rx Connect Speed is non-mandatory, this condition should not be
considered catastrophic. As such, the control message should be
accepted as if the AVP had not been received (with the exception of a
local error message being logged).
In several cases in the following tables, a protocol message is sent,
and then a "clean up" occurs. Note that regardless of the initiator
of the tunnel destruction, the reliable delivery mechanism must be
allowed to run (see Section 5.8) before destroying the tunnel. This
permits the tunnel management messages to be reliably delivered to
the peer.
Appendix B.1 contains an example of lock-step tunnel establishment.
7.2 Control Connection States
The L2TP control connection protocol is not distinguishable between
the LNS and LAC, but is distinguishable between the originator and
receiver. The originating peer is the one which first initiates
establishment of the tunnel (in a tie breaker situation, this is the
winner of the tie). Since either LAC or LNS can be the originator, a
collision can occur. See the Tie Breaker AVP in Section 4.4.3 for a
description of this and its resolution.
7.2.1 Control Connection Establishment
State Event Action New State
----- ----- ------ ---------
idle Local Send SCCRQ wait-ctl-reply
Open request
idle Receive SCCRQ, Send SCCRP wait-ctl-conn
acceptable
idle Receive SCCRQ, Send StopCCN, idle
not acceptable Clean up
idle Receive SCCRP Send StopCCN idle
Clean up
idle Receive SCCCN Clean up idle
wait-ctl-reply Receive SCCRP, Send SCCCN, established
acceptable Send tunnel-open
event to waiting
sessions
wait-ctl-reply Receive SCCRP, Send StopCCN, idle
not acceptable Clean up
wait-ctl-reply Receive SCCRQ, Clean up, idle
lose tie-breaker Re-queue SCCRQ
for idle state
wait-ctl-reply Receive SCCCN Send StopCCN idle
Clean up
wait-ctl-conn Receive SCCCN, Send tunnel-open established
acceptable event to waiting
sessions
wait-ctl-conn Receive SCCCN, Send StopCCN, idle
not acceptable Clean up
wait-ctl-conn Receive SCCRP, Send StopCCN, idle
SCCRQ Clean up
established Local Send tunnel-open established
Open request event to waiting
(new call) sessions
established Admin Send StopCCN idle
Tunnel Close Clean up
established Receive SCCRQ, Send StopCCN idle
SCCRP, SCCCN Clean up
idle Receive StopCCN Clean up idle
wait-ctl-reply,
wait-ctl-conn,
established
The states associated with the LNS or LAC for control connection
establishment are:
idle
Both initiator and recipient start from this state. An initiator
transmits an SCCRQ, while a recipient remains in the idle state
until receiving an SCCRQ.
wait-ctl-reply
The originator checks to see if another connection has been
requested from the same peer, and if so, handles the collision
situation described in Section 5.8.
When an SCCRP is received, it is examined for a compatible
version. If the version of the reply is lower than the version
sent in the request, the older (lower) version should be used
provided it is supported. If the version in the reply is earlier
and supported, the originator moves to the established state. If
the version is earlier and not supported, a StopCCN MUST be sent
to the peer and the originator cleans up and terminates the
tunnel.
wait-ctl-conn
This is where an SCCCN is awaited; upon receipt, the challenge
response is checked. The tunnel either is established, or is torn
down if an authorization failure is detected.
established
An established connection may be terminated by either a local
condition or the receipt of a Stop-Control-Connection-
Notification. In the event of a local termination, the originator
MUST send a Stop-Control-Connection-Notification and clean up the
tunnel.
If the originator receives a Stop-Control-Connection-Notification
it MUST also clean up the tunnel.
7.3 Timing considerations
Due to the real-time nature of telephone signaling, both the LNS and
LAC should be implemented with multi-threaded architectures such that
messages related to multiple calls are not serialized and blocked.
The call and connection state figures do not specify exceptions
caused by timers. These are addressed in Section 5.8.
7.4 Incoming calls
An Incoming-Call-Request message is generated by the LAC when an
incoming call is detected (for example, an associated telephone line
rings). The LAC selects a Session ID and serial number and indicates
the call bearer type. Modems should always indicate analog call type.
ISDN calls should indicate digital when unrestricted digital service
or rate adaption is used and analog if digital modems are involved.
Calling Number, Called Number, and Subaddress may be included in the
message if they are available from the telephone network.
Once the LAC sends the Incoming-Call-Request, it waits for a response
from the LNS but it does not necessarily answer the call from the
telephone network yet. The LNS may choose not to accept the call if:
- No resources are available to handle more sessions
- The dialed, dialing, or subaddress fields do not correspond to
an authorized user
- The bearer service is not authorized or supported
If the LNS chooses to accept the call, it responds with an Incoming-
Call-Reply. When the LAC receives the Incoming-Call-Reply, it
attempts to connect the call. A final call connected message from
the LAC to the LNS indicates that the call states for both the LAC
and the LNS should enter the established state. If the call
terminated before the LNS could accept it, a Call-Disconnect-Notify
is sent by the LAC to indicate this condition.
When the dialed-in client hangs up, the call is cleared normally and
the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to
clear a call, it sends a Call-Disconnect-Notify message and cleans up
its session.
7.4.1 LAC Incoming Call States
State Event Action New State
----- ----- ------ ---------
idle Bearer Ring or Initiate local wait-tunnel
Ready to indicate tunnel open
incoming conn.
idle Receive ICCN, Clean up idle
ICRP, CDN
wait-tunnel Bearer line drop Clean up idle
or local close
request
wait-tunnel tunnel-open Send ICRQ wait-reply
wait-reply Receive ICRP, Send ICCN established
acceptable
wait-reply Receive ICRP, Send CDN, idle
Not acceptable Clean up
wait-reply Receive ICRQ Send CDN idle
Clean up
wait-reply Receive CDN Clean up idle
ICCN
wait-reply Local Send CDN, idle
close request or Clean up
Bearer line drop
established Receive CDN Clean up idle
established Receive ICRQ, Send CDN, idle
ICRP, ICCN Clean up
established Bearer line Send CDN, idle
drop or local Clean up
close request
The states associated with the LAC for incoming calls are:
idle
The LAC detects an incoming call on one of its interfaces.
Typically this means an analog line is ringing or an ISDN TE has
detected an incoming Q.931 SETUP message. The LAC initiates its
tunnel establishment state machine, and moves to a state waiting
for confirmation of the existence of a tunnel.
wait-tunnel
In this state the session is waiting for either the control
connection to be opened or for verification that the tunnel is
already open. Once an indication that the tunnel has/was opened,
session control messages may be exchanged. The first of these is
the Incoming-Call-Request.
wait-reply
The LAC receives either a CDN message indicating the LNS is not
willing to accept the call (general error or don't accept) and
moves back into the idle state, or an Incoming-Call-Reply message
indicating the call is accepted, the LAC sends an Incoming-Call-
Connected message and enters the established state.
established
Data is exchanged over the tunnel. The call may be cleared
following:
+ An event on the connected interface: The LAC sends a Call-
Disconnect-Notify message
+ Receipt of a Call-Disconnect-Notify message: The LAC cleans
up, disconnecting the call.
+ A local reason: The LAC sends a Call-Disconnect-Notify
message.
7.4.2 LNS Incoming Call States
State Event Action New State
----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect
acceptable
idle Receive ICRQ, Send CDN, idle
not acceptable Clean up
idle Receive ICRP Send CDN idle
Clean up
idle Receive ICCN Clean up idle
wait-connect Receive ICCN Prepare for established
acceptable data
wait-connect Receive ICCN Send CDN, idle
not acceptable Clean up
wait-connect Receive ICRQ, Send CDN idle
ICRP Clean up
idle, Receive CDN Clean up idle
wait-connect,
established
wait-connect Local Send CDN, idle
established Close request Clean up
established Receive ICRQ, Send CDN idle
ICRP, ICCN Clean up
The states associated with the LNS for incoming calls are:
idle
An Incoming-Call-Request message is received. If the request is
not acceptable, a Call-Disconnect-Notify is sent back to the LAC
and the LNS remains in the idle state. If the Incoming-Call-
Request message is acceptable, an Incoming-Call-Reply is sent. The
session moves to the wait-connect state.
wait-connect
If the session is still connected on the LAC, the LAC sends an
Incoming-Call-Connected message to the LNS which then moves into
established state. The LAC may send a Call-Disconnect-Notify to
indicate that the incoming caller could not be connected. This
could happen, for example, if a telephone user accidentally places
a standard voice call to an LAC resulting in a handshake failure
on the called modem.
established
The session is terminated either by receipt of a Call-Disconnect-
Notify message from the LAC or by sending a Call-Disconnect-
Notify. Clean up follows on both sides regardless of the
initiator.
7.5 Outgoing calls
Outgoing calls are initiated by an LNS and instruct an LAC to place a
call. There are three messages for outgoing calls: Outgoing-Call-
Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS
sends an Outgoing-Call-Request specifying the dialed party phone
number, subaddress and other parameters. The LAC MUST respond to the
Outgoing-Call-Request message with an Outgoing-Call-Reply message
once the LAC determines that the proper facilities exist to place the
call and the call is administratively authorized. For example, is
this LNS allowed to dial an international call? Once the outbound
call is connected, the LAC sends an Outgoing-Call-Connected message
to the LNS indicating the final result of the call attempt:
7.5.1 LAC Outgoing Call States
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Open bearer
idle Receive OCRQ, Send CDN, idle
not acceptable Clean up
idle Receive OCRP Send CDN idle
Clean up
idle Receive OCCN, Clean up idle
CDN
wait-cs-answer Bearer answer, Send OCCN established
framing detected
wait-cs-answer Bearer failure Send CDN, idle
Clean up
wait-cs-answer Receive OCRQ, Send CDN idle
OCRP, OCCN Clean up
established Receive OCRQ, Send CDN idle
OCRP, OCCN Clean up
wait-cs-answer, Receive CDN Clean up idle
established
established Bearer line drop, Send CDN, idle
Local close Clean up
request
The states associated with the LAC for outgoing calls are:
idle
If Outgoing-Call-Request is received in error, respond with a
Call-Disconnect-Notify. Otherwise, allocate a physical channel and
send an Outgoing-Call-Reply. Place the outbound call and move to
the wait-cs-answer state.
wait-cs-answer
If the call is not completed or a timer expires waiting for the
call to complete, send a Call-Disconnect-Notify with the
appropriate error condition set and go to idle state. If a circuit
switched connection is established and framing is detected, send
an Outgoing-Call-Connected indicating success and go to
established state.
established
If a Call-Disconnect-Notify is received by the LAC, the telco call
MUST be released via appropriate mechanisms and the session
cleaned up. If the call is disconnected by the client or the
called interface, a Call-Disconnect-Notify message MUST be sent to
the LNS. The sender of the Call-Disconnect-Notify message returns
to the idle state after sending of the message is complete.
7.5.2 LNS Outgoing Call States
State Event Action New State
----- ----- ------ ---------
idle Local Initiate local wait-tunnel
open request tunnel-open
idle Receive OCCN, Clean up idle
OCRP, CDN
wait-tunnel tunnel-open Send OCRQ wait-reply
wait-reply Receive OCRP, none wait-connect
acceptable
wait-reply Receive OCRP, Send CDN idle
not acceptable Clean up
wait-reply Receive OCCN, Send CDN idle
OCRQ Clean up
wait-connect Receive OCCN none established
wait-connect Receive OCRQ, Send CDN idle
OCRP Clean up
idle, Receive CDN, Clean up idle
wait-reply,
wait-connect,
established
established Receive OCRQ, Send CDN idle
OCRP, OCCN Clean up
wait-reply, Local Send CDN idle
wait-connect, Close request Clean up
established
wait-tunnel Local Clean up idle
Close request
The states associated with the LNS for outgoing calls are:
idle, wait-tunnel
When an outgoing call is initiated, a tunnel is first created,
much as the idle and wait-tunnel states for an LAC incoming call.
Once a tunnel is established, an Outgoing-Call-Request message is
sent to the LAC and the session moves into the wait-reply state.
wait-reply
If a Call-Disconnect-Notify is received, an error occurred, and
the session is cleaned up and returns to idle. If an Outgoing-
Call-Reply is received, the call is in progress and the session
moves to the wait-connect state.
wait-connect
If a Call-Disconnect-Notify is received, the call failed; the
session is cleaned up and returns to idle. If an Outgoing-Call-
Connected is received, the call has succeeded and the session may
now exchange data.
established
If a Call-Disconnect-Notify is received, the call has been
terminated for the reason indicated in the Result and Cause Codes;
the session moves back to the idle state. If the LNS chooses to
terminate the session, it sends a Call-Disconnect-Notify to the
LAC and then cleans up and idles its session.
7.6 Tunnel Disconnection
The disconnection of a tunnel consists of either peer issuing a
Stop-Control-Connection-Notification. The sender of this Notification
should wait a finite period of time for the acknowledgment of this
message before releasing the control information associated with the
tunnel. The recipient of this Notification should send an
acknowledgment of the Notification and then release the associated
control information.
When to release a tunnel is an implementation issue and is not
specified in this document. A particular implementation may use
whatever policy is appropriate for determining when to release a
control connection. Some implementations may leave a tunnel open for
a period of time or perhaps indefinitely after the last session for
that tunnel is cleared. Others may choose to disconnect the tunnel
immediately after the last user connection on the tunnel disconnects.
8.0 L2TP Over Specific Media
L2TP is self-describing, operating at a level above the media over
which it is carried. However, some details of its connection to media
are required to permit interoperable implementations. The following
sections describe details needed to permit interoperability over
specific media.
8.1 L2TP over UDP/IP
L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP
packet, including payload and L2TP header, is sent within a UDP
datagram. The initiator of an L2TP tunnel picks an available source
UDP port (which may or may not be 1701), and sends to the desired
destination address at port 1701. The recipient picks a free port on
its own system (which may or may not be 1701), and sends its reply to
the initiator's UDP port and address, setting its own source port to
the free port it found. Once the source and destination ports and
addresses are established, they MUST remain static for the life of
the tunnel.
It has been suggested that having the recipient choose an arbitrary
source port (as opposed to using the destination port in the packet
initiating the tunnel, i.e., 1701) may make it more difficult for
L2TP to traverse some NAT devices. Implementors should consider the
potential implication of this before before choosing an arbitrary
source port.
IP fragmentation may occur as the L2TP packet travels over the IP
substrate. L2TP makes no special efforts to optimize this. A LAC
implementation MAY cause its LCP to negotiate for a specific MRU,
which could optimize for LAC environments in which the MTU's of the
path over which the L2TP packets are likely to travel have a
consistent value.
The default for any L2TP implementation is that UDP checksums MUST be
enabled for both control and data messages. An L2TP implementation
MAY provide an option to disable UDP checksums for data messages. It
is recommended that UDP checksums always be enabled on control
packets.
Port 1701 is used for both L2F [RFC2341] and L2TP packets. The
Version field in each header may be used to discriminate between the
two packet types (L2F uses a value of 1, and the L2TP version
described in this document uses a value of 2). An L2TP implementation
running on a system which does not support L2F MUST silently discard
all L2F packets.
To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has
the characteristic of being able to reorder or silently drop packets.
The former may break non-IP protocols being carried by PPP,
especially LAN-centric ones such as bridging. The latter may break
protocols which assume per-packet indication of error, such as TCP
header compression. Sequencing may be handled by using L2TP data
message sequence numbers if any protocol being transported by the PPP
tunnel cannot tolerate reordering. 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 L2TP 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
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/UDP/IP transport is
an unreliable transport. As with any PPP media 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.
8.2 IP
When operating in IP environments, L2TP MUST offer the UDP
encapsulation described in 8.1 as its default configuration for IP
operation. Other configurations (perhaps corresponding to a
compressed header format) MAY be defined and made available as a
configurable option.
9.0 Security Considerations
L2TP encounters several security issues in its operation. The
general approach of L2TP to these issues is documented here.
9.1 Tunnel Endpoint Security
The tunnel endpoints may optionally perform an authentication
procedure of one another during tunnel establishment. This
authentication has the same security attributes as CHAP, and has
reasonable protection against replay and snooping during the tunnel
establishment process. This mechanism is not designed to provide any
authentication beyond tunnel establishment; it is fairly simple for a
malicious user who can snoop the tunnel stream to inject packets once
an authenticated tunnel establishment has been completed
successfully.
For authentication to occur, the LAC and LNS MUST share a single
secret. Each side uses this same secret when acting as authenticatee
as well as authenticator. Since a single secret is used, the tunnel
authentication AVPs include differentiating values in the CHAP ID
fields for each message digest calculation to guard against replay
attacks.
The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3)
SHOULD be selected in an unpredictable manner rather than
sequentially or otherwise. Doing so will help deter hijacking of a
session by a malicious user who does not have access to packet traces
between the LAC and LNS.
9.2 Packet Level Security
Securing L2TP requires that the underlying transport make available
encryption, integrity and authentication services for all L2TP
traffic. This secure transport operates on the entire L2TP packet
and is functionally independent of PPP and the protocol being carried
by PPP. As such, L2TP is only concerned with confidentiality,
authenticity, and integrity of the L2TP packets between its tunnel
endpoints (the LAC and LNS), not unlike link-layer encryption being
concerned only about protecting the confidentiality of traffic
between its physical endpoints.
9.3 End to End Security
Protecting the L2TP packet stream via a secure transport does, in
turn, also protect the data within the tunneled PPP packets while
transported from the LAC to the LNS. Such protection should not be
considered a substitution for end-to-end security between
communicating hosts or applications.
9.4 L2TP and IPsec
When running over IP, IPsec provides packet-level security via ESP
and/or AH. All L2TP control and data packets for a particular tunnel
appear as homogeneous UDP/IP data packets to the IPsec system.
In addition to IP transport security, IPsec defines a mode of
operation that allows tunneling of IP packets. The packet level
encryption and authentication provided by IPsec tunnel mode and that
provided by L2TP secured with IPsec provide an equivalent level of
security for these requirements.
IPsec also defines access control features that are required of a
compliant IPsec implementation. These features allow filtering of
packets based upon network and transport layer characteristics such
as IP address, ports, etc. In the L2TP tunneling model, analogous
filtering is logically performed at the PPP layer or network layer
above L2TP. These network layer access control features may be
handled at the LNS via vendor-specific authorization features based
upon the authenticated PPP user, or at the network layer itself by
using IPsec transport mode end-to-end between the communicating
hosts. The requirements for access control mechanisms are not a part
of the L2TP specification and as such are outside the scope of this
document.
9.5 Proxy PPP Authentication
L2TP defines AVPs that MAY be exchanged during session establishment
to provide forwarding of PPP authentication information obtained at
the LAC to the LNS for validation (see Section 4.4.5). This implies a
direct trust relationship of the LAC on behalf of the LNS. If the
LNS chooses to implement proxy authentication, it MUST be able to be
configured off, requiring a new round a PPP authentication initiated
by the LNS (which may or may not include a new round of LCP
negotiation).
10.0 IANA Considerations
This document defines a number of "magic" numbers to be maintained by
the IANA. This section explains the criteria to be used by the IANA
to assign additional numbers in each of these lists. The following
subsections describe the assignment policy for the namespaces defined
elsewhere in this document.
10.1 AVP Attributes
As defined in Section 4.1, AVPs contain vendor ID, Attribute and
Value fields. For vendor ID value of 0, IANA will maintain a registry
of assigned Attributes and in some case also values. Attributes 0-39
are assigned as defined in Section 4.4. The remaining values are
available for assignment through IETF Consensus [RFC2434].
10.2 Message Type AVP Values
As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0)
have an associated value maintained by IANA. Values 0-16 are defined
in Section 3.2, the remaining values are available for assignment via
IETF Consensus [RFC2434]
10.3 Result Code AVP Values
As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1)
contain three fields. Two of these fields (the Result Code and Error
Code fields) have associated values maintained by IANA.
10.3.1 Result Code Field Values
The Result Code AVP may be included in CDN and StopCCN messages. The
allowable values for the Result Code field of the AVP differ
depending upon the value of the Message Type AVP. For the StopCCN
message, values 0-7 are defined in Section 4.4.2; for the StopCCN
message, values 0-11 are defined in the same section. The remaining
values of the Result Code field for both messages are available for
assignment via IETF Consensus [RFC2434].
10.3.2 Error Code Field Values
Values 0-7 are defined in Section 4.4.2. Values 8-32767 are
available for assignment via IETF Consensus [RFC2434]. The remaining
values of the Error Code field are available for assignment via First
Come First Served [RFC2434].
10.4 Framing Capabilities & Bearer Capabilities
The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in
Section 4.4.3) both contain 32-bit bitmasks. Additional bits should
only be defined via a Standards Action [RFC2434].
10.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 4.4.5, the
remaining values are available for assignment via First Come First
Served [RFC2434].
10.6 AVP Header Bits
There are four remaining reserved bits in the AVP header. Additional
bits should only be assigned via a Standards Action [RFC2434].
11.0 References
[DSS1] ITU-T Recommendation, "Digital subscriber Signaling System
No. 1 (DSS 1) - ISDN user-network interface layer 3
specification for basic call control", Rec. Q.931(I.451),
May 1998
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network
Security: Private Communications in a Public World",
Prentice Hall, March 1995, ISBN 0-13-061466-1
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC791, September
1981.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC1034, November 1987.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC1144, February 1990.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC1661, July 1994.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC1662,
July 1994.
[RFC1663] Rand, D., "PPP Reliable Transmission", RFC1663, July 1994.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC1990,
August 1996.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC1994, August 1996.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC2138,
April 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC2277, January 1998.
[RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
Forwarding (Protocol) L2F", RFC2341, May 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC2434,
October 1998.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
RFC2637, 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
12.0 Acknowledgments
The basic concept for L2TP and many of its protocol constructs were
adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A.
Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein,
J. Taarud, W. Little, and G. Zorn.
Dory Leifer made valuable refinements to the protocol definition of
L2TP and contributed to the editing of this document.
Steve Cobb and Evan Caves redesigned the state machine tables.
Barney Wolff provided a great deal of design input on the endpoint
authentication mechanism.
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 this document.
13.0 Authors' Addresses
Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
EMail: gurdeep@microsoft.com
Bill Palter
RedBack Networks, Inc
1389 Moffett Park Drive
Sunnyvale, CA 94089
EMail: palter@zev.net
Allan Rubens
Ascend Communications
1701 Harbor Bay Parkway
Alameda, CA 94502
EMail: acr@del.com
W. Mark Townsley
cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
EMail: townsley@cisco.com
Andrew J. Valencia
cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: vandys@cisco.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: gwz@acm.org
Appendix A: Control Channel Slow Start and Congestion Avoidance
Although each side has indicated the maximum size of its receive
window, it is recommended that a slow start and congestion avoidance
method be used to transmit control packets. The methods described
here are based upon the TCP congestion avoidance algorithm as
described in section 21.6 of TCP/IP Illustrated, Volume I, by W.
Richard Stevens [STEVENS].
Slow start and congestion avoidance make use of several variables.
The congestion window (CWND) defines the number of packets a sender
may send before waiting for an acknowledgment. The size of CWND
expands and contracts as described below. Note however, that CWND is
never allowed to exceed the size of the advertised window obtained
from the Receive Window AVP (in the text below, it is assumed any
increase will be limited by the Receive Window Size). The variable
SSTHRESH determines when the sender switches from slow start to
congestion avoidance. Slow start is used while CWND is less than
SSHTRESH.
A sender starts out in the slow start phase. CWND is initialized to
one packet, and SSHTRESH is initialized to the advertised window
(obtained from the Receive Window AVP). The sender then transmits
one packet and waits for its acknowledgement (either explicit or
piggybacked). When the acknowledgement is received, the congestion
window is incremented from one to two. During slow start, CWND is
increased by one packet each time an ACK (explicit ZLB or
piggybacked) is received. Increasing CWND by one on each ACK has the
effect of doubling CWND with each round trip, resulting in an
exponential increase. When the value of CWND reaches SSHTRESH, the
slow start phase ends and the congestion avoidance phase begins.
During congestion avoidance, CWND expands more slowly. Specifically,
it increases by 1/CWND for every new ACK received. That is, CWND is
increased by one packet after CWND new ACKs have been received.
Window expansion during the congestion avoidance phase is effectively
linear, with CWND increasing by one packet each round trip.
When congestion occurs (indicated by the triggering of a
retransmission) one half of the CWND is saved in SSTHRESH, and CWND
is set to one. The sender then reenters the slow start phase.
Appendix B: Control Message Examples
B.1: Lock-step tunnel establishment
In this example, an LAC establishes a tunnel, with the exchange
involving each side alternating in sending messages. This example
shows the final acknowledgment explicitly sent within a ZLB ACK
message. An alternative would be to piggyback the acknowledgement
within a message sent as a reply to the ICRQ or OCRQ that will likely
follow from the side that initiated the tunnel.
LAC or LNS LNS or LAC
---------- ----------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ZLB
Nr: 2, Ns: 1
B.2: Lost packet with retransmission
An existing tunnel has a new session requested by the LAC. The ICRP
is lost and must be retransmitted by the LNS. Note that loss of the
ICRP has two impacts: not only does it keep the upper level state
machine from progressing, but it also keeps the LAC from seeing a
timely lower level acknowledgment of its ICRQ.
LAC LNS
--- ---
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(pause; LAC's timer started first, so fires first)
ICRQ ->
Nr: 1, Ns: 2
(Realizing that it has already seen this packet,
the LNS discards the packet and sends a ZLB)
<- ZLB
Nr: 3, Ns: 2
(LNS's retransmit timer fires)
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ZLB
Nr: 4, Ns: 2
Appendix C: Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat."
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.