tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2661

 
 
 

Layer Two Tunneling Protocol "L2TP"

Part 3 of 4, p. 41 to 69
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 41 
5.0 Protocol Operation

   The necessary setup for tunneling a PPP session with L2TP consists of
   two steps, (1) establishing the Control Connection for a Tunnel, and
   (2) establishing a Session as triggered by an incoming or outgoing
   call request. The Tunnel and corresponding Control Connection MUST be
   established before an incoming or outgoing call is initiated. An L2TP
   Session MUST be established before L2TP can begin to tunnel PPP
   frames. Multiple Sessions may exist across a single Tunnel and
   multiple Tunnels may exist between the same LAC and LNS.

                          +-----+                               +-----+
                          |     |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~|     |
                          | LAC |                               | LNS |
                          |     #######Control Connection########     |
 [Remote]                 |     |                               |     |
 [System]------Call----------*============L2TP Session=============*  |
   PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
                          |     |                               |     |
 [Remote]                 |     |                               |     |
 [System]------Call----------*============L2TP Session=============*  |
   PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
                          |     |                               |     |
                          |     |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|     |
                          +-----+                               +-----+

 Figure 5.1 Tunneling PPP

5.1 Control Connection Establishment

   The Control Connection is the initial connection that must be
   achieved between an LAC and LNS before sessions may be brought up.
   Establishment of the control connection includes securing the
   identity of the peer, as well as identifying the peer's L2TP version,
   framing, and bearer capabilities, etc.

   A three message exchange is utilized to setup the control connection.
   Following is a typical message exchange:

      LAC or LNS  LAC or LNS
      ----------  ----------
      SCCRQ ->
                  <- SCCRP
      SCCCN ->
                  <- ZLB ACK

   The ZLB ACK is sent if there are no further messages waiting in queue
   for that peer.

Top      Up      ToC       Page 42 
5.1.1 Tunnel Authentication

   L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel
   authentication system during control connection establishment. If an
   LAC or LNS wishes to authenticate the identity of the peer it is
   contacting or being contacted by, a Challenge AVP is included in the
   SCCRQ or SCCRP message. If a Challenge AVP is received in an SCCRQ or
   SCCRP, a Challenge Response AVP MUST be sent in the following SCCRP
   or SCCCN, respectively. If the expected response and response
   received from a peer does not match, establishment of the tunnel MUST
   be disallowed.

   To participate in tunnel authentication, a single shared secret MUST
   exist between the LAC and LNS. This is the same shared secret used
   for AVP hiding (see Section 4.3).  See Section 4.4.3 for details on
   construction of the Challenge and Response AVPs.

5.2 Session Establishment

   After successful control connection establishment, individual
   sessions may be created. Each session corresponds to single PPP
   stream between the LAC and LNS. Unlike control connection
   establishment, session establishment is directional with respect to
   the LAC and LNS. The LAC requests the LNS to accept a session for an
   incoming call, and the LNS requests the LAC to accept a session for
   placing an outgoing call.

5.2.1 Incoming Call Establishment

   A three message exchange is employed to setup the session.  Following
   is a typical sequence of events:

      LAC         LNS
      ---         ---
      (Call
       Detected)

      ICRQ ->
               <- ICRP
      ICCN ->
               <- ZLB ACK

   The ZLB ACK is sent if there are no further messages waiting in queue
   for that peer.

Top      Up      ToC       Page 43 
5.2.2 Outgoing Call Establishment

   A three message exchange is employed to setup the session.  Following
   is a typical sequence of events:

      LAC         LNS
      ---         ---
               <- OCRQ
      OCRP ->

      (Perform
       Call
       Operation)

      OCCN ->
               <- ZLB ACK

   The ZLB ACK is sent if there are no further messages waiting in queue
   for that peer.

5.3 Forwarding PPP Frames

   Once tunnel establishment is complete, PPP frames from the remote
   system are received at the LAC, stripped of CRC, link framing, and
   transparency bytes, encapsulated in L2TP, and forwarded over the
   appropriate tunnel. The LNS receives the L2TP packet, and processes
   the encapsulated PPP frame as if it were received on a local PPP
   interface.

   The sender of a message associated with a particular session and
   tunnel places the Session ID and Tunnel ID (specified by its peer) in
   the Session ID and Tunnel ID header for all outgoing messages. In
   this manner, PPP frames are multiplexed and demultiplexed over a
   single tunnel between a given LNS-LAC pair. Multiple tunnels may
   exist between a given LNS-LAC pair, and multiple sessions may exist
   within a tunnel.

   The value of 0 for Session ID and Tunnel ID is special and MUST NOT
   be used as an Assigned Session ID or Assigned Tunnel ID.  For the
   cases where a Session ID has not yet been assigned by the peer (i.e.,
   during establishment of a new session or tunnel), the Session ID
   field MUST be sent as 0, and the Assigned Session ID AVP within the
   message MUST be used to identify the session. Similarly, for cases
   where the Tunnel ID has not yet been assigned from the peer, the
   Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to
   identify the tunnel.

Top      Up      ToC       Page 44 
5.4 Using Sequence Numbers on the Data Channel

   Sequence numbers are defined in the L2TP header for control messages
   and optionally for data messages (see Section 3.1). These are used to
   provide a reliable control message transport (see Section 5.8) and
   optional data message sequencing. Each peer maintains separate
   sequence numbers for the control connection and each individual data
   session within a tunnel.

   Unlike the L2TP control channel, the L2TP data channel does not use
   sequence numbers to retransmit lost data messages. Rather, data
   messages may use sequence numbers to detect lost packets and/or
   restore the original sequence of packets that may have been reordered
   during transport.  The LAC may request that sequence numbers be
   present in data messages via the Sequencing Required AVP (see Section
   4.4.6). If this AVP is present during session setup, sequence numbers
   MUST be present at all times. If this AVP is not present, sequencing
   presence is under control of the LNS. The LNS controls enabling and
   disabling of sequence numbers by sending a data message with or
   without sequence numbers present at any time during the life of a
   session. Thus, if the LAC receives a data message without sequence
   numbers present, it MUST stop sending sequence numbers in future data
   messages. If the LAC receives a data message with sequence numbers
   present, it MUST begin sending sequence numbers in future outgoing
   data messages. If the LNS enables sequencing after disabling it
   earlier in the session, the sequence number state picks up where it
   left off before.

   The LNS may initiate disabling of sequencing at any time during the
   session (including the first data message sent). It is recommended
   that for connections where reordering or packet loss may occur,
   sequence numbers always be enabled during the initial negotiation
   stages of PPP and disabled only when and if the risk is considered
   acceptable. For example, if the PPP session being tunneled is not
   utilizing any stateful compression or encryption protocols and is
   only carrying IP (as determined by the PPP NCPs that are
   established), then the LNS might decide to disable sequencing as IP
   is tolerant to datagram loss and reordering.

5.5 Keepalive (Hello)

   A keepalive mechanism is employed by L2TP in order to differentiate
   tunnel outages from extended periods of no control or data activity
   on a tunnel. This is accomplished by injecting Hello control messages
   (see Section 6.5) after a specified period of time has elapsed since
   the last data or control message was received on a tunnel. As for any
   other control message, if the Hello message is not reliably delivered
   then the tunnel is declared down and is reset. The transport reset

Top      Up      ToC       Page 45 
   mechanism along with the injection of Hello messages ensures that a
   connectivity failure between the LNS and the LAC will be detected at
   both ends of a tunnel.

5.6 Session Teardown

   Session teardown may be initiated by either the LAC or LNS and is
   accomplished by sending a CDN control message. After the last session
   is cleared, the control connection MAY be torn down as well (and
   typically is). Following is an example of a typical control message
   exchange:

      LAC or LNS  LAC or LNS

      CDN ->
      (Clean up)

                  <- ZLB ACK
                     (Clean up)

5.7 Control Connection Teardown

   Control connection teardown may be initiated by either the LAC or LNS
   and is accomplished by sending a single StopCCN control message. The
   receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of
   the message and maintain enough control connection state to properly
   accept StopCCN retransmissions over at least a full retransmission
   cycle (in case the ZLB ACK is lost). The recommended time for a full
   retransmission cycle is 31 seconds (see section 5.8). Following is an
   example of a typical control message exchange:

      LAC or LNS  LAC or LNS

      StopCCN ->
      (Clean up)

                  <- ZLB ACK
                     (Wait)
                     (Clean up)

   An implementation may shut down an entire tunnel and all sessions on
   the tunnel by sending the StopCCN. Thus, it is not necessary to clear
   each session individually when tearing down the whole tunnel.

Top      Up      ToC       Page 46 
5.8 Reliable Delivery of Control Messages

   L2TP provides a lower level reliable transport service for all
   control messages. The Nr and Ns fields of the control message header
   (see section 3.1) belong to this transport.  The upper level
   functions of L2TP are not concerned with retransmission or ordering
   of control messages. The reliable control message is a sliding window
   transport that provides control message retransmission and congestion
   control.  Each peer maintains separate sequence number state for the
   control connection within a tunnel.

   The message sequence number, Ns, begins at 0. Each subsequent message
   is sent with the next increment of the sequence number.  The sequence
   number is thus a free running counter represented modulo 65536. The
   sequence number in the header of a received message is considered
   less than or equal to the last received number if its value lies in
   the range of the last received number and the preceding 32767 values,
   inclusive. For example, if the last received sequence number was 15,
   then messages with sequence numbers 0 through 15, as well as 32784
   through 65535, would be considered less than or equal. Such a message
   would be considered a duplicate of a message already received and
   ignored from processing. However, in order to ensure that all
   messages are acknowledged properly (particularly in the case of a
   lost ZLB ACK message), receipt of duplicate messages MUST be
   acknowledged by the reliable transport. This acknowledgement may
   either piggybacked on a message in queue, or explicitly via a ZLB
   ACK.

   All control messages take up one slot in the control message sequence
   number space, except the ZLB acknowledgement. Thus, Ns is not
   incremented after a ZLB message is sent.

   The last received message number, Nr, is used to acknowledge messages
   received by an L2TP peer. It contains the sequence number of the
   message the peer expects to receive next (e.g. the last Ns of a non-
   ZLB message received plus 1, modulo 65536).  While the Nr in a
   received ZLB is used to flush messages from the local retransmit
   queue (see below), Nr of the next message sent is not be updated by
   the Ns of the ZLB.

   The reliable transport at a receiving peer is responsible for making
   sure that control messages are delivered in order and without
   duplication to the upper level. Messages arriving out of order may be
   queued for in-order delivery when the missing messages are received,
   or they may be discarded requiring a retransmission by the peer.

Top      Up      ToC       Page 47 
   Each tunnel maintains a queue of control messages to be transmitted
   to its peer.  The message at the front of the queue is sent with a
   given Ns value, and is held until a control message arrives from the
   peer in which the Nr field indicates receipt of this message. After a
   period of time (a recommended default is 1 second) passes without
   acknowledgement, the message is retransmitted. The retransmitted
   message contains the same Ns value, but the Nr value MUST be updated
   with the sequence number of the next expected message.

   Each subsequent retransmission of a message MUST employ an
   exponential backoff interval. Thus, if the first retransmission
   occurred after 1 second, the next retransmission should occur after 2
   seconds has elapsed, then 4 seconds, etc. An implementation MAY place
   a cap upon the maximum interval between retransmissions. This cap
   MUST be no less than 8 seconds per retransmission.  If no peer
   response is detected after several retransmissions, (a recommended
   default is 5, but SHOULD be configurable), the tunnel and all
   sessions within MUST be cleared.

   When a tunnel is being shut down for reasons other than loss of
   connectivity, the state and reliable delivery mechanisms MUST be
   maintained and operated for the full retransmission interval after
   the final message exchange has occurred.

   A sliding window mechanism is used for control message transmission.
   Consider two peers A & B. Suppose A specifies a Receive Window Size
   AVP with a value of N in the SCCRQ or SCCRP messages. B is now
   allowed to have up to N outstanding control messages. Once N have
   been sent, it must wait for an acknowledgment that advances the
   window before sending new control messages.  An implementation may
   support a receive window of only 1 (i.e., by sending out a Receive
   Window Size AVP with a value of 1), but MUST accept a window of up to
   4 from its peer (e.g. have the ability to send 4 messages before
   backing off). A value of 0 for the Receive Window Size AVP is
   invalid.

   When retransmitting control messages, a slow start and congestion
   avoidance window adjustment procedure SHOULD be utilized. The
   recommended procedure for this is described in Appendix A.

   A peer MUST NOT withhold acknowledgment of messages as a technique
   for flow controlling control messages.  An L2TP implementation is
   expected to be able to keep up with incoming control messages,
   possibly responding to some with errors reflecting an inability to
   honor the requested action.

   Appendix B contains examples of control message transmission,
   acknowledgement, and retransmission.

Top      Up      ToC       Page 48 
6.0 Control Connection Protocol Specification

   The following control connection messages are used to establish,
   clear and maintain L2TP tunnels. All data is sent in network order
   (high order octets first). Any "reserved" or "empty" fields MUST be
   sent as 0 values to allow for protocol extensibility.

6.1 Start-Control-Connection-Request (SCCRQ)

   Start-Control-Connection-Request (SCCRQ) is a control message used to
   initialize a tunnel between an LNS and an LAC. It is sent by either
   the LAC or the LNS to being the tunnel establishment process.

   The following AVPs MUST be present in the SCCRQ:

      Message Type AVP
      Protocol Version
      Host Name
      Framing Capabilities
      Assigned Tunnel ID

   The Following AVPs MAY be present in the SCCRQ:

      Bearer Capabilities
      Receive Window Size
      Challenge
      Tie Breaker
      Firmware Revision
      Vendor Name

6.2 Start-Control-Connection-Reply (SCCRP)

   Start-Control-Connection-Reply (SCCRP) is a control message sent in
   reply to a received SCCRQ message. SCCRP is used to indicate that the
   SCCRQ was accepted and establishment of the tunnel should continue.

   The following AVPs MUST be present in the SCCRP:

      Message Type
      Protocol Version
      Framing Capabilities
      Host Name
      Assigned Tunnel ID

Top      Up      ToC       Page 49 
   The following AVPs MAY be present in the SCCRP:

      Bearer Capabilities
      Firmware Revision
      Vendor Name
      Receive Window Size
      Challenge
      Challenge Response

6.3 Start-Control-Connection-Connected (SCCCN)

   Start-Control-Connection-Connected (SCCCN) is a control message sent
   in reply to an SCCRP. SCCCN completes the tunnel establishment
   process.

   The following AVP MUST be present in the SCCCN:

      Message Type

   The following AVP MAY be present in the SCCCN:

      Challenge Response

6.4 Stop-Control-Connection-Notification (StopCCN)

   Stop-Control-Connection-Notification (StopCCN) is a control message
   sent by either the LAC or LNS to inform its peer that the tunnel is
   being shutdown and the control connection should be closed. In
   addition, all active sessions are implicitly cleared (without sending
   any explicit call control messages). The reason for issuing this
   request is indicated in the Result Code AVP. There is no explicit
   reply to the message, only the implicit ACK that is received by the
   reliable control message transport layer.

   The following AVPs MUST be present in the StopCCN:

      Message Type
      Assigned Tunnel ID
      Result Code

6.5 Hello (HELLO)

   The Hello (HELLO) message is an L2TP control message sent by either
   peer of a LAC-LNS control connection. This control message is used as
   a "keepalive" for the tunnel.

Top      Up      ToC       Page 50 
   The sending of HELLO messages and the policy for sending them are
   left up to the implementation. A peer MUST NOT expect HELLO messages
   at any time or interval. As with all messages sent on the control
   connection, the receiver will return either a ZLB ACK or an
   (unrelated) message piggybacking the necessary acknowledgement
   information.

   Since a HELLO is a control message, and control messages are reliably
   sent by the lower level transport, this keepalive function operates
   by causing the transport level to reliably deliver a message. If a
   media interruption has occurred, the reliable transport will be
   unable to deliver the HELLO across, and will clean up the tunnel.

   Keepalives for the tunnel MAY be implemented by sending a HELLO if a
   period of time (a recommended default is 60 seconds, but SHOULD be
   configurable) has passed without receiving any message (data or
   control) from the peer.

   HELLO messages are global to the tunnel. The Session ID in a HELLO
   message MUST be 0.

   The Following AVP MUST be present in the HELLO message:

      Message Type

6.6 Incoming-Call-Request (ICRQ)

   Incoming-Call-Request (ICRQ) is a control message sent by the LAC to
   the LNS when an incoming call is detected. It is the first in a three
   message exchange used for establishing a session within an L2TP
   tunnel.

   ICRQ is used to indicate that a session is to be established between
   the LAC and LNS for this call and provides the LNS with parameter
   information for the session.  The LAC may defer answering the call
   until it has received an ICRP from the LNS indicating that the
   session should be established.  This mechanism allows the LNS to
   obtain sufficient information about the call before determining
   whether it should be answered or not. Alternatively, the LAC may
   answer the call, negotiate LCP and PPP authentication, and use the
   information gained to choose the LNS. In this case, the call has
   already been answered by the time the ICRP message is received; the
   LAC simply spoofs the "call indication" and "call answer" steps in
   this case.

Top      Up      ToC       Page 51 
   The following AVPs MUST be present in the ICRQ:

      Message Type
      Assigned Session ID
      Call Serial Number

   The following AVPs MAY be present in the ICRQ:

      Bearer Type
      Physical Channel ID
      Calling Number
      Called Number
      Sub-Address

6.7 Incoming-Call-Reply (ICRP)

   Incoming-Call-Reply (ICRP) is a control message sent by the LNS to
   the LAC in response to a received ICRQ message. It is the second in
   the three message exchange used for establishing sessions within an
   L2TP tunnel.

   ICRP is used to indicate that the ICRQ was successful and for the LAC
   to answer the call if it has not already done so. It also allows the
   LNS to indicate necessary parameters for the L2TP session.

   The following AVPs MUST be present in the ICRP:

      Message Type
      Assigned Session ID

6.8 Incoming-Call-Connected (ICCN)

   Incoming-Call-Connected (ICCN) is a control message sent by the LAC
   to the LNS in response to a received ICRP message. It is the third
   message in the three message exchange used for establishing sessions
   within an L2TP tunnel.

   ICCN is used to indicate that the ICRP was accepted, the call has
   been answered, and that the L2TP session should move to the
   established state.  It also provides additional information to the
   LNS about parameters used for the answered call (parameters that may
   not always available at the time the ICRQ is issued).

   The following AVPs MUST be present in the ICCN:

      Message Type
      (Tx) Connect Speed
      Framing Type

Top      Up      ToC       Page 52 
   The following AVPs MAY be present in the ICCN:

      Initial Received LCP CONFREQ
      Last Sent LCP CONFREQ
      Last Received LCP CONFREQ
      Proxy Authen Type
      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

Top      Up      ToC       Page 53 
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

Top      Up      ToC       Page 54 
   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

Top      Up      ToC       Page 55 
   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).

Top      Up      ToC       Page 56 
   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

Top      Up      ToC       Page 57 
   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

Top      Up      ToC       Page 58 
      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

Top      Up      ToC       Page 59 
   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.

Top      Up      ToC       Page 60 
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

Top      Up      ToC       Page 61 
   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.

Top      Up      ToC       Page 62 
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

Top      Up      ToC       Page 63 
      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:

Top      Up      ToC       Page 64 
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

Top      Up      ToC       Page 65 
      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.

Top      Up      ToC       Page 66 
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.

Top      Up      ToC       Page 67 
   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.

Top      Up      ToC       Page 68 
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

Top      Up      ToC       Page 69 
   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.



(page 69 continued on part 4)

Next RFC Part