GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2661

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

Townsley, et al. Standards Track [Page 1] RFC 2661 L2TP August 1999

 4.4 AVP Summary...........................................   17
    4.4.1 AVPs Applicable To All Control Messages..........   17
    4.4.2 Result and Error Codes...........................   18
    4.4.3 Control Connection Management AVPs...............   20
    4.4.4 Call Management AVPs.............................   27
    4.4.5 Proxy LCP and Authentication AVPs................   34
    4.4.6 Call Status AVPs.................................   39
 5.0 Protocol Operation....................................   41
 5.1 Control Connection Establishment......................   41
    5.1.1 Tunnel Authentication............................   42
 5.2 Session Establishment.................................   42
    5.2.1 Incoming Call Establishment......................   42
    5.2.2 Outgoing Call Establishment......................   43
 5.3 Forwarding PPP Frames.................................   43
 5.4 Using Sequence Numbers on the Data Channel............   44
 5.5 Keepalive (Hello).....................................   44
 5.6 Session Teardown......................................   45
 5.7 Control Connection Teardown...........................   45
 5.8 Reliable Delivery of Control Messages.................   46
 6.0 Control Connection Protocol Specification.............   48
 6.1 Start-Control-Connection-Request (SCCRQ)..............   48
 6.2 Start-Control-Connection-Reply (SCCRP)................   48
 6.3 Start-Control-Connection-Connected (SCCCN)............   49
 6.4 Stop-Control-Connection-Notification (StopCCN)........   49
 6.5 Hello (HELLO).........................................   49
 6.6 Incoming-Call-Request (ICRQ)..........................   50
 6.7 Incoming-Call-Reply (ICRP)............................   51
 6.8 Incoming-Call-Connected (ICCN)........................   51
 6.9 Outgoing-Call-Request (OCRQ)..........................   52
 6.10 Outgoing-Call-Reply (OCRP)...........................   53
 6.11 Outgoing-Call-Connected (OCCN).......................   53
 6.12 Call-Disconnect-Notify (CDN).........................   53
 6.13 WAN-Error-Notify (WEN)...............................   54
 6.14 Set-Link-Info (SLI)..................................   54
 7.0 Control Connection State Machines.....................   54
 7.1 Control Connection Protocol Operation.................   55
 7.2 Control Connection States.............................   56
    7.2.1 Control Connection Establishment.................   56
 7.3 Timing considerations.................................   58
 7.4 Incoming calls........................................   58
    7.4.1 LAC Incoming Call States.........................   60
    7.4.2 LNS Incoming Call States.........................   62
 7.5 Outgoing calls........................................   63
    7.5.1 LAC Outgoing Call States.........................   64
    7.5.2 LNS Outgoing Call States.........................   66
 7.6 Tunnel Disconnection..................................   67
 8.0 L2TP Over Specific Media..............................   67
 8.1 L2TP over UDP/IP......................................   68

Townsley, et al. Standards Track [Page 2] RFC 2661 L2TP August 1999

 8.2 IP....................................................   69
 9.0 Security Considerations...............................   69
 9.1 Tunnel Endpoint Security..............................   70
 9.2 Packet Level Security.................................   70
 9.3 End to End Security...................................   70
 9.4 L2TP and IPsec........................................   71
 9.5 Proxy PPP Authentication..............................   71
 10.0 IANA Considerations..................................   71
 10.1 AVP Attributes.......................................   71
 10.2 Message Type AVP Values..............................   72
 10.3 Result Code AVP Values...............................   72
    10.3.1 Result Code Field Values........................   72
    10.3.2 Error Code Field Values.........................   72
 10.4 Framing Capabilities & Bearer Capabilities...........   72
 10.5 Proxy Authen Type AVP Values.........................   72
 10.6 AVP Header Bits......................................   73
 11.0 References...........................................   73
 12.0 Acknowledgments......................................   74
 13.0 Authors' Addresses...................................   75
 Appendix A: Control Channel Slow Start and 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

Townsley, et al. Standards Track [Page 3] RFC 2661 L2TP August 1999

 a shared infrastructure such as frame relay circuit or the Internet.
 From the user's perspective, there is no functional difference 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).

Townsley, et al. Standards Track [Page 4] RFC 2661 L2TP August 1999

 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).

Townsley, et al. Standards Track [Page 5] RFC 2661 L2TP August 1999

 L2TP Access Concentrator (LAC)
    A node that acts as one side of an L2TP tunnel endpoint and is 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.

Townsley, et al. Standards Track [Page 6] RFC 2661 L2TP August 1999

 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.

Townsley, et al. Standards Track [Page 7] RFC 2661 L2TP August 1999

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.

Townsley, et al. Standards Track [Page 8] RFC 2661 L2TP August 1999

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.

Townsley, et al. Standards Track [Page 9] RFC 2661 L2TP August 1999

 This header is formatted:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Tunnel ID           |           Session ID          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Ns (opt)          |             Nr (opt)          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Offset Size (opt)        |    Offset pad... (opt)
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 3.1 L2TP Message 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.

Townsley, et al. Standards Track [Page 10] RFC 2661 L2TP August 1999

 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.

Townsley, et al. Standards Track [Page 11] RFC 2661 L2TP August 1999

 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

4.0 Control Message Attribute Value Pairs

 To maximize extensibility while still permitting interoperability, a
 uniform method for encoding message types and bodies is used
 throughout L2TP.  This encoding will be termed AVP (Attribute-Value
 Pair) in the remainder of this document.

Townsley, et al. Standards Track [Page 12] RFC 2661 L2TP August 1999

4.1 AVP Format

 Each AVP is encoded as:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |M|H| rsvd  |      Length       |           Vendor ID           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Attribute Type        |        Attribute Value...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     [until Length is reached]...                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The first six bits are a bit mask, describing the general attributes
 of the AVP.
 Two bits are defined in this document, the remaining are reserved for
 future extensions.  Reserved bits MUST be set to 0. An AVP received
 with a reserved bit set to 1 MUST be treated as an unrecognized AVP.
 Mandatory (M) bit: Controls the behavior required of an
 implementation which receives an AVP which it does not recognize. If
 the M bit is set on an unrecognized AVP within a message associated
 with a particular session, the session associated with this message
 MUST be terminated. If the M bit is set on an unrecognized AVP within
 a message associated with the overall tunnel, the entire tunnel (and
 all sessions within) MUST be terminated. If the M bit is not set, an
 unrecognized AVP MUST be ignored. The control message must then
 continue to be processed as if the AVP had not been present.
 Hidden (H) bit: Identifies the hiding of data in the Attribute Value
 field of an AVP.  This capability can be used to avoid the passing of
 sensitive data, such as user passwords, as cleartext in an AVP.
 Section 4.3 describes the procedure for performing AVP hiding.
 Length: Encodes the number of octets (including the Overall Length
 and bitmask fields) contained in this AVP. The Length may be
 calculated as 6 + the length of the Attribute Value field in octets.
 The field itself is 10 bits, permitting a maximum of 1023 octets of
 data in a single AVP. The minimum Length of an AVP is 6. If the
 length is 6, then the Attribute Value field is absent.
 Vendor ID: The IANA assigned "SMI Network Management Private
 Enterprise Codes" [RFC1700] value.  The value 0, corresponding to
 IETF adopted attribute values, is used for all AVPs defined within
 this document. Any vendor wishing to implement their own L2TP
 extensions can use their own Vendor ID along with private Attribute

Townsley, et al. Standards Track [Page 13] RFC 2661 L2TP August 1999

 values, guaranteeing that they will not collide with any other
 vendor's extensions, nor with future IETF extensions. Note that there
 are 16 bits allocated for the Vendor ID, thus limiting this feature
 to the first 65,535 enterprises.
 Attribute Type: A 2 octet value with a unique interpretation across
 all AVPs defined under a given Vendor ID.
 Attribute Value: This is the actual value as indicated by the Vendor
 ID and Attribute Type. It follows immediately after the Attribute
 Type field, and runs for the remaining octets indicated in the Length
 (i.e., Length minus 6 octets of header). This field is absent if the
 Length is 6.

4.2 Mandatory AVPs

 Receipt of an unknown AVP that has the M-bit set is catastrophic to
 the session or tunnel it is associated with. Thus, the M bit should
 only be defined for AVPs which are absolutely crucial to proper
 operation of the session or tunnel. Further, in the case where the
 LAC or LNS receives an unknown AVP with the M-bit set and shuts down
 the session or tunnel accordingly, it is the full responsibility of
 the peer sending the Mandatory AVP to accept fault for causing an
 non-interoperable situation. Before defining an AVP with the M-bit
 set, particularly a vendor-specific AVP, be sure that this is the
 intended consequence.
 When an adequate alternative exists to use of the M-bit, it should be
 utilized. For example, rather than simply sending an AVP with the M-
 bit set to determine if a specific extension exists, availability may
 be identified by sending an AVP in a request message and expecting a
 corresponding AVP in a reply message.
 Use of the M-bit with new AVPs (those not defined in this document)
 MUST provide the ability to configure the associated feature off,
 such that the AVP is either not sent, or sent with the M-bit not set.

4.3 Hiding of AVP Attribute Values

 The H bit in the header of each AVP provides a mechanism to indicate
 to the receiving peer whether the contents of the AVP are hidden or
 present in cleartext.  This feature can be used to hide sensitive
 control message data such as user passwords or user IDs.
 The H bit MUST only be set if a shared secret exists between the LAC
 and LNS. The shared secret is the same secret that is used for tunnel
 authentication (see Section 5.1.1).  If the H bit is set in any

Townsley, et al. Standards Track [Page 14] RFC 2661 L2TP August 1999

 AVP(s) in a given control message, a Random Vector AVP must also be
 present in the message and MUST precede the first AVP having an H bit
 of 1.
 Hiding an AVP value is done in several steps. The first step is to
 take the length and value fields of the original (cleartext) AVP and
 encode them into a Hidden AVP Subformat as follows:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Length of Original Value    |   Original Attribute Value ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ...                          |             Padding ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Length of Original Attribute Value:  This is length of the Original
 Attribute Value to be obscured in octets. This is necessary to
 determine the original length of the Attribute Value which is lost
 when the additional Padding is added.
 Original Attribute Value:  Attribute Value that is to be obscured.
 Padding:  Random additional octets used to obscure length of the
 Attribute Value that is being hidden.
 To mask the size of the data being hidden, the resulting subformat
 MAY be padded as shown above. Padding does NOT alter the value placed
 in the Length of Original Attribute Value field, but does alter the
 length of the resultant AVP that is being created. For example, If an
 Attribute Value to be hidden is 4 octets in length, the unhidden AVP
 length would be 10 octets (6 + Attribute Value length). After hiding,
 the length of the AVP will become 6 + Attribute Value length + size
 of the Length of Original Attribute Value field + Padding. Thus, if
 Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24
 octets.
 Next, An MD5 hash is performed on the concatenation of:
 + the 2 octet Attribute number of the AVP
 + the shared secret
 + an arbitrary length random vector
 The value of the random vector used in this hash is passed in the
 value field of a Random Vector AVP. This Random Vector AVP must be
 placed in the message by the sender before any hidden AVPs. The same
 random vector may be used for more than one hidden AVP in the same

Townsley, et al. Standards Track [Page 15] RFC 2661 L2TP August 1999

 message. If a different random vector is used for the hiding of
 subsequent AVPs then a new Random Vector AVP must be placed in the
 command message before the first AVP to which it applies.
 The MD5 hash value is then XORed with the first 16 octet (or less)
 segment of the Hidden AVP Subformat and placed in the Attribute Value
 field of the Hidden AVP.  If the Hidden AVP Subformat is less than 16
 octets, the Subformat is transformed as if the Attribute Value field
 had been padded to 16 octets before the XOR, but only the actual
 octets present in the Subformat are modified, and the length of the
 AVP is not altered.
 If the Subformat is longer than 16 octets, a second one-way MD5 hash
 is calculated over a stream of octets consisting of the shared secret
 followed by the result of the first XOR.  That hash is XORed with the
 second 16 octet (or less) segment of the Subformat and placed in the
 corresponding octets of the Value field of the Hidden AVP.
 If necessary, this operation is repeated, with the shared secret used
 along with each XOR result to generate the next hash to XOR the next
 segment of the value with.
 The hiding method was adapted from RFC 2138 [RFC2138] which was taken
 from the "Mixing in the Plaintext" section in the book "Network
 Security" by Kaufman, Perlman and Speciner [KPS].  A detailed
 explanation of the method follows:
 Call the shared secret S, the Random Vector RV, and the Attribute
 Value AV. Break the value field into 16-octet chunks p1, p2, etc.
 with the last one padded at the end with random data to a 16-octet
 boundary.  Call the ciphertext blocks c(1), c(2), etc.  We will also
 define intermediate values b1, b2, etc.
        b1 = MD5(AV + S + RV)   c(1) = p1 xor b1
        b2 = MD5(S  + c(1))     c(2) = p2 xor b2
                    .                       .
                    .                       .
                    .                       .
        bi = MD5(S  + c(i-1))   c(i) = pi xor bi
 The String will contain c(1)+c(2)+...+c(i) where + denotes
 concatenation.
 On receipt, the random vector is taken from the last Random Vector
 AVP encountered in the message prior to the AVP to be unhidden.  The
 above process is then reversed to yield the original value.

Townsley, et al. Standards Track [Page 16] RFC 2661 L2TP August 1999

4.4 AVP Summary

 The following sections contain a list of all L2TP AVPs defined in
 this document.
 Following the name of the AVP is a list indicating the message types
 that utilize each AVP. After each AVP title follows a short
 description of the purpose of the AVP, a detail (including a graphic)
 of the format for the Attribute Value, and any additional information
 needed for proper use of the avp.

4.4.1 AVPs Applicable To All Control Messages

 Message Type (All Messages)
    The Message Type AVP, Attribute Type 0, identifies the control
    message herein and defines the context in which the exact meaning
    of the following AVPs will be determined.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Message Type          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Message Type is a 2 octet unsigned integer.
    The Message Type AVP MUST be the first AVP in a message,
    immediately following the control message header (defined in
    section 3.1). See Section 3.2 for the list of defined control
    message types and their identifiers.
    The Mandatory (M) bit within the Message Type AVP has special
    meaning. Rather than an indication as to whether the AVP itself
    should be ignored if not recognized, it is an indication as to
    whether the control message itself should be ignored. Thus, if the
    M-bit is set within the Message Type AVP and the Message Type is
    unknown to the implementation, the tunnel MUST be cleared.  If the
    M-bit is not set, then the implementation may ignore an unknown
    message type. The M-bit MUST be set to 1 for all message types
    defined in this document. This AVP may not be hidden (the H-bit
    MUST be 0).  The Length of this AVP is 8.

Townsley, et al. Standards Track [Page 17] RFC 2661 L2TP August 1999

 Random Vector (All Messages)
    The Random Vector AVP, Attribute Type 36, is used to enable the
    hiding of the Attribute Value of arbitrary AVPs.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Random Octet String ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Random Octet String may be of arbitrary length, although a
    random vector of at least 16 octets is recommended.  The string
    contains the random vector for use in computing the MD5 hash to
    retrieve or hide the Attribute Value of a hidden AVP (see Section
    4.2).
    More than one Random Vector AVP may appear in a message, in which
    case a hidden AVP uses the Random Vector AVP most closely
    preceding it.  This AVP MUST precede the first AVP with the H bit
    set.
    The M-bit for this AVP MUST be set to 1.  This AVP MUST NOT be
    hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the
    length of the Random Octet String.

4.4.2 Result and Error Codes

 Result Code (CDN, StopCCN)
    The Result Code AVP, Attribute Type 1, indicates the reason for
    terminating the control channel or session.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Result Code          |        Error Code (opt)       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Error Message (opt) ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Result Code is a 2 octet unsigned integer.  The optional Error
    Code is a 2 octet unsigned integer.  An optional Error Message can
    follow the Error Code field.  Presence of the Error Code and

Townsley, et al. Standards Track [Page 18] RFC 2661 L2TP August 1999

    Message are indicated by the AVP Length field. The Error Message
    contains an arbitrary string providing further (human readable)
    text associated with the condition. Human readable text in all
    error messages MUST be provided in the UTF-8 charset using the
    Default Language [RFC2277].
    This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
    this AVP MUST be set to 1.  The Length is 8 if there is no Error
    Code or Message, 10 if there is an Error Code and no Error Message
    or 10 + the length of the Error Message if there is an Error Code
    and Message.
    Defined Result Code values for the StopCCN message are:
       0 - Reserved
       1 - General request to clear control connection
       2 - General error--Error Code indicates the problem
       3 - Control channel already exists
       4 - Requester is not authorized to establish a control
           channel
       5 - The protocol version of the requester is not
           supported
            Error Code indicates highest version supported
       6 - Requester is being shut down
       7 - Finite State Machine error
    Defined Result Code values for the CDN message are:
       0 - Reserved
       1 - Call disconnected due to loss of carrier
       2 - Call disconnected for the reason indicated
           in error code
       3 - Call disconnected for administrative reasons
       4 - Call failed due to lack of appropriate facilities
           being available (temporary condition)
       5 - Call failed due to lack of appropriate facilities being
           available (permanent condition)
       6 - Invalid destination
       7 - Call failed due to no carrier detected
       8 - Call failed due to detection of a busy signal
       9 - Call failed due to lack of a dial tone
       10 - Call was not established within time allotted by LAC
       11 - Call was connected but no appropriate framing was
            detected
    The Error Codes defined below pertain to types of errors that are
    not specific to any particular L2TP request, but rather to
    protocol or message format errors. If an L2TP reply indicates in

Townsley, et al. Standards Track [Page 19] RFC 2661 L2TP August 1999

    its Result Code that a general error occurred, the General Error
    value should be examined to determine what the error was. The
    currently defined General Error codes and their meanings are:
       0 - No general error
       1 - No control connection exists yet for this LAC-LNS pair
       2 - Length is wrong
       3 - One of the field values was out of range or
           reserved field was non-zero
       4 - Insufficient resources to handle this operation now
       5 - The Session ID is invalid in this context
       6 - A generic vendor-specific error occurred in the LAC
       7 - Try another.  If LAC is aware of other possible LNS
           destinations, it should try one of them.  This can be
           used to guide an LAC based on LNS policy, for instance,
           the existence of multilink PPP bundles.
       8 - Session or tunnel was shutdown due to receipt of an unknown
           AVP with the M-bit set (see section 4.2). The Error Message
           SHOULD contain the attribute of the offending AVP in (human
           readable) text form.
    When a General Error Code of 6 is used, additional information
    about the error SHOULD be included in the Error Message field.

4.4.3 Control Connection Management AVPs

 Protocol Version (SCCRP, SCCRQ)
    The Protocol Version AVP, Attribute Type 2, indicates the L2TP
    protocol version of the sender.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Ver      |     Rev       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Ver field is a 1 octet unsigned integer containing the value
    1. Rev field is a 1 octet unsigned integer containing 0. This
    pertains to L2TP protocol version 1, revision 0. Note this is not
    the same version number that is included in the header of each
    message.
    This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
    this AVP MUST be set to 1.  The Length of this AVP is 8.

Townsley, et al. Standards Track [Page 20] RFC 2661 L2TP August 1999

 Framing Capabilities (SCCRP, SCCRQ)
    The Framing Capabilities AVP, Attribute Type 3, provides the peer
    with an indication of the types of framing that will be accepted
    or requested by the sender.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Reserved for future framing type definitions          |A|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Attribute Value field is a 32-bit mask, with two bits defined.
    If bit A is set, asynchronous framing is supported. If bit S is
    set, synchronous framing is supported.
    A peer MUST NOT request an incoming or outgoing call with a
    Framing Type AVP specifying a value not advertised in the Framing
    Capabilities AVP it received during control connection
    establishment.  Attempts to do so will result in the call being
    rejected.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) is 10.
 Bearer Capabilities (SCCRP, SCCRQ)
    The Bearer Capabilities AVP, Attribute Type 4, provides the peer
    with an indication of the bearer device types supported by the
    hardware interfaces of the sender for outgoing calls.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Reserved for future bearer type definitions           |A|D|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    This is a 32-bit mask, with two bits defined. If bit A is set,
    analog access is supported. If bit D is set, digital access is
    supported.

Townsley, et al. Standards Track [Page 21] RFC 2661 L2TP August 1999

    An LNS should not request an outgoing call specifying a value in
    the Bearer Type AVP for a device type not advertised in the Bearer
    Capabilities AVP it received from the LAC during control
    connection establishment. Attempts to do so will result in the
    call being rejected.
    This AVP MUST be present if the sender can place outgoing calls
    when requested.
    Note that an LNS that cannot act as an LAC as well will not
    support hardware devices for handling incoming and outgoing calls
    and should therefore set the A and D bits of this AVP to 0, or
    should not send the AVP at all. An LNS that can also act as an LAC
    and place outgoing calls should set A or D as appropriate.
    Presence of this message is not a guarantee that a given outgoing
    call will be placed by the sender if requested, just that the
    physical capability exists.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) is 10.
 Tie Breaker (SCCRQ)
    The Tie Breaker AVP, Attribute Type 5, indicates that the sender
    wishes a single tunnel to exist between the given LAC-LNS pair.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Tie Break Value...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                               ...(64 bits)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Tie Breaker Value is an 8 octet value that is used to choose a
    single tunnel where both LAC and LNS request a tunnel
    concurrently. The recipient of a SCCRQ must check to see if a
    SCCRQ has been sent to the peer, and if so, must compare its Tie
    Breaker value with the received one. The lower value "wins", and
    the "loser" MUST silently discard its tunnel. In the case where a
    tie breaker is present on both sides, and the value is equal, both
    sides MUST discard their tunnels.

Townsley, et al. Standards Track [Page 22] RFC 2661 L2TP August 1999

    If a tie breaker is received, and an outstanding SCCRQ had no tie
    breaker value, the initiator which included the Tie Breaker AVP
    "wins". If neither side issues a tie breaker, then two separate
    tunnels are opened.
    This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
    this AVP MUST be set to 0.  The Length of this AVP is 14.
 Firmware Revision (SCCRP, SCCRQ)
    The Firmware Revision AVP, Attribute Type 6, indicates the
    firmware revision of the issuing device.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Firmware Revision       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Firmware Revision is a 2 octet unsigned integer encoded in a
    vendor specific format.
    For devices which do not have a firmware revision (general purpose
    computers running L2TP software modules, for instance), the
    revision of the L2TP software module may be reported instead.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) is 8.
 Host Name (SCCRP, SCCRQ)
    The Host Name AVP, Attribute Type 7, indicates the name of the
    issuing LAC or LNS.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Host Name ... (arbitrary number of octets)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Host Name is of arbitrary length, but MUST be at least 1
    octet.

Townsley, et al. Standards Track [Page 23] RFC 2661 L2TP August 1999

    This name should be as broadly unique as possible; for hosts
    participating in DNS [RFC1034], a hostname with fully qualified
    domain would be appropriate.
    This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
    this AVP MUST be set to 1.  The Length of this AVP is 6 plus the
    length of the Host Name.
 Vendor Name (SCCRP, SCCRQ)
    The Vendor Name AVP, Attribute Type 8, contains a vendor specific
    (possibly human readable) string describing the type of LAC or LNS
    being used.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Vendor Name ...(arbitrary number of octets)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Vendor Name is the indicated number of octets representing the
    vendor string. Human readable text for this AVP MUST be provided
    in the UTF-8 charset using the Default Language [RFC2277].
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) of this AVP
    is 6 plus the length of the Vendor Name.
 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)
    The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being
    assigned to this tunnel by the sender.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Assigned Tunnel ID       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Assigned Tunnel ID is a 2 octet non-zero unsigned integer.
    The Assigned Tunnel ID AVP establishes a value used to multiplex
    and demultiplex multiple tunnels between the LNS and LAC. The L2TP
    peer MUST place this value in the Tunnel ID header field of all

Townsley, et al. Standards Track [Page 24] RFC 2661 L2TP August 1999

    control and data messages that it subsequently transmits over the
    associated tunnel.  Before the Assigned Tunnel ID AVP is received
    from a peer, messages MUST be sent to that peer with a Tunnel ID
    value of 0 in the header of all control messages.
    In the StopCCN control message, the Assigned Tunnel ID AVP MUST be
    the same as the Assigned Tunnel ID AVP first sent to the receiving
    peer, permitting the peer to identify the appropriate tunnel even
    if a StopCCN is sent before an Assigned Tunnel ID AVP is received.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 8.
 Receive Window Size (SCCRQ, SCCRP)
    The Receive Window Size AVP, Attribute Type 10, specifies the
    receive window size being offered to the remote peer.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Window Size           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Window Size is a 2 octet unsigned integer.
    If absent, the peer must assume a Window Size of 4 for its
    transmit window. The remote peer may send the specified number of
    control messages before it must wait for an acknowledgment.
    This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
    this AVP MUST be set to 1.  The Length of this AVP is 8.
 Challenge (SCCRP, SCCRQ)
    The Challenge AVP, Attribute Type 11, indicates that the issuing
    peer wishes to authenticate the tunnel endpoints using a CHAP-
    style authentication mechanism.

Townsley, et al. Standards Track [Page 25] RFC 2661 L2TP August 1999

    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Challenge ... (arbitrary number of octets)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Challenge is one or more octets of random data.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 6 plus the length of the Challenge.
 Challenge Response (SCCCN, SCCRP)
    The Response AVP, Attribute Type 13, provides a response to a
    challenge received.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Response ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                            ... (16 octets)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Response is a 16 octet value reflecting the CHAP-style
    [RFC1994] response to the challenge.
    This AVP MUST be present in an SCCRP or SCCCN if a challenge was
    received in the preceding SCCRQ or SCCRP. For purposes of the ID
    value in the CHAP response calculation, the value of the Message
    Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for
    an SCCCN).
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 22.

Townsley, et al. Standards Track [Page 26] RFC 2661 L2TP August 1999

4.4.4 Call Management AVPs

 Q.931 Cause Code (CDN)
    The Q.931 Cause Code AVP, Attribute Type 12, is used to give
    additional information in case of unsolicited call disconnection.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Cause Code           |   Cause Msg   | Advisory Msg...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Cause Code is the returned Q.931 Cause code, and Cause Msg is the
    returned Q.931 message code (e.g., DISCONNECT) associated with the
    Cause Code.  Both values are returned in their native ITU
    encodings [DSS1]. An additional ASCII text Advisory Message may
    also be included (presence indicated by the AVP Length) to further
    explain the reason for disconnecting.
    This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
    this AVP MUST be set to 1.  The Length of this AVP is 9, plus the
    size of the Advisory Message.
 Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
    The Assigned Session ID AVP, Attribute Type 14, encodes the ID
    being assigned to this session by the sender.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Assigned Session ID       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Assigned Session ID is a 2 octet non-zero unsigned integer.
    The Assigned Session ID AVP is establishes a value used to
    multiplex and demultiplex data sent over a tunnel between the LNS
    and LAC. The L2TP peer MUST place this value in the Session ID
    header field of all control and data messages that it subsequently
    transmits over the tunnel that belong to this session.  Before the

Townsley, et al. Standards Track [Page 27] RFC 2661 L2TP August 1999

    Assigned Session ID AVP is received from a peer, messages MUST be
    sent to that peer with a Session ID of 0 in the header of all
    control messages.
    In the CDN control message, the same Assigned Session ID AVP first
    sent to the receiving peer is used, permitting the peer to
    identify the appropriate tunnel even if CDN is sent before an
    Assigned Session ID is received.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 8.
 Call Serial Number (ICRQ, OCRQ)
    The Call Serial Number AVP, Attribute Type 15, encodes an
    identifier assigned by the LAC or LNS to this call.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Call Serial Number                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Call Serial Number is a 32 bit value.
    The Call Serial Number is intended to be an easy reference for
    administrators on both ends of a tunnel to use when investigating
    call failure problems. Call Serial Numbers should be set to
    progressively increasing values, which are likely to be unique for
    a significant period of time across all interconnected LNSs and
    LACs.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 10.
 Minimum BPS (OCRQ)
    The Minimum BPS AVP, Attribute Type 16, encodes the lowest
    acceptable line speed for this call.

Townsley, et al. Standards Track [Page 28] RFC 2661 L2TP August 1999

    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Minimum BPS                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The  Minimum BPS is a 32 bit value indicates the speed in bits per
    second.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 10.
 Maximum BPS (OCRQ)
    The Maximum BPS AVP, Attribute Type 17, encodes the highest
    acceptable line speed for this call.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Maximum BPS                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Maximum BPS is a 32 bit value indicates the speed in bits per
    second.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 10.
 Bearer Type (ICRQ, OCRQ)
    The Bearer Type AVP, Attribute Type 18,  encodes the bearer type
    for the incoming or outgoing call.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Reserved for future Bearer Types                |A|D|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Townsley, et al. Standards Track [Page 29] RFC 2661 L2TP August 1999

    The Bearer Type is a 32-bit bit mask, which indicates the bearer
    capability of the call (ICRQ) or required for the call (OCRQ). If
    set, bit A indicates that the call refers to an analog channel. If
    set, bit D indicates that the call refers to a digital channel.
    Both may be set, indicating that the call was either
    indistinguishable, or can be placed on either type of channel.
    Bits in the Value field of this AVP MUST only be set by the LNS
    for an OCRQ if it was set in the Bearer Capabilities AVP received
    from the LAC during control connection establishment.
    It is valid to set neither the A nor D bits in an ICRQ. Such a
    setting may indicate that the call was not received over a
    physical link (e.g if the LAC and PPP are located in the same
    subsystem).
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 10.
 Framing Type (ICCN, OCCN, OCRQ)
    The Framing Type AVP, Attribute Type 19, encodes the framing type
    for the incoming or outgoing call.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Reserved for future Framing Types               |A|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Framing Type is a 32-bit mask, which indicates the type of PPP
    framing requested for an OCRQ, or the type of PPP framing
    negotiated for an OCCN or ICCN. The framing type MAY be used as an
    indication to PPP on the LNS as to what link options to use for
    LCP negotiation [RFC1662].
    Bit A indicates asynchronous framing. Bit S indicates synchronous
    framing. For an OCRQ, both may be set, indicating that either type
    of framing may be used.
    Bits in the Value field of this AVP MUST only be set by the LNS
    for an OCRQ if it was set in the Framing Capabilities AVP received
    from the LAC during control connection establishment.

Townsley, et al. Standards Track [Page 30] RFC 2661 L2TP August 1999

    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 10.
 Called Number (ICRQ, OCRQ)
    The Called Number AVP, Attribute Type 21, encodes the telephone
    number to be called for an OCRQ, and the Called number for an
    ICRQ.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Called Number... (arbitrary number of octets)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Called Number is an ASCII string. Contact between the
    administrator of the LAC and the LNS may be necessary to
    coordinate interpretation of the value needed in this AVP.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 6 plus the length of the Called Number.
 Calling Number (ICRQ)
    The Calling Number AVP, Attribute Type 22, encodes the originating
    number for the incoming call.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Calling Number... (arbitrary number of octets)                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Calling Number is an ASCII string. Contact between the
    administrator of the LAC and the LNS may be necessary to
    coordinate interpretation of the value in this AVP.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 6 plus the length of the Calling Number.

Townsley, et al. Standards Track [Page 31] RFC 2661 L2TP August 1999

 Sub-Address (ICRQ, OCRQ)
    The Sub-Address AVP, Attribute Type 23, encodes additional dialing
    information.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Sub-Address ... (arbitrary number of octets)                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Sub-Address is an ASCII string. Contact between the
    administrator of the LAC and the LNS may be necessary to
    coordinate interpretation of the value in this AVP.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 6 plus the length of the Sub-Address.
 (Tx) Connect Speed (ICCN, OCCN)
    The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the
    speed of the facility chosen for the connection attempt.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             BPS                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The (Tx) Connect Speed BPS is a 4 octet value indicating the speed
    in bits per second.
    When the optional Rx Connect Speed AVP is present, the value in
    this AVP represents the transmit connect speed, from the
    perspective of the LAC (e.g. data flowing from the LAC to the
    remote system). When the optional Rx Connect Speed AVP is NOT
    present, the connection speed between the remote system and LAC is
    assumed to be symmetric and is represented by the single value in
    this AVP.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 10.

Townsley, et al. Standards Track [Page 32] RFC 2661 L2TP August 1999

 Rx Connect Speed (ICCN, OCCN)
    The Rx Connect Speed AVP, Attribute Type 38, represents the speed
    of the connection from the perspective of the LAC (e.g. data
    flowing from the remote system to the LAC).
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           BPS (H)             |            BPS (L)            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    BPS is a 4 octet value indicating the speed in bits per second.
    Presence of this AVP implies that the connection speed may be
    asymmetric with respect to the transmit connect speed given in the
    (Tx) Connect Speed AVP.
    This AVP may be hidden (the H-bit MAY be 1 or 0).  The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) of this AVP
    is 10.
 Physical Channel ID (ICRQ, OCRP)
    The Physical Channel ID AVP, Attribute Type 25, encodes the vendor
    specific physical channel number used for a call.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Physical Channel ID                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Physical Channel ID is a 4 octet value intended to be used for
    logging purposes only.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) of this AVP
    is 10.

Townsley, et al. Standards Track [Page 33] RFC 2661 L2TP August 1999

 Private Group ID (ICCN)
    The Private Group ID AVP, Attribute Type 37, is used by the LAC to
    indicate that this call is to be associated with a particular
    customer group.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Private Group ID ... (arbitrary number of octets)           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Private Group ID is a string of octets of arbitrary length.
    The LNS MAY treat the PPP session as well as network traffic
    through this session in a special manner determined by the peer.
    For example, if the LNS is individually connected to several
    private networks using unregistered addresses, this AVP may be
    included by the LAC to indicate that a given call should be
    associated with one of the private networks.
    The Private Group ID is a string corresponding to a table in the
    LNS that defines the particular characteristics of the selected
    group.  A LAC MAY determine the Private Group ID from a RADIUS
    response, local configuration, or some other source.
    This AVP may be hidden (the H-bit MAY be 1 or 0).  The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) of this AVP
    is 6 plus the length of the Private Group ID.
 Sequencing Required (ICCN, OCCN)
    The Sequencing Required AVP, Attribute Type 39, indicates to the
    LNS that Sequence Numbers MUST always be present on the data
    channel.
    This AVP has no Attribute Value field.
    This AVP MUST NOT be hidden (the H-bit MUST be 0).  The M-bit for
    this AVP MUST be set to 1.  The Length of this AVP is 6.

4.4.5 Proxy LCP and Authentication AVPs

    The LAC may have answered the call and negotiated LCP with the
    remote system, perhaps in order to establish the system's apparent
    identity. In this case, these AVPs may be included to indicate the

Townsley, et al. Standards Track [Page 34] RFC 2661 L2TP August 1999

    link properties the remote system initially requested, properties
    the remote system and LAC ultimately negotiated, as well as PPP
    authentication information sent and received by the LAC. This
    information may be used to initiate the PPP LCP and authentication
    systems on the LNS, allowing PPP to continue without renegotiation
    of LCP. Note that the LNS policy may be to enter an additional
    round of LCP negotiation and/or authentication if the LAC is not
    trusted.
 Initial Received LCP CONFREQ (ICCN)
    In the Initial Received LCP CONFREQ AVP, Attribute Type 26,
    provides the LNS with the Initial CONFREQ received by the LAC from
    the PPP Peer.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | LCP CONFREQ... (arbitrary number of octets)                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    LCP CONFREQ is a copy of the body of the initial CONFREQ received,
    starting at the first option within the body of the LCP message.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) of this AVP
    is 6 plus the length of the CONFREQ.
 Last Sent LCP CONFREQ (ICCN)
    In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the
    LNS with the Last CONFREQ sent by the LAC to the PPP Peer.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | LCP CONFREQ... (arbitrary number of octets)                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The LCP CONFREQ is a copy of the body of the final CONFREQ sent to
    the client to complete LCP negotiation, starting at the first
    option within the body of the LCP message.

Townsley, et al. Standards Track [Page 35] RFC 2661 L2TP August 1999

    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) of this AVP
    is 6 plus the length of the CONFREQ.
 Last Received LCP CONFREQ (ICCN)
    The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the
    LNS with the Last CONFREQ received by the LAC from the PPP Peer.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | LCP CONFREQ... (arbitrary number of octets)                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The LCP CONFREQ is a copy of the body of the final CONFREQ
    received from the client to complete LCP negotiation, starting at
    the first option within the body of the LCP message.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) of this AVP
    is 6 plus the length of the CONFREQ.
 Proxy Authen Type (ICCN)
    The Proxy Authen Type AVP, Attribute Type 29, determines if proxy
    authentication should be used.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Authen Type          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Authen Type is a 2 octet unsigned integer, holding:
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) of this AVP
    is 8.

Townsley, et al. Standards Track [Page 36] RFC 2661 L2TP August 1999

    Defined Authen Type values are:
       0 - Reserved
       1 - Textual username/password exchange
       2 - PPP CHAP
       3 - PPP PAP
       4 - No Authentication
       5 - Microsoft CHAP Version 1 (MSCHAPv1)
       This AVP MUST be present if proxy authentication is to be
       utilized. If it is not present, then it is assumed that this
       peer cannot perform proxy authentication, requiring
       a restart of the authentication phase at the LNS if the client
       has already entered this phase with the
       LAC (which may be determined by the Proxy LCP AVP if present).
    Associated AVPs for each type of authentication follow.
 Proxy Authen Name (ICCN)
    The Proxy Authen Name AVP, Attribute Type 30, specifies the name
    of the authenticating client when using proxy authentication.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Authen Name... (arbitrary number of octets)                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Authen Name is a string of octets of arbitrary length.  It
    contains the name specified in the client's authentication
    response.
    This AVP MUST be present in messages containing a Proxy Authen
    Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable
    to employ AVP hiding for obscuring the cleartext name.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) is 6 plus
    the length of the cleartext name.
 Proxy Authen Challenge (ICCN)
    The Proxy Authen Challenge AVP, Attribute Type 31, specifies the
    challenge sent by the LAC to the PPP Peer, when using proxy
    authentication.

Townsley, et al. Standards Track [Page 37] RFC 2661 L2TP August 1999

    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Challenge... (arbitrary number of octets)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Challenge is a string of one or more octets.
    This AVP MUST be present for Proxy Authen Types 2 and 5. The
    Challenge field contains the CHAP challenge presented to the
    client by the LAC.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) of this AVP
    is 6, plus the length of the Challenge.
 Proxy Authen ID (ICCN)
    The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value
    of the PPP Authentication that was started between the LAC and the
    PPP Peer, when proxy authentication is being used.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Reserved    |      ID       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ID is a 2 octet unsigned integer, the most significant octet MUST
    be 0.
    The Proxy Authen ID AVP MUST be present for Proxy authen types 2,
    3 and 5. For 2 and 5, the ID field contains the byte ID value
    presented to the client by the LAC in its Challenge. For 3, it is
    the Identifier value of the Authenticate-Request.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.
 Proxy Authen Response (ICCN)
    The Proxy Authen Response AVP, Attribute Type 33, specifies the
    PPP Authentication response received by the LAC from the PPP Peer,
    when proxy authentication is used.

Townsley, et al. Standards Track [Page 38] RFC 2661 L2TP August 1999

    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Response... (arbitrary number of octets)                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Response is a string of octets.
    This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The
    Response field contains the client's response to the challenge.
    For Proxy authen types 2 and 5, this field contains the response
    value received by the LAC. For types 1 or 3, it contains the clear
    text password received from the client by the LAC.  In the case of
    cleartext passwords, AVP hiding is recommended.
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 0.  The Length (before hiding) of this AVP
    is 6 plus the length of the Response.

4.4.6 Call Status AVPs

 Call Errors (WEN)
    The Call Errors AVP, Attribute Type 34, is used by the LAC to send
    error information to the LNS.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Reserved              |        CRC Errors (H)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         CRC Errors (L)        |        Framing Errors (H)     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Framing Errors (L)    |        Hardware Overruns (H)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Hardware Overruns (L) |        Buffer Overruns (H)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Buffer Overruns  (L)  |        Time-out Errors (H)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Time-out Errors (L)   |        Alignment Errors (H)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Alignment Errors (L)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Townsley, et al. Standards Track [Page 39] RFC 2661 L2TP August 1999

    The following fields are defined:
       Reserved - Not used, MUST be 0
       CRC Errors - Number of PPP frames received with CRC errors
          since call was established
       Framing Errors - Number of improperly framed PPP packets
          received
       Hardware Overruns - Number of receive buffer over-runs since
          call was established
       Buffer Overruns - Number of buffer over-runs detected since
          call was established
       Time-out Errors - Number of time-outs since call was
          established
       Alignment Errors - Number of alignment errors since call was
          established
    This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
    this AVP MUST be set to 1.  The Length (before hiding) of this AVP
    is 32.
 ACCM (SLI)
    The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC
    of the ACCM negotiated with the PPP Peer by the LNS.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Reserved             |    Send ACCM (H)              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Send ACCM   (L)      |    Receive ACCM (H)           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Receive ACCM  (L)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Send ACCM and Receive ACCM are each 4 octet values preceded by a 2
    octet reserved quantity. The send ACCM value should be used by the
    LAC to process packets it sends on the connection. The receive
    ACCM value should be used by the LAC to process incoming packets
    on the connection. The default values used by the LAC for both
    these fields are 0xFFFFFFFF. The LAC should honor these fields
    unless it has specific configuration information to indicate that
    the requested mask must be modified to permit operation.
    This AVP may be hidden (the H-bit MAY be 1 or 0).  The M-bit for
    this AVP MUST be set to 1.  The Length of this AVP is 16.

Townsley, et al. Standards Track [Page 40] RFC 2661 L2TP August 1999

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.

Townsley, et al. Standards Track [Page 41] RFC 2661 L2TP August 1999

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.

Townsley, et al. Standards Track [Page 42] RFC 2661 L2TP August 1999

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.

Townsley, et al. Standards Track [Page 43] RFC 2661 L2TP August 1999

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

Townsley, et al. Standards Track [Page 44] RFC 2661 L2TP August 1999

 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.

Townsley, et al. Standards Track [Page 45] RFC 2661 L2TP August 1999

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.

Townsley, et al. Standards Track [Page 46] RFC 2661 L2TP August 1999

 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.

Townsley, et al. Standards Track [Page 47] RFC 2661 L2TP August 1999

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

Townsley, et al. Standards Track [Page 48] RFC 2661 L2TP August 1999

 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.

Townsley, et al. Standards Track [Page 49] RFC 2661 L2TP August 1999

 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.

Townsley, et al. Standards Track [Page 50] RFC 2661 L2TP August 1999

 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

Townsley, et al. Standards Track [Page 51] RFC 2661 L2TP August 1999

 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

Townsley, et al. Standards Track [Page 52] RFC 2661 L2TP August 1999

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

Townsley, et al. Standards Track [Page 53] RFC 2661 L2TP August 1999

 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

Townsley, et al. Standards Track [Page 54] RFC 2661 L2TP August 1999

 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).

Townsley, et al. Standards Track [Page 55] RFC 2661 L2TP August 1999

 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

Townsley, et al. Standards Track [Page 56] RFC 2661 L2TP August 1999

 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

Townsley, et al. Standards Track [Page 57] RFC 2661 L2TP August 1999

    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:
  1. No resources are available to handle more sessions
  2. The dialed, dialing, or subaddress fields do not correspond to

an authorized user

  1. The bearer service is not authorized or supported

Townsley, et al. Standards Track [Page 58] RFC 2661 L2TP August 1999

 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.

Townsley, et al. Standards Track [Page 59] RFC 2661 L2TP August 1999

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

Townsley, et al. Standards Track [Page 60] RFC 2661 L2TP August 1999

 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.

Townsley, et al. Standards Track [Page 61] RFC 2661 L2TP August 1999

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

Townsley, et al. Standards Track [Page 62] RFC 2661 L2TP August 1999

    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:

Townsley, et al. Standards Track [Page 63] RFC 2661 L2TP August 1999

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

Townsley, et al. Standards Track [Page 64] RFC 2661 L2TP August 1999

    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.

Townsley, et al. Standards Track [Page 65] RFC 2661 L2TP August 1999

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.

Townsley, et al. Standards Track [Page 66] RFC 2661 L2TP August 1999

 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.

Townsley, et al. Standards Track [Page 67] RFC 2661 L2TP August 1999

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

Townsley, et al. Standards Track [Page 68] RFC 2661 L2TP August 1999

 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.

Townsley, et al. Standards Track [Page 69] RFC 2661 L2TP August 1999

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.

Townsley, et al. Standards Track [Page 70] RFC 2661 L2TP August 1999

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

Townsley, et al. Standards Track [Page 71] RFC 2661 L2TP August 1999

 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 [RFC 2434].

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 [RFC 2434]

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 [RFC 2434].

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 [RFC 2434]. The remaining
 values of the Error Code field are available for assignment via First
 Come First Served [RFC 2434].

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 [RFC 2434].

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 [RFC 2434].

Townsley, et al. Standards Track [Page 72] RFC 2661 L2TP August 1999

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 [RFC 2434].

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, RFC 791, September
           1981.
 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
           STD 13, RFC 1034, November 1987.
 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
           Serial Links", RFC 1144, February 1990.
 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
           RFC 1661, July 1994.
 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
           July 1994.
 [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
           1700, October 1994.  See also:
           http://www.iana.org/numbers.html
 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
           Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
           August 1996.
 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
           Protocol (CHAP)", RFC 1994, August 1996.
 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
           and E. Lear, "Address Allocation for Private Internets",
           BCP 5, RFC 1918, February 1996.

Townsley, et al. Standards Track [Page 73] RFC 2661 L2TP August 1999

 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
           Authentication Dial In User Service (RADIUS)", RFC 2138,
           April 1997.
 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
           Languages", BCP 18, RFC 2277, January 1998.
 [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
           Forwarding (Protocol) L2F", RFC 2341, May 1998.
 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
           Internet Protocol", RFC 2401, November 1998.
 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 2434,
           October 1998.
 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
           and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
           RFC 2637, July 1999.
 [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The
           Protocols", Addison-Wesley Publishing Company, Inc., March
           1996, ISBN 0-201-63346-9

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.

Townsley, et al. Standards Track [Page 74] RFC 2661 L2TP August 1999

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

Townsley, et al. Standards Track [Page 75] RFC 2661 L2TP August 1999

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.

Townsley, et al. Standards Track [Page 76] RFC 2661 L2TP August 1999

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)

Townsley, et al. Standards Track [Page 77] RFC 2661 L2TP August 1999

                                       <-       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

Townsley, et al. Standards Track [Page 78] RFC 2661 L2TP August 1999

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.

Townsley, et al. Standards Track [Page 79] RFC 2661 L2TP August 1999

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 RFC Editor function is currently provided by the
 Internet Society.

Townsley, et al. Standards Track [Page 80]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2661.txt · Last modified: 1999/08/13 21:50 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki