Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2661

Layer Two Tunneling Protocol "L2TP"

Pages: 80
Proposed Standard
Errata
Part 1 of 4 – Pages 1 to 12
None   None   Next

Top   ToC   RFC2661 - Page 1
Network Working Group                                        W. Townsley
Request for Comments: 2661                                   A. Valencia
Category: Standards Track                                  cisco Systems
                                                               A. Rubens
                                                   Ascend Communications
                                                                 G. Pall
                                                                 G. Zorn
                                                   Microsoft Corporation
                                                               B. Palter
                                                        Redback Networks
                                                             August 1999


                  Layer Two Tunneling Protocol "L2TP"

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

This document describes the Layer Two Tunneling Protocol (L2TP). STD 51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications.

Table of Contents

1.0 Introduction.......................................... 3 1.1 Specification of Requirements......................... 4 1.2 Terminology........................................... 4 2.0 Topology.............................................. 8 3.0 Protocol Overview..................................... 9 3.1 L2TP Header Format.................................... 9 3.2 Control Message Types................................. 11 4.0 Control Message Attribute Value Pairs................. 12 4.1 AVP Format............................................ 13 4.2 Mandatory AVPs........................................ 14 4.3 Hiding of AVP Attribute Values........................ 14
Top   ToC   RFC2661 - Page 2
   4.4 AVP Summary...........................................   17
      4.4.1 AVPs Applicable To All Control Messages..........   17
      4.4.2 Result and Error Codes...........................   18
      4.4.3 Control Connection Management AVPs...............   20
      4.4.4 Call Management AVPs.............................   27
      4.4.5 Proxy LCP and Authentication AVPs................   34
      4.4.6 Call Status AVPs.................................   39
   5.0 Protocol Operation....................................   41
   5.1 Control Connection Establishment......................   41
      5.1.1 Tunnel Authentication............................   42
   5.2 Session Establishment.................................   42
      5.2.1 Incoming Call Establishment......................   42
      5.2.2 Outgoing Call Establishment......................   43
   5.3 Forwarding PPP Frames.................................   43
   5.4 Using Sequence Numbers on the Data Channel............   44
   5.5 Keepalive (Hello).....................................   44
   5.6 Session Teardown......................................   45
   5.7 Control Connection Teardown...........................   45
   5.8 Reliable Delivery of Control Messages.................   46
   6.0 Control Connection Protocol Specification.............   48
   6.1 Start-Control-Connection-Request (SCCRQ)..............   48
   6.2 Start-Control-Connection-Reply (SCCRP)................   48
   6.3 Start-Control-Connection-Connected (SCCCN)............   49
   6.4 Stop-Control-Connection-Notification (StopCCN)........   49
   6.5 Hello (HELLO).........................................   49
   6.6 Incoming-Call-Request (ICRQ)..........................   50
   6.7 Incoming-Call-Reply (ICRP)............................   51
   6.8 Incoming-Call-Connected (ICCN)........................   51
   6.9 Outgoing-Call-Request (OCRQ)..........................   52
   6.10 Outgoing-Call-Reply (OCRP)...........................   53
   6.11 Outgoing-Call-Connected (OCCN).......................   53
   6.12 Call-Disconnect-Notify (CDN).........................   53
   6.13 WAN-Error-Notify (WEN)...............................   54
   6.14 Set-Link-Info (SLI)..................................   54
   7.0 Control Connection State Machines.....................   54
   7.1 Control Connection Protocol Operation.................   55
   7.2 Control Connection States.............................   56
      7.2.1 Control Connection Establishment.................   56
   7.3 Timing considerations.................................   58
   7.4 Incoming calls........................................   58
      7.4.1 LAC Incoming Call States.........................   60
      7.4.2 LNS Incoming Call States.........................   62
   7.5 Outgoing calls........................................   63
      7.5.1 LAC Outgoing Call States.........................   64
      7.5.2 LNS Outgoing Call States.........................   66
   7.6 Tunnel Disconnection..................................   67
   8.0 L2TP Over Specific Media..............................   67
   8.1 L2TP over UDP/IP......................................   68
Top   ToC   RFC2661 - Page 3
   8.2 IP....................................................   69
   9.0 Security Considerations...............................   69
   9.1 Tunnel Endpoint Security..............................   70
   9.2 Packet Level Security.................................   70
   9.3 End to End Security...................................   70
   9.4 L2TP and IPsec........................................   71
   9.5 Proxy PPP Authentication..............................   71
   10.0 IANA Considerations..................................   71
   10.1 AVP Attributes.......................................   71
   10.2 Message Type AVP Values..............................   72
   10.3 Result Code AVP Values...............................   72
      10.3.1 Result Code Field Values........................   72
      10.3.2 Error Code Field Values.........................   72
   10.4 Framing Capabilities & Bearer Capabilities...........   72
   10.5 Proxy Authen Type AVP Values.........................   72
   10.6 AVP Header Bits......................................   73
   11.0 References...........................................   73
   12.0 Acknowledgments......................................   74
   13.0 Authors' Addresses...................................   75
   Appendix A: Control Channel Slow Start and Congestion
               Avoidance.....................................   76
   Appendix B: Control Message Examples......................   77
   Appendix C: Intellectual Property Notice..................   79
   Full Copyright Statement..................................   80

1.0 Introduction

PPP [RFC1661] defines an encapsulation mechanism for transporting multiprotocol packets across layer 2 (L2) point-to-point links. Typically, a user obtains a L2 connection to a Network Access Server (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN, ADSL, etc.) and then runs PPP over that connection. In such a configuration, the L2 termination point and PPP session endpoint reside on the same physical device (i.e., the NAS). L2TP extends the PPP model by allowing the L2 and PPP endpoints to reside on different devices interconnected by a packet-switched network. With L2TP, a user has an L2 connection to an access concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the concentrator then tunnels individual PPP frames to the NAS. This allows the actual processing of PPP packets to be divorced from the termination of the L2 circuit. One obvious benefit of such a separation is that instead of requiring the L2 connection terminate at the NAS (which may require a long-distance toll charge), the connection may terminate at a (local) circuit concentrator, which then extends the logical PPP session over
Top   ToC   RFC2661 - Page 4
   a shared infrastructure such as frame relay circuit or the Internet.
   From the user's perspective, there is no functional difference between
   having the L2 circuit terminate in a NAS directly or using L2TP.

   L2TP may also solve the multilink hunt-group splitting problem.
   Multilink PPP [RFC1990] requires that all channels composing a
   multilink bundle be grouped at a single Network Access Server (NAS).
   Due to its ability to project a PPP session to a location other than
   the point at which it was physically received, L2TP can be used to
   make all channels terminate at a single NAS. This allows multilink
   operation even when the calls are spread across distinct physical
   NASs.

   This document defines the necessary control protocol for on-demand
   creation of tunnels between two nodes and the accompanying
   encapsulation for multiplexing multiple, tunneled PPP sessions.

1.1 Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

1.2 Terminology

Analog Channel A circuit-switched communication path which is intended to carry 3.1 kHz audio in each direction. Attribute Value Pair (AVP) The variable length concatenation of a unique Attribute (represented by an integer) and a Value containing the actual value identified by the attribute. Multiple AVPs make up Control Messages which are used in the establishment, maintenance, and teardown of tunnels. Call A connection (or attempted connection) between a Remote System and LAC. For example, a telephone call through the PSTN. A Call (Incoming or Outgoing) which is successfully established between a Remote System and LAC results in a corresponding L2TP Session within a previously established Tunnel between the LAC and LNS. (See also: Session, Incoming Call, Outgoing Call).
Top   ToC   RFC2661 - Page 5
   Called Number

      An indication to the receiver of a call as to what telephone
      number the caller used to reach it.

   Calling Number

      An indication to the receiver of a call as to the telephone number
      of the caller.

   CHAP

      Challenge Handshake Authentication Protocol [RFC1994], a PPP
      cryptographic challenge/response authentication protocol in which
      the cleartext password is not passed over the line.

   Control Connection

      A control connection operates in-band over a tunnel to control the
      establishment, release, and maintenance of sessions and of the
      tunnel itself.

   Control Messages

      Control messages are exchanged between LAC and LNS pairs,
      operating in-band within the tunnel protocol. Control messages
      govern aspects of the tunnel and sessions within the tunnel.

   Digital Channel

      A circuit-switched communication path which is intended to carry
      digital information in each direction.

   DSLAM

      Digital Subscriber Line (DSL) Access Module. A network device used
      in the deployment of DSL service. This is typically a concentrator
      of individual DSL lines located in a central office (CO) or local
      exchange.

   Incoming Call

      A Call received at an LAC to be tunneled to an LNS (see Call,
      Outgoing Call).
Top   ToC   RFC2661 - Page 6
   L2TP Access Concentrator (LAC)

      A node that acts as one side of an L2TP tunnel endpoint and is a
      peer to the L2TP Network Server (LNS).  The LAC sits between an
      LNS and a remote system and forwards packets to and from each.
      Packets sent from the LAC to the LNS requires tunneling with the
      L2TP protocol as defined in this document.  The connection from
      the LAC to the remote system is either local (see: Client LAC) or
      a PPP link.

   L2TP Network Server (LNS)

      A node that acts as one side of an L2TP tunnel endpoint and is a
      peer to the L2TP Access Concentrator (LAC).  The LNS is the
      logical termination point of a PPP session that is being tunneled
      from the remote system by the LAC.

   Management Domain (MD)

      A network or networks under the control of a single
      administration, policy or system. For example, an LNS's Management
      Domain might be the corporate network it serves. An LAC's
      Management Domain might be the Internet Service Provider that owns
      and manages it.

   Network Access Server (NAS)

      A device providing local network access to users across a remote
      access network such as the PSTN. An NAS may also serve as an LAC,
      LNS or both.

   Outgoing Call

      A Call placed by an LAC on behalf of an LNS (see Call, Incoming
      Call).

   Peer

      When used in context with L2TP, peer refers to either the LAC or
      LNS. An LAC's Peer is an LNS and vice versa. When used in context
      with PPP, a peer is either side of the PPP connection.

   POTS

      Plain Old Telephone Service.
Top   ToC   RFC2661 - Page 7
   Remote System

      An end-system or router attached to a remote access network (i.e.
      a PSTN), which is either the initiator or recipient of a call.
      Also referred to as a dial-up or virtual dial-up client.

   Session

      L2TP is connection-oriented. The LNS and LAC maintain state for
      each Call that is initiated or answered by an LAC. An L2TP Session
      is created between the LAC and LNS when an end-to-end PPP
      connection is established between a Remote System and the LNS.
      Datagrams related to the PPP connection are sent over the Tunnel
      between the LAC and LNS. There is a one to one relationship
      between established L2TP Sessions and their associated Calls. (See
      also: Call).

   Tunnel

      A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a
      Control Connection and zero or more L2TP Sessions. The Tunnel
      carries encapsulated PPP datagrams and Control Messages between
      the LAC and the LNS.

   Zero-Length Body (ZLB) Message

      A control packet with only an L2TP header. ZLB messages are used
      for explicitly acknowledging packets on the reliable control
      channel.
Top   ToC   RFC2661 - Page 8

2.0 Topology

The following diagram depicts a typical L2TP scenario. The goal is to tunnel PPP frames between the Remote System or LAC Client and an LNS located at a Home LAN. [Home LAN] [LAC Client]----------+ | ____|_____ +--[Host] | | | [LAC]---------| Internet |-----[LNS]-----+ | |__________| | _____|_____ : | | | PSTN | [Remote]--| Cloud | [System] | | [Home LAN] |___________| | | ______________ +---[Host] | | | | [LAC]-------| Frame Relay |---[LNS]-----+ | or ATM Cloud | | |______________| : The Remote System initiates a PPP connection across the PSTN Cloud to an LAC. The LAC then tunnels the PPP connection across the Internet, Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is obtained. The Remote System is provided addresses from the HOME LAN via PPP NCP negotiation. Authentication, Authorization and Accounting may be provided by the Home LAN's Management Domain as if the user were connected to a Network Access Server directly. A LAC Client (a Host which runs L2TP natively) may also participate in tunneling to the Home LAN without use of a separate LAC. In this case, the Host containing the LAC Client software already has a connection to the public Internet. A "virtual" PPP connection is then created and the local L2TP LAC Client software creates a tunnel to the LNS. As in the above case, Addressing, Authentication, Authorization and Accounting will be provided by the Home LAN's Management Domain.
Top   ToC   RFC2661 - Page 9

3.0 Protocol Overview

L2TP utilizes two types of messages, control messages and data messages. Control messages are used in the establishment, maintenance and clearing of tunnels and calls. Data messages are used to encapsulate PPP frames being carried over the tunnel. Control messages utilize a reliable Control Channel within L2TP to guarantee delivery (see section 5.1 for details). Data messages are not retransmitted when packet loss occurs. +-------------------+ | PPP Frames | +-------------------+ +-----------------------+ | L2TP Data Messages| | L2TP Control Messages | +-------------------+ +-----------------------+ | L2TP Data Channel | | L2TP Control Channel | | (unreliable) | | (reliable) | +------------------------------------------------+ | Packet Transport (UDP, FR, ATM, etc.) | +------------------------------------------------+ Figure 3.0 L2TP Protocol Structure Figure 3.0 depicts the relationship of PPP frames and Control Messages over the L2TP Control and Data Channels. PPP Frames are passed over an unreliable Data Channel encapsulated first by an L2TP header and then a Packet Transport such as UDP, Frame Relay, ATM, etc. Control messages are sent over a reliable L2TP Control Channel which transmits packets in-band over the same Packet Transport. Sequence numbers are required to be present in all control messages and are used to provide reliable delivery on the Control Channel. Data Messages may use sequence numbers to reorder packets and detect lost packets. All values are placed into their respective fields and sent in network order (high order octets first).

3.1 L2TP Header Format

L2TP packets for the control channel and data channel share a common header format. In each case where a field is optional, its space does not exist in the message if the field is marked not present. Note that while optional on data messages, the Length, Ns, and Nr fields marked as optional below, are required to be present on all control messages.
Top   ToC   RFC2661 - Page 10
   This header is formatted:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tunnel ID           |           Session ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Ns (opt)          |             Nr (opt)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Offset Size (opt)        |    Offset pad... (opt)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3.1 L2TP Message Header

   The Type (T) bit indicates the type of message. It is set to 0 for a
   data message and 1 for a control message.

   If the Length (L) bit is 1, the Length field is present. This bit
   MUST be set to 1 for control messages.

   The x bits are reserved for future extensions. All reserved bits MUST
   be set to 0 on outgoing messages and ignored on incoming messages.

   If the Sequence (S) bit is set to 1 the Ns and Nr fields are present.
   The S bit MUST be set to 1 for control messages.

   If the Offset (O) bit is 1, the Offset Size field is present. The O
   bit MUST be set to 0 (zero) for control messages.

   If the Priority (P) bit is 1, this data message should receive
   preferential treatment in its local queuing and transmission.  LCP
   echo requests used as a keepalive for the link, for instance, should
   generally be sent with this bit set to 1. Without it, a temporary
   interval of local congestion could result in interference with
   keepalive messages and unnecessary loss of the link. This feature is
   only for use with data messages. The P bit MUST be set to 0 for all
   control messages.

   Ver MUST be 2, indicating the version of the L2TP data message header
   described in this document. The value 1 is reserved to permit
   detection of L2F [RFC2341] packets should they arrive intermixed with
   L2TP packets. Packets received with an unknown Ver field MUST be
   discarded.

   The Length field indicates the total length of the message in octets.
Top   ToC   RFC2661 - Page 11
   Tunnel ID indicates the identifier for the control connection. L2TP
   tunnels are named by identifiers that have local significance only.
   That is, the same tunnel will be given different Tunnel IDs by each
   end of the tunnel. Tunnel ID in each message is that of the intended
   recipient, not the sender. Tunnel IDs are selected and exchanged as
   Assigned Tunnel ID AVPs during the creation of a tunnel.

   Session ID indicates the identifier for a session within a tunnel.
   L2TP sessions are named by identifiers that have local significance
   only. That is, the same session will be given different Session IDs
   by each end of the session. Session ID in each message is that of the
   intended recipient, not the sender. Session IDs are selected and
   exchanged as Assigned Session ID AVPs during the creation of a
   session.

   Ns indicates the sequence number for this data or control message,
   beginning at zero and incrementing by one (modulo 2**16) for each
   message sent. See Section 5.8 and 5.4 for more information on using
   this field.

   Nr indicates the sequence number expected in the next control message
   to be received.  Thus, Nr is set to the Ns of the last in-order
   message received plus one (modulo 2**16). In data messages, Nr is
   reserved and, if present (as indicated by the S-bit), MUST be ignored
   upon receipt. See section 5.8 for more information on using this
   field in control messages.

   The Offset Size field, if present, specifies the number of octets
   past the L2TP header at which the payload data is expected to start.
   Actual data within the offset padding is undefined. If the offset
   field is present, the L2TP header ends after the last octet of the
   offset padding.

3.2 Control Message Types

The Message Type AVP (see section 4.4.1) defines the specific type of control message being sent. Recall from section 3.1 that this is only for control messages, that is, messages with the T-bit set to 1.
Top   ToC   RFC2661 - Page 12
   This document defines the following control message types (see
   Section 6.1 through 6.14 for details on the construction and use of
   each message):

   Control Connection Management

      0  (reserved)

      1  (SCCRQ)    Start-Control-Connection-Request
      2  (SCCRP)    Start-Control-Connection-Reply
      3  (SCCCN)    Start-Control-Connection-Connected
      4  (StopCCN)  Stop-Control-Connection-Notification
      5  (reserved)
      6  (HELLO)    Hello

   Call Management

      7  (OCRQ)     Outgoing-Call-Request
      8  (OCRP)     Outgoing-Call-Reply
      9  (OCCN)     Outgoing-Call-Connected
      10 (ICRQ)     Incoming-Call-Request
      11 (ICRP)     Incoming-Call-Reply
      12 (ICCN)     Incoming-Call-Connected
      13 (reserved)
      14 (CDN)      Call-Disconnect-Notify

   Error Reporting

      15 (WEN)      WAN-Error-Notify

   PPP Session Control

      16 (SLI)      Set-Link-Info



(page 12 continued on part 2)

Next Section