PPP Working Group A. Valencia INTERNET DRAFT Cisco Systems Category: Internet Draft K. Hamzeh, A. Rubens Title: draft-ietf-pppext-l2tp-12.txt Ascend Communications Date: October 1998 T. Kolar, M. Littlewood W. M. Townsley Cisco Systems J. Taarud Copper Mountain Networks G. S. Pall Microsoft Corporation B. Palter Network Alchemy W. Verthein 3COM Corporation Layer Two Tunneling Protocol "L2TP" Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. RFC 1661 specifies multi-protocol dial-up via PPP [1]. This document describes the Layer Two Tunneling Protocol (L2TP) which permits the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. Valencia expires June 1999 [Page 1] INTERNET DRAFT October 1998 Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.0 Problem Space Overview . . . . . . . . . . . . . . . . . . 6 2.1 Initial Assumptions . . . . . . . . . . . . . . . . . . . 6 2.2 Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Providing Virtual Dial-up Services--a walk-through . . . . 7 3.0 Service Model Issues . . . . . . . . . . . . . . . . . . . 9 3.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Address Allocation . . . . . . . . . . . . . . . . . . . . 10 3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11 4.0 Protocol Overview . . . . . . . . . . . . . . . . . . . . 11 4.1 Control Message Overview . . . . . . . . . . . . . . . . . 13 4.2 Payload Packet Overview . . . . . . . . . . . . . . . . . 13 4.3 Flow Control . . . . . . . . . . . . . . . . . . . . . . . 16 5.0 Message Format and Protocol Extensibility . . . . . . . . 18 5.1 AVP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2 Control Message Format . . . . . . . . . . . . . . . . . . 20 5.3 Payload Message Format . . . . . . . . . . . . . . . . . . 21 5.4 Control Message Types . . . . . . . . . . . . . . . . . . 22 5.5 AVP Summary . . . . . . . . . . . . . . . . . . . . . . . 23 5.6 Result and Error Code Summary . . . . . . . . . . . . . . 25 5.7 Hiding of AVP values . . . . . . . . . . . . . . . . . . . 27 6.0 Control Connection Protocol Specification . . . . . . . . 30 6.0.1 Control Connection Collision . . . . . . . . . . . . . . 30 6.0.2 Reliable Delivery of Control Messages . . . . . . . . . 30 6.0.3 Control Message Format . . . . . . . . . . . . . . . . . 31 6.1 Start-Control-Connection-Request . . . . . . . . . . . . . 31 6.2 Start-Control-Connection-Reply . . . . . . . . . . . . . . 37 6.3 Start-Control-Connection-Connected . . . . . . . . . . . . 41 6.4 Stop-Control-Connection-Notification . . . . . . . . . . . 42 6.5 Hello . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.6 Outgoing-Call-Request . . . . . . . . . . . . . . . . . . 44 6.7 Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . 49 6.8 Outgoing-Call-Connected . . . . . . . . . . . . . . . . . 50 6.9 Incoming-Call-Request . . . . . . . . . . . . . . . . . . 53 6.10 Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 57 6.11 Incoming-Call-Connected . . . . . . . . . . . . . . . . . 58 6.12 Call-Disconnect-Notify . . . . . . . . . . . . . . . . . 65 6.13 WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . 67 6.14 Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 68 7.0 Control Connection State Machines . . . . . . . . . . . . 69 7.1 Control Connection Protocol Operation . . . . . . . . . . 70 7.2 Control Connection States . . . . . . . . . . . . . . . . 70 7.2.1 Control Connection Establishment . . . . . . . . . . . . 70 7.3 Timing considerations . . . . . . . . . . . . . . . . . . 72 7.4 Incoming Calls . . . . . . . . . . . . . . . . . . . . . . 72 7.4.1 LAC Incoming Call States . . . . . . . . . . . . . . . . 72 7.4.2 LNS Incoming Call States . . . . . . . . . . . . . . . . 74 7.5 Outgoing calls . . . . . . . . . . . . . . . . . . . . . . 74 7.5.1 LAC Outgoing Call States . . . . . . . . . . . . . . . . 75 Valencia expires June 1999 [Page 2] INTERNET DRAFT October 1998 7.5.2 LNS Outgoing Call States . . . . . . . . . . . . . . . . 76 7.6 Tunnel Disconnection . . . . . . . . . . . . . . . . . . . 77 8.0 L2TP Over Specific Media . . . . . . . . . . . . . . . . . 77 8.1 IP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 77 8.2 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 9.0 Security Considerations . . . . . . . . . . . . . . . . . 79 9.1 Tunnel Endpoint Security . . . . . . . . . . . . . . . . . 79 9.2 Client Security . . . . . . . . . . . . . . . . . . . . . 79 9.3 Proxy Authentication . . . . . . . . . . . . . . . . . . . 80 10.0 IANA Considerations . . . . . . . . . . . . . . . . . . . 80 10.1 AVP Attribute Type Values . . . . . . . . . . . . . . . . 80 10.2 Message type values . . . . . . . . . . . . . . . . . . . 80 10.3 Result code values . . . . . . . . . . . . . . . . . . . 80 10.4 Framing Capabilities & Bearer Capabilitities . . . . . . 80 10.5 Proxy Authen Type values . . . . . . . . . . . . . . . . 81 10.6 AVP Header bits . . . . . . . . . . . . . . . . . . . . . 81 10.7 Message (Payload and Control) Header bits . . . . . . . . 81 11.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 81 12.0 Contacts . . . . . . . . . . . . . . . . . . . . . . . . 81 13.0 References . . . . . . . . . . . . . . . . . . . . . . . 82 Appendix A: Acknowledgment Time-Outs . . . . . . . . . . . . . 83 Appendix B: Acknowledgment Time-Out and Window Adjustment . . 87 Appendix C: Handling of out-of-order packets . . . . . . . . . 88 Appendix D: Transport Layer Adaptive Time-Outs and Window Adjustment . . . . . . . . . . . . . . 89 Appendix E: Examples of L2TP sequence numbering . . . . . . . 90 Appendix F: Flow Control and Sequencing Negotiation . . . . . 93 1.0 Introduction The traditional dial-up network service on the Internet is for registered IP addresses only. A new class of virtual dial-up application which allows multiple protocols and unregistered IP addresses is also desired on the Internet. Examples of this class of network application are support for privately addressed IP, IPX, and AppleTalk dial-up via PPP across existing Internet infrastructure. The support of these multi-protocol virtual dial-up applications is of significant benefit to end users, enterprises, and Internet Service providers as it allows the sharing of very large investments in access and core infrastructure and allows local calls to be used. It also allows existing investments in non-IP protocol applications to be supported in a secure manner while still leveraging the access infrastructure of the Internet. It is the purpose of this document to identify the issues encountered in integrating multi-protocol dial-up services into an existing Internet Service Provider's Point of Presence (hereafter referred to Valencia expires June 1999 [Page 3] INTERNET DRAFT October 1998 as ISP and POP, respectively), and to describe the L2TP protocol which permits the leveraging of existing access protocols. This protocol may solve the "multilink hunt-group splitting" problem. Multilink PPP [9], often used to aggregate ISDN B channels, requires that all channels composing a multilink bundle be grouped at a single NAS. Because L2TP makes a PPP session terminate at a location other than the point at which the session was physically received, it can be used to make all channels terminate at a single NAS, allowing multilink operation even when the physical calls are spread across distinct physical NAS's. 1.1 Conventions The following language conventions are used in the items of specification in this document: 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 RFC 2119 [15]. 1.2 Terminology Analog Channel A circuit-switched communication path which is intended to carry 3.1 kHz audio in each direction. 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. Call A connection or attempted connection between two terminal endpoints. For example, a telephone call through the PSTN between two modems. (See also: Session). CHAP Challenge Authentication Protocol, a PPP cryptographic challenge/response authentication protocol in which the cleartext password is not passed over the line. CLID Calling Line ID, an indication to the receiver of a call as to the phone number of the caller. Control Messages Control messages are exchanged between LAC and LNS pairs, Valencia expires June 1999 [Page 4] INTERNET DRAFT October 1998 operating in-band within the tunnel protocol. Control messages govern aspects of the tunnel and sessions within the tunnel. Dial User An end-system or router attached to an on-demand PSTN or ISDN which is either the initiator or recipient of a call. Also referred to as a dial-up or Virtual dial-up client. DNIS Dialed Number Information String, an indication to the receiver of a call as to what phone number the caller used to reach it. Digital Channel A circuit-switched communication path which is intended to carry digital information in each direction. EAP Extensible Authentication Protocol, a framework for a family of PPP authentication protocols, including cleartext, challenge/response, and arbitrary dialog sequences. L2TP Access Concentrator (LAC) A Network Access Server (NAS) or host co-located with a PPP end system capable of handling the L2TP protocol. The LAC needs only implement the media over which L2TP is to operate to pass traffic to one or more LNS's. It may tunnel any protocol carried within PPP. The LAC is the initiator of incoming calls and the receiver of outgoing calls. L2TP Network Server (LNS) An LNS operates on any platform capable of PPP termination. The LNS handles the server side of the L2TP protocol. Since L2TP relies only on the single media over which L2TP tunnels arrive, the LNS may have only a single LAN or WAN interface, yet still be able to terminate calls arriving at any LAC's full range of PPP interfaces (async, synchronous ISDN, V.120, etc.). The LNS is the initiator of outgoing calls and the receiver of incoming calls. Network Access Server (NAS) A device providing temporary, on-demand network access to users. This access is point-to-point typically using PSTN or ISDN lines. A NAS may also serve as an LAC, LNS or both. PAP Password Authentication Protocol, a simple PPP authentication mechanism in which a cleartext username and password are Valencia expires June 1999 [Page 5] INTERNET DRAFT October 1998 transmitted to prove identity. POP An Internet Service Provider's Point of Presence. Quality of Service (QOS) A given Quality of Service level is sometimes required for a given user being tunneled between an LNS-LAC pair. For this scenario, a unique L2TP tunnel is created and encapsulated directly on top of the media providing the indicated QOS. Session L2TP is connection-oriented. The LNS and LAC maintain state for each user that is attached to an LAC. A session is created when an end-to-end PPP connection is attempted between a dial user and the LNS, or when an outbound call is initiated. The datagrams related to a session are sent over the tunnel between the LAC and LNS. (See also: Call). Tunnel A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP datagrams between the LAC and the LNS; many sessions can be multiplexed over a single tunnel. A control connection operating in-band over the same tunnel controls the establishment, release, and maintenance of sessions and of the tunnel itself. A tunnel is sometimes referred to as a control connection. Zero-Length Body (ZLB) Message A control or payload packet with only an L2TP header, and no control message information or PPP payload. ZLB messages are used for explicitly acknowledging packets on the control or data channel. 2.0 Problem Space Overview In this section we describe in high level terms the scope of the problem that will be explored in more detail in later sections. 2.1 Initial Assumptions We begin by assuming that Internet access is provided by an ISP and that the ISP wishes to offer services other than traditional registered IP address based services to dial-up users of the network. We also assume that the user of such a service wants all of the security facilities that are available to him or her in a dedicated dial-up configuration. In particular, the end user requires: + End System transparency: Neither the remote end system nor his Valencia expires June 1999 [Page 6] INTERNET DRAFT October 1998 home site hosts should require any special software to use this service in a secure manner. + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or through other dialogs, for instance, a textual exchange on V.120 before starting PPP. This will include TACACS+ [7] and RADIUS [8] solutions as well as support for smart cards and one-time passwords. The authentication should be manageable by the user independently of the ISP. + Addressing should be as manageable as dedicated dial-up solutions. The address should be assigned by the home site and not the ISP. + Authorization should be managed by the home site as it would in a direct dial-up solution. + Accounting should be performed both by the ISP (for billing purposes) and by the user (for charge-back and auditing). 2.2 Topology Shown below is a generic Internet with Public switched Telephone Network (PSTN) access (i.e., async PPP via modems) and Integrated Services Digital Network (ISDN) access (i.e., synchronous PPP access). Remote users (either async or ISDN PPP) will access the Home LAN as if they were dialed into the L2TP Network Server (LNS), although their physical dial-up is via the ISP Network Access Server (acting as the LAC). [LAN] | __________ +--[Host] | | | [LAC]---------| Internet |-----[LNS]-----+ | |__________| | _____|_____ : | | | PSTN | [User]--| or ISDN | | Cloud | [LAN] |___________| | | ______________ +---[Host] | | | | [LAC]-------| Frame Relay |---[LNS]-----+ | or ATM Cloud | | |______________| : 2.3 Providing Virtual dial-up Services--a walk-through To motivate the following discussion, this section walks through an example of what might happen when a Virtual dial-up client initiates access. Valencia expires June 1999 [Page 7] INTERNET DRAFT October 1998 A Network Access Server (NAS) operating as a peer to an LNS is referred to as an L2TP Access Concentrator, or "LAC". The remote user initiates a PPP connection to an ISP via either the PSTN or ISDN. The LAC accepts the connection and the PPP link is established (L2TP also permits the LAC to check with an LNS after call indication prior to accepting the call. This is useful where DNIS or CLID information is available in the incoming call notification). The ISP may now undertake a partial authentication of the end system/user. Only the username field would be interpreted to determine whether the user requires a Virtual dial-up service. It is expected, but not required, that usernames will be structured (e.g. username@company.com). Alternatively, the ISP may maintain a database mapping users to services. In the case of Virtual dial-up, the mapping will name a specific endpoint, the LNS. Alternatively, the ISP may have already determined the target LNS from DNIS. If the LNS is willing to accept tunnel creation without any authentication of the caller, the LAC may tunnel the PPP connection without ever having communicated with the remote user. If a virtual dial-up service is not required, standard access to the Internet may be provided. If no tunnel connection currently exists to the desired LNS, one is initiated. L2TP is designed to be largely insulated from the details of the media over which the tunnel is established; L2TP requires only that the tunnel media provide packet oriented point-to-point connectivity. Obvious examples of such media are UDP, Frame Relay PVC's, or X.25 VC's. Once the tunnel exists, an unused slot within the tunnel, a "Call ID", is allocated, and a connect indication is sent to notify the LNS of this new dial-up session. The LNS either accepts the connection, or rejects it. Rejection MUST include a result condition and MAY include an error indication, which may be displayed to the dial-up user, after which the call should be disconnected. The initial connect notification may include the authentication information required to allow the LNS to authenticate the user and decide to accept or decline the connection. In the case of CHAP, the set-up packet includes the challenge, username and raw response. For PAP or text dialog, it includes username and clear text password. The LNS may choose to use this information to complete its authentication, avoiding an additional cycle of authentication. If the LAC negotiated PPP LCP [1] before initiating the tunnel, the initial connect notification may also include a copy of the LCP CONFREQ's sent in each direction which completed LCP negotiation. The LNS may use this information to initialize its own PPP state (thus avoiding an additional LCP negotiation), or it may choose to initiate a new LCP CONFREQ exchange. Valencia expires June 1999 [Page 8] INTERNET DRAFT October 1998 If the LNS accepts the connection, it creates a "virtual interface" for PPP in a manner analogous to what it would use for a direct- dialed connection. With this "virtual interface" in place, link layer frames may now pass over this tunnel in both directions. Frames from the remote user are received at the POP, stripped of CRC, link framing, and transparency bytes, encapsulated in L2TP, and forwarded over the appropriate tunnel. The LNS accepts these frames, strips L2TP, and processes them as normal incoming frames for the appropriate interface and protocol. The "virtual interface" behaves very much like a hardware interface, with the exception that the hardware in this case is physically located at the ISP POP. The other direction behaves analogously, with the LNS encapsulating the packet in L2TP, and the LAC stripping L2TP before transmitting it out the physical interface to the remote user. At this point, the connectivity is a point-to-point PPP session whose endpoints are the remote user's networking application on one end and the termination of this connectivity into the LNS's PPP support on the other. Because the remote user has become simply another dial-up client of the LNS, client connectivity can now be managed using traditional mechanisms with respect to further authorization, protocol access, and packet filtering. Accounting can be performed at both the LAC as well as the LNS. This document illustrates some Accounting techniques which are possible using L2TP, but the policies surrounding such Accounting are outside the scope of this specification. L2TP offers optional facilities which maximize compatibility with legacy client requirements; L2TP connect notifications for PPP clients can contain sufficient information for an LNS to authenticate and initialize its LCP state machine. With these facilities, the remote user need not be queried a second time for PPP authentication, nor undergo multiple rounds of LCP negotiation and convergence. These techniques are intended to optimize connection setup, and are not intended to deprecate any functions required by the PPP specification. 3.0 Service Model Issues There are several significant differences between the standard Internet access service and the Virtual dial-up service with respect to authentication, address allocation, authorization and accounting. The details of the differences between these services and the problems presented by these differences are described below. The mechanisms used for Virtual Dial-up service are intended to coexist with more traditional mechanisms; it is intended that an ISP's POP can simultaneously service ISP clients as well as Virtual dial-up clients. Valencia expires June 1999 [Page 9] INTERNET DRAFT October 1998 3.1 Security For the Virtual dial-up service, the ISP pursues authentication only to the extent required to discover the user's apparent identity (and by implication, their desired LNS). This may involve no more than detecting DNIS information when a call arrives, or may involve full LCP negotiation and initiation of PPP authentication. As soon as the apparent identity is determined, a call request to the LNS is initiated with any authentication information gathered by the ISP. If the LNS receives proxy authentication information (see section 6.11), it SHOULD assume that the PPP peer is in the authentication phase, awaiting an indication of success or failure. The LNS completes the authentication by either accepting the call, or rejecting it. The LNS may need to protect against attempts by third parties to establish tunnels to the LNS. Tunnel establishment can include authentication to protect against such attacks. 3.2 Address Allocation For a traditional Internet service, the user typically accepts that the IP address may be allocated dynamically from a pool of ISP addresses. This model often means that the remote user has little or no access to their home network's resources, due to firewalls and other security policies applied by the home network to accesses from external IP addresses. For the Virtual dial-up service, the LNS can exist behind the home firewall, allocating addresses which are internal (and, in fact, can be RFC 1918 addresses, or non-IP addresses). Because L2TP tunnels exclusively at the frame layer, the actual policies of such address management are irrelevant to correct Virtual dial-up service; for all purposes of PPP protocol handling, the dial-in user appears to have connected at the LNS. 3.3 Authentication The authentication of the user occurs in three phases; the first at the ISP, and the second and optional third at the LNS. The ISP uses DNIS, CLID, or a username to determine that a Virtual dial-up service is required and initiates the tunnel connection to the appropriate LNS. Once a tunnel is established, The ISP NAS allocates a new Call ID and initiates a session by forwarding the gathered authentication information. The LNS undertakes the second phase by deciding whether or not to accept the call. The call start indication may include CHAP, PAP, EAP, or textual authentication information. Based on this information, the LNS may accept the call request, or may reject it (for instance, it was a PAP request and the username/password are found to be incorrect). Once the call is accepted, the LNS is free to pursue a third phase of Valencia expires June 1999 [Page 10] INTERNET DRAFT October 1998 authentication at the PPP layer. These activities are outside the scope of this specification, but might include an additional cycle of LCP authentication, proprietary PPP extensions, or textual challenges carried via a TCP/IP TELNET session. 3.4 Accounting It is a requirement that both the LAC and the LNS be capable of providing accounting data and hence both may count packets, octets and connection start and stop times. Since Virtual dial-up is an access service, accounting of connection attempts (in particular, failed connection attempts) is of significant interest. The LNS can reject new connections based on the authentication information gathered by the LAC, with corresponding logging. For cases where the LNS accepts the connection and then continues with further authentication, the LNS might subsequently disconnect the client. For such scenarios, the disconnection indication back to the LAC may also include a reason. Because the LNS can decline a connection based on the authentication information collected by the LAC, accounting can easily draw a distinction between a series of failed call attempts and a series of brief successful connections. Lacking this facility, the LNS must always accept connection requests, and would need to exchange a number of PPP packets with the remote system. Note that the LNS could use this information to decide to accept the connection (which protects against most invalid connection attempts) while still insisting on running its own CHAP authentication (for instance, to protect against CHAP replay attacks). 4.0 Protocol Overview There are two parallel components of L2TP operating over a given tunnel: control messages between each LAC-LNS pair, and payload packets between the same LAC-LNS pair. The latter are used to transport L2TP encapsulated PPP packets for user sessions between the pair. Two fields important to the operation of L2TP are the Nr (Next Received) and Ns (Next Sent) fields which are always present in control messages, and are optionally present in payload packets. A single sequence number state is maintained for all control messages, and a distinct state is maintained for the payload of each user session within the tunnel. The Sequence number starts at 0, Each subsequent packet 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 packet 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 preceeding 32767 values, inclusive. For example, if the last received sequence number was 15, then packets with sequence numbers 0 through 15, as well as 32753 through 65536, would be considered less than or equal to, and would be silently discarded. Valencia expires June 1999 [Page 11] INTERNET DRAFT October 1998 Otherwise it would be accepted. In this document, the sequence number state for a control connection and each user session is represented for clarity in the following discussions by distinct pairs of state variables, Sr and Ss. Sr represents the value of the next in-sequence message expected to be received for a given session by a peer. Ss represents the sequence number to be placed in the Ns field of the next message sent for a given session by the sending peer. Each state is initialized such that the first message sent and the first message expected to be received for each session has an Ns value of 0. This corresponds to initializing Ss and Sr in both peers to 0 for each new session. As messages are sent for a given session, Nr is set in these messages to reflect one more than the Ns value of the highest (modulo 2**16) in-order message received for that session; if sent before any packet is received Nr will be 0, indicating that the peer expects the next new Ns value received to be 0. When a non-ZLB message is received with an Ns value that matches the session's current Sr value, Sr is incremented by 1 (modulo 2**16). It is important to note that, for both control and payload sessions, Sr is not modified if a message is received with a value of Ns greater than the current Sr value (exceptions to this rule being the permitted handling of out-of-order payload packets by the "simple receiver" discussed in Appendix C and handling of payload packets with the R bit set). For the control session, retransmission of outgoing messages should eventually provide the receiving peer with the expected message. For payload sessions, however, lost messages are never retransmitted so a mechanism involving the use of the "Reset Sr" (R bit) indicator in an outgoing message is used to update the peer's value of Sr to the value of Ns contained in the message. See Sec. 4.2 for details of this mechanism. Every time a peer sends a non-ZLB message it increments its corresponding Ss value for that session by 1 (modulo 2**16). This increment takes place after the current Ss value is copied to Ns in the message to be sent. Outgoing messages always include the current value of Sr for the corresponding session in their Nr field. A message (control or payload) with a zero-length body indicates that the packet is only used to communicate Nr and Ns fields. The Nr and Ns fields are filled in as above, but the sequence number state, Ss, is not incremented. Thus a ZLB message sent after a non-ZLB message will contain a new Ns value while a non-ZLB message sent after a ZLB message will contain the same value of Ns as the preceding zero- length message. Unless the Rbit (Reset Sr) is set, a peer receiving a zero-length message does not update its Sr variable. Upon receipt of an in-order non-ZLB message, the receiving peer must acknowledge the message by sending back the updated value of Sr in the Nr field of the next outgoing message. This updated Sr value can be piggybacked in the Nr field of any non-ZLB outgoing messages that the peer may happen to send back. Valencia expires June 1999 [Page 12] INTERNET DRAFT October 1998 If the peer does not have a message to transmit for a short period of time after receiving a non-ZLB message then it should send a ZLB message containing the latest values of Sr and Ss, as described above. The suggested value for this time interval is 1/4 the receiving peer's value of Round-Trip-Time (RTT - see Appendix A), if it computes RTT, or a maximum of 1/2 of its fixed timeout interval otherwise. This timeout should provide a reasonable opportunity for the receiving peer to obtain a payload message destined for its peer, upon which the ACK of the received message can be piggybacked. This timeout value should be treated as a suggested maximum; an implementation could make this timeout quite small without adversely affecting the protocol. To provide for better throughput, the receiving peer should skip this timeout entirely and send a ZLB message immediately in the case where its receive window fills and it has no queued data to send for this connection or it can't send queued data because the transmit window is closed. A suggested implementation of this timer is as follows: Upon receiving a non-ZLB message, the receiver starts a timer that will expire in the recommended time interval. A variable, Lr (Last Nr value sent), is used by the transmitter to store the last value sent in the Nr field of a transmitted payload message for this connection. Upon expiration of this timer, Sr is compared to Lr and, if they are not equal, a ZLB ACK is issued. If they are equal, then no ACK's are outstanding and no action needs to be taken. This timer should not be reinitialized if a new message is received while it is active since such messages will be acknowledged when the timer expires. This ensures that periodic ACK's are issued with a maximum period equal to the recommended timeout interval. This interval should be short enough to not cause false acknowledgment timeouts at the transmitter when payload messages are being sent in one direction only. Since such ACK's are being sent on what would otherwise be an idle data path, their affect on performance should be small, if not negligible. See Appendix E for some examples of how sequence numbers progress. 4.1 Control Message Overview Before PPP tunneling can occur between an LAC and LNS, control messages must be exchanged between them. Control messages are exchanged over the same tunnel which will be used to forward payload data once L2TP call control and management information have been passed. The control messages are responsible for establishment, management, and release of sessions carried through the tunnel, as well as status on the tunnel itself. It is the means by which an LNS is notified of an incoming call at an associated LAC, as well as the means by which an LAC is instructed to place an outgoing call. A tunnel may be established by either an LAC (for incoming calls) or an LNS (for outgoing calls). Following the establishment of Valencia expires June 1999 [Page 13] INTERNET DRAFT October 1998 the tunnel, the LNS and LAC configure the tunnel by exchanging Start-Control-Connection-Request and -Reply messages. These messages are also used to exchange information about basic operating capabilities of the LAC and LNS. Once the control message exchange is complete, the LAC may initiate sessions by indicating inbound requests, or the LNS by requesting outbound calls. If both ends of the tunnel have the ability to act as an LAC and LNS concurrently, then nothing prohibits establishing incoming or outgoing calls from both sides of the same tunnel. Control messages may indicate changes in operating characteristics of an individual user session with a Set-Link-Info message. Individual sessions may be released by either the LAC or LNS, also through control messages. Independent Call ID values are established for each end of a user session. The sender of a packet associated with a particular session places the Call ID established by its peer in the Call ID header field of all outgoing packets. For the cases where a Call ID has not yet been assigned from the peer (i.e., during call establishment of a new session), the Call ID field is sent as 0, and further fields within the message are used to identify the session. The Call ID value of 0 is thus special and MUST NOT be used as an Assigned Call ID. A mechanism for detection of tunnel connectivity problems is provided by the reliable transport layer of L2TP. The transport layer of L2TP performs control message retransmission. If the number of retransmission attempts for a given control message exceeds a configured maximum value, the tunnel is reset. This retransmission mechanism exists in both the LNS and LAC ends of the tunnel. A keepalive mechanism is employed by the L2TP higher layer in order to differentiate tunnel outages from extended periods of no control or data activity on a tunnel. This is accomplished by the higher layer injecting Hello control messages into the control stream after a specified period of time elapses since the last data or control message was received on the tunnel. As for any other control message, if the transport does not receive an ACK for the Hello message after the normal number of retransmissions the tunnel is declared down and is reset. The transport layer reset 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 in a timely manner. It is intended that control messages will also carry management related information in the future, such as a message allowing the LNS to request the status of a given LAC; these message types are not defined in this document. 4.2 Payload Packet Overview Once a tunnel is established and control messages have completed tunnel setup, the tunnel can be used to carry user session PPP Valencia expires June 1999 [Page 14] INTERNET DRAFT October 1998 packets for sessions involving a given LNS-LAC pair. The "Call ID" field in the L2TP header indicates to which session a particular PPP packet belongs. In this manner, PPP packets are multiplexed and demultiplexed over a single tunnel between a given LNS-LAC pair. The "Call ID" field value is established during the exchange of call setup control messages. It is legal for multiple tunnels to exist between a given LNS-LAC pair. This is useful where each tunnel is used for a single user session, and the tunnel media has specific QOS attributes dedicated to a given user. L2TP provides a tunnel identifier so that individual tunnels can be identified, even when arriving from a single source LAC or LNS. The L2TP header also contains optional acknowledgment and sequencing information that can be used to provide flow-control across the underlying medium (which may be an internetwork) as well as congestion control in the network itself (see section 4.3). In this document, these mechanisms will be referred to collectively as "flow control". Control messages are used to determine rate and buffering parameters that are used to regulate the flow of PPP packets for a particular session over the tunnel. The receiving peer indicates whether flow control is to be performed for payload packets sent to it. If a peer issues a Receive Window Size AVP with a non-zero value during session establishment, then the sending peer MUST abide by the indicated window size value as long as sequence numbers are provided. If a receiving peer does not wish to flow control the payload packets sent to it, it should not issue the Receive Window Size AVP with a non-zero value. Issuing a Receive Window Size AVP with a zero value has special significance. It indicates that the receiver does not want to perform flow-control but it does want the sending peer to provide Ns values in payload packets so that it can detect lost packets or packets received out of order. A peer SHOULD NOT send ZLB ACK's when its advertised Receive Window is zero or not present (flow control is not requested). In the case where neither peer issues a Receive Window Size AVP during session establishment, the optional Nr and Ns fields are absent in all payload packets for that session. In the case where either peer wishes to perform flow-control or to detect out-of- order receive messages (as indicated by the sending of the Receive Window Size AVP with non-zero or zero value, respectively) the Nr and Ns fields MUST be present in payload packets sent by both peers. A proper Ns value starts at 0 and increments by one for each transmitted payload message and a proper Nr value is the current value of the receive sequence number state variable, Sr. See Appendix F for a table detailing when to send sequence numbers with regard to the Receive Window AVP. Unless the LAC sends the Sequencing Required AVP (see section 6.7 and 6.8) in the ICCN or OCCN message, the LNS has the authority to dynamically enable or disable sending of Ns/Nr and hence Valencia expires June 1999 [Page 15] INTERNET DRAFT October 1998 controlling the capability of loss detection, reordering and flow control over the link. To disable sequence numbers, the LNS sends a packet with the F bit set to 0 and Ns/Nr fields not present. The LAC, upon receiving such a data packet, MUST process the packet and discontinue inclusion of Ns/Nr fields in any subsequent data packets. Any packets which have been received by L2TP but are being held in queue for reordering SHOULD be flushed without waiting for an ACK from the peer (as if an R bit packet with Ns equal to the current Sr value was received). Ss and Sr should be updated and saved accordingly. All data packets will continue to be exchanged without sequence numbers until the end of the session or until the LNS resumes sequence numbers by sending a packet with the F bit set and Ns/Nr present. The LAC, upon receiving a packet with the F bit set, MUST resume sending sequence numbers in further packets. In order to properly resume, the LNS and LAC MUST preserve the state of Ss and Sr between periods of disabled sequencing. While the LNS may initiate disabling of sequencing at any time during the session (including the first data packet sent), it is recommended that for links 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 instance, if the PPP session being tunneled is not utilizing any stateful compression or encryption protocols and is only carrying IP (as determined by the NCP's that are established), then the LNS might decide to disable sequencing, thus allowing higher level protocols to perform necessary flow control end to end and reducing the per packet L2TP processing burden on the LNS substantially. Further discussion of some of the tradeoffs associated with disabling sequencing over media which may reorder or silently drop packets is given in section 8.2. 4.3 Flow Control If a receiving peer offers a non-zero receive window size to a sending peer then the sending peer MUST abide by this window size value as long as sequence numbers are being exchanged (See Appendix F for details of when flow control is enabled in relation to sending of the receive window AVP). The sending peer MUST stop sending payload packets when the window is full; i.e., x consecutive messages have been sent but have not been acknowledged, where x is the value of the Receive Window Size AVP. Implementors should take care to avoid the situation where loss of an ACK by a sending peer with a full transmit window causes a session to hang forever, due to the fact there are no retransmissions of payload packets. Steps must be taken to reopen the transmit window (at least to a value of 1) upon expiration of an ACK wait timeout. See Appendix B for more details. When sending to a peer that has issued a non-zero receive window size, the sending peer is responsible for resetting the receiver's Sr value when a sent payload message is lost during transmission. Valencia expires June 1999 [Page 16] INTERNET DRAFT October 1998 When a sent message is lost, the receiving peer's Sr value (and hence the Nr value it sends) will "stick" at the Ns value of the first missing payload message. The "Reset Sr" (R bit) in the payload message header (see Section 5.3) provides a mechanism for the sending peer to indicate to the receiver that it (the sending peer) recognizes that at least one payload message has been lost and that the receiving peer should now reset its Sr value beyond the lost message(s). If the sending peer is performing adaptive window adjustment (see Appendix B.1) then it is this recognition of a lost message that is used to indicate that a window adjustment at the sending peer should be performed. The sender may use a timer mechanism similar to that used to retransmit lost control messages to determine when transmitted payload packets have been lost. When the timer expires, a payload message (zero or non-zero length) with the R bit set can be issued to indicate to the receiver that it needs to reset its Sr value. Upon receipt of a payload message with the R bit set, the receiver resets Sr to the value of Ns contained in the message, or, if highly congested, to a value between its current value and the value of Ns contained in the message. Upon receipt of a payload message with R bit set, the receiver takes the following actions: First, the receiver checks for the presence of the R bit in a received payload message before comparing the message's Ns value to its Sr value. If the R bit is set, the receiver will typically set its Sr value equal to that of Ns contained in the message and fall through to normal receive message processing in which Sr will be incremented (modulo 2**16) if the message is non-ZLB and will remain the same if it is ZLB. However, if the receiver is known to be heavily congested, it MAY choose to not update or set its new Sr value between (modulo 2**16) the current Sr value and that of Ns contained in the message. This effectively spoofs the transmitter into believing that the R bit packets that have been sent are not being received, ultimately causing the transmitter to backoff more quickly. In order to prevent an R bit message received out of order from setting Sr to an old value, the receiving peer should compare the value of Ns in an R bit message to its current value of Sr. The receiving peer should reset its Sr value only if Ns is greater than (modulo 2**16) its current value of Sr. The sender of the R bit can decide whether it wishes to advance the receiver's Sr value to the value just past the highest (modulo 2**16) Nr value received (the Ns value of the message just past that of the first lost message) or to its current value of Ss. Resetting it to that just past the first lost message enables the sender to determine if other messages in the same transmit window were also lost. Setting it to the current Ss value of the sender treats losses of multiple messages in the same window the same as the loss of a single message. An implementation may use either, or a combination of both methods. If the transmitter detects that the receiver is heavily congested, piggybacking the R bit on data Valencia expires June 1999 [Page 17] INTERNET DRAFT October 1998 packets should be refrained in favor of a ZLB with the R bit set for resetting the receiver's Sr. It is permissible for a sending peer to set the R bit (and hence reset the transmit window) in all transmitted payload packets as an indication that flow control has been disabled at the transmitter. Receipt of an R bit is NOT an explicit indication to immediately flush all packets which might be in queue to PPP for processing. There are a number of tradeoffs as to precisely when a receiver should decide to pass packets from L2TP to PPP, many dependent on what protocols are being carried by PPP. In general, packets should be declared lost and passed to PPP in a timely enough manner so as to not cause retransmissions by reliable higher layer protocols due to packets that are held in queue by l2tp. L2TP does not specify the particular timeout algorithms to use for flow control. Suggested algorithms for the determination of adaptive timeouts to recover from dropped data or acknowledgments on the tunnel are included in Appendix A of this document. Additional examples for sequencing and flow control are included in Appendix E. 5.0 Message Format and Protocol Extensibility L2TP defines a set of control messages sent in packets over the tunnel between an LNS and a given LAC. The exact technique for initiating a tunnel between an LNS-LAC pair is specific to the tunnel media, and specific media are described in section 8.0. Once media-level connectivity is reached, L2TP message formats define the protocol for an LAC and LNS to manage the tunnel and its associated sessions. In each case where a field is optional, if the field is not present, its space does not exist in the packet. Existing fields are placed back-to-back to form the packet. 5.1 AVP 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 an AVP (Attribute- Value Pair) in the remainder of this document. Each AVP is encoded as: Valencia expires June 1999 [Page 18] INTERNET DRAFT October 1998 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|0|0|0|0| Overall Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [until Overall Length is reached]... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first six bits are a bit mask, describing the general attributes of the AVP. The 0 bits indicate reserved bit fields and MUST be set to 0. An AVP received with a reserved bit set to 1 MUST be treated as an unrecognized AVP, unless the reserved bit is defined for an extension that is known to the implementation. The M bit, known as the "mandatory" bit, controls the behavior required of an implementation which receives an AVP which it does not recognize. If M is set on an unrecognized AVP associated with call (session) management, any session associated with this AVP MUST be terminated. If M is set on an unrecognized AVP associated with the overall tunnel, the entire tunnel (and all sessions within) MUST be terminated. If M is not set, an unrecognized AVP MUST be ignored. The H bit, known as the "hidden" bit, controls the hiding of the data in the 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 5.7 describes the procedure for performing AVP value hiding. Overall Length encodes the number of octets (including the Overall Length field itself) contained in this AVP. It is 10 bits, permitting a maximum of 1023 octets of data in a single AVP. Vendor ID is the IANA assigned "SMI Network Management Private Enterprise Codes" [12] value, encoded in network byte order. The value 0, reserved in this table, corresponds to IETF adopted Attribute values defined within this document. Any vendor wishing to implement L2TP extensions can use their own Vendor ID along with private Attribute 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 various organizations to design and define non-standard attributes. This limits the ability to define new proprietary AVP implementations to the first 65,535 enterprises. Attribute is the actual attribute, a 16-bit value specified in network byte order with a unique interpretation across all AVP's defined under a given Vendor ID. Value follows immediately after the Attribute field, and runs for Valencia expires June 1999 [Page 19] INTERNET DRAFT October 1998 the remaining octets indicated in the Overall Length (i.e., Overall Length minus six octets of header). AVP's should be kept compact; the combined AVP's within a control message MUST NOT ever cause a control message's total length to exceed 1500 octets in length. 5.2 Control Message Format Each L2TP control message begins with a 12 octet header portion followed by an 8 octet Message Type AVP and zero or more AVP's. 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|0|0|F|0|0|0|0|0|0|0|0| Ver | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns | Nr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type AVP... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 0 bits indicate reserved bit fields and MUST be set to 0. A control message received with a reserved bit set to 1 in the header MUST be treated as an unrecognized control message, unless the bit is defined for an extension that is known to the implementation. The L and F bits must be 1, indicating that the length, Ns and Nr fields are present. The T bit MUST be 1, indicating a control message. Ver MUST be the value 2, indicating a version 1 L2TP message (the value 1 is reserved to permit detection of L2F [2] packets should they arrive intermixed, the value 0 is undefined). Length is the overall length of the message specified in network byte order. Calculation of the length includes the L2TP header, message type AVP, plus any additional AVP's associated with a given control message type. Tunnel ID and Call ID identify the tunnel and user session within the tunnel to which a control message applies. If a control message does not apply to a single user session within the tunnel (for instance, a Stop-Control-Connection-Notification message), Call ID MUST be set to 0. If an Assigned Tunnel ID has not yet been received from the peer, Tunnel ID MUST be set to 0. Once an Assigned Tunnel ID is received, all further packets MUST be sent Valencia expires June 1999 [Page 20] INTERNET DRAFT October 1998 with Tunnel ID set to the indicated value. Note that the Assigned Tunnel ID and Call ID SHOULD be selected in an unpredictable manner rather than sequentially or otherwise. Doing so will help to deter hijacking of a session by a malicious user who does not have access to packet traces between the LAC and LNS. Ns is copied from the send sequence number state variable, Ss, at the time the message is transmitted. Ss is incremented after copying if the control message is not a ZLB ACK. Nr is copied from the receive sequence number state variable, Sr, and indicates the sequence number, Ns, + 1 of the highest (modulo 2**16) in- sequence message received. See section 4.0. 5.3 Payload Message Format PPP payload packets tunneled within L2TP have a smaller encapsulation than the L2TP control message header, reducing overhead of L2TP during the life of a tunneled PPP session. The LNS is expected to be able to process user data packets of at least the default MRU for PPP, not including L2TP and media encapsulation. The L2TP header has an optional padding field to allow for alignment correction if desired. The smallest L2TP encapsulation is 6 octets; the largest is 14 octets (plus padding octets, if present). See section 8.1 for further MTU considerations. 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|R|0|F|0|S|P|0|0|0|0|0| Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns (opt) | Nr (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt) | Offset pad... (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 0 bits indicate reserved bit fields and MUST be set to 0. A packet received with a reserved bit set to 1 in the payload message header MUST be silently discarded, unless the bit is defined for an extension that is known to the implementation. The T bit MUST be 0, indicating payload. Ver MUST be 2, indicating version 1 of the L2TP protocol. If the L bit is set, the Length field is present, indicating the total length of the packet sent. The R bit, "Reset Sr", is used for flow control and indicates that the receiver SHOULD reset its receive state variable, Sr, for this session to the value contained in the Ns field of this message header. Sr is reset to the value of Ns only if Ns is greater than Valencia expires June 1999 [Page 21] INTERNET DRAFT October 1998 (modulo 2**16) the receiver's current value of Sr. Normal receive processing of the message is performed after the value of Sr is reset. Note that if the F bit is not set, then this bit MUST be 0. See section 4.2 for a detailed discussion of the use of this bit for flow control on the data channel. See Appendix E for examples of proper R bit usage. If the F bit is set, both the Nr and Ns fields MUST be present. Ns indicates the sequence number of the packet being sent. The Ns value of a message being transmitted is copied from the current value of the send sequence number state variable, Ss. Ss is incremented by one (modulo 2**16) after copying to the Ns field only if the message being sent is not a ZLB ACK. Nr indicates the sequence number of the next in-order message sequence number to be received (if the last in-order non-ZLB data packet had Ns set to 1, the Nr sent back would be 2). The value of Nr is copied from the current receive state variable, Sr. Together, Nr and Ns can be used to handle out-of-order packets and, together with the R bit, to provide flow control for the connection. An L2TP peer setting the F bit, and placing Nr and Ns fields in its messages, MUST have previously received or sent a Receive Window Size AVP during establishment of the session. The Nr and Ns fields are present and updated as described in section 4.0 if either side has specified an intention to do payload flow control. The Offset Size field is present if the S bit is set in the header flags. This field specifies the number of octets past the L2TP header at which the payload data is expected to start. It is recommended that data thus skipped be initialized to 0's. If Offset Size is 0, or the S bit is not set, the first octet following the last octet of L2TP header is the first octet of payload data. If the P bit is set, this packet should receive preferential treatment at the LAC in its queuing for transmission to the client. LCP echo requests used as a keepalive for the link, for instance, should generally be sent from the LNS with this bit set. Without it, a temporary interval of congestion of the transmission queues could result in the interference with keepalive messages and unnecessary loss of the link. 5.4 Control Message Types Control message and AVP types defined in this specification exist under Vendor ID 0, indicating IETF defined behavior. The actual message and AVP semantics are defined in the next section. This section includes tables that summarize all currently defined message and AVP types. Note that while an AVP may legally occur under more than one type of control message, an AVP's specific interpretation is unique to the specific control message. Each message type entry in the table below indicates: the integer value assigned to the message type; the message type abbreviation Valencia expires June 1999 [Page 22] INTERNET DRAFT October 1998 used in the AVP Summary Table of Sec. 5.5; and the full name of the message type. The integer value assigned to each message type is placed in the Value field of the Message Type AVP. This AVP MUST be the first AVP in a message. The currently defined control message types, grouped by function, are: Control Connection Management 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 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 5.5 AVP Summary The following table lists all standard L2TP attributes currently defined. The "Attr" column indicates the integer value assigned to this attribute. The "M" column indicates the setting of the "Mandatory" bit of the AVP header for each attribute. The "Len" field indicates the size of the AVP including the AVP header. A "+" in this column indicates that the length varies depending upon the length of the actual contents of the value field. The "(usage)" list for each entry indicates the message types that utilize each AVP (See command table of Sec. 5.4). An abbreviation shown in mixed or upper case letters indicates that the corresponding AVP MUST be present in this message type; All lower case indicates that the AVP may optionally appear in this message type. Some AVPs MUST be present only when a corresponding optional AVP is present, these AVPs are shown in lower case as well. Valencia expires June 1999 [Page 23] INTERNET DRAFT October 1998 A brief summary of the type and contents of the value field for each attribute is also given for each entry. Refer to the individual message type descriptions that appear in Section 6 for further details about the use of a particular AVP in a particular message type. This table is provided only as a convenient overview of AVPs, individual message AVP descriptions always enjoy priority to summary descriptions provided in this table. Attr M Len Attribute Name (usage) 0 1 8 Message Type (ALL MESSAGES) 16-bit integer value indicating the message type, as defined in table above. MUST be the first AVP in each message 1 1 10+ Result Code (CDN, StopCCN) 16-bit Integer value indicating result of corresponding request or reason for issuing a request, 16-bit integer General Error code and an optional ASCII string error message. See Result and General Error code tables below. 2 1 8 Protocol Version (SCCRP, SCCRQ) 8-bit L2TP Protocol and Revision numbers 3 1 10 Framing Capabilities (SCCRP, SCCRQ) 32-bit bitmask indicating supported framing types (e.g., synchronous and asynchronous) 4 1 10 Bearer Capabilities (sccrp, sccrq) 32-bit bitmask indicating supported bearer types (e.g., analog and digital) 5 0 14 Tie Breaker (sccrq) 8 octet value used to break control connection establishment collisions 6 0 8 Firmware Revision (sccrp, sccrq) 16-bit integer representing vendor's firmware revision 7 1 6+ Host Name (SCCRP, SCCRQ) ASCII string name (e.g., DNS name) of issuer 8 0 6+ Vendor Name (sccrp, sccrq) ASCII string describing issuing device 9 1 8 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 16-bit integer tunnel ID assigned by sender 10 1 8 Receive Window Size (iccn, icrp, occn, ocrq, sccrp, sccrq) 16-bit integer receive window size offered by sender for a given call or control session 11 1 6+ Challenge (sccrp, sccrq) 1 or more octet value issued by sender wishing to authenticate Valencia expires June 1999 [Page 24] INTERNET DRAFT October 1998 control session peer 12 1 9+ Q.931 Cause Code (cdn) 16-bit cause code, 1 octet cause message, and optional ASCII advisory message 13 1 22 Challenge Response (scccn, sccrp) 16 octet CHAP type response to peer's Challenge 14 1 8 Assigned Call ID (CDN, ICRP, ICRQ, OCRP, OCRQ) 16-bit integer ID assigned to a call by sender 15 1 10 Call Serial Number (ICRQ, OCRQ) 1 or more octet identifier assigned to a call 16 1 10 Minimum BPS (OCRQ) 32-bit integer indicating lowest acceptable line speed for call 17 1 10 Maximum BPS (OCRQ) 32-bit integer indicating highest acceptable line speed for call 18 1 10 Bearer Type (icrq, OCRQ) Indicates bearer type (i.e., analog or digital) for call 19 1 10 Framing Type (ICCN, OCCN, OCRQ) Indicates framing type (i.e., synchronous or asynchronous) for call 20 1 8 Packet Processing Delay (iccn, icrp, occn, ocrq) 16-bit integer estimate of processing time of full window of received packets by sender 21 1 6+ Dialed Number (icrq, OCRQ) ASCII string phone number called or to be called 22 1 6+ Dialing Number (icrq) ASCII string phone number of caller 23 1 6+ Sub-Address (icrq, ocrq) ASCII string containing additional dialing information 24 1 10 (Tx) Connect Speed (ICCN, OCCN) 32-bit integer representing actual (or transmit) line speed of connection 25 0 10 Physical Channel ID (icrq, ocrp) 32-bit vendor specific physical device identifier used for call 26 0 6+ Initial Received LCP CONFREQ (iccn) Octet string containing initial CONFREQ received from client 27 0 6+ Last Sent LCP CONFREQ (iccn) Octet string containing final CONFREQ sent to client Valencia expires June 1999 [Page 25] INTERNET DRAFT October 1998 28 0 6+ Last Received LCP CONFREQ (iccn) Octet string containing final CONFREQ received from client 29 0 8 Proxy Authen Type (iccn) 16-bit integer code indicating client authentication type negotiated (e.g., PAP, CHAP) 30 0 6+ Proxy Authen Name (iccn) ASCII string containing name returned by client in authentication response 31 0 6+ Proxy Authen Challenge (iccn) Octet string Challenge presented by LAC to client 32 0 8 Proxy Authen ID (iccn) 16-bit integer of which low order octet is ID presented to client with Challenge. High order octet must be 0. 33 0 6+ Proxy Authen Response (iccn) Octet string CHAP response or ASCII string password depending on authentication type used 34 1 32 Call Errors (WEN) A reserved 16-bit word set to 0 followed by 6 32-bit integer connection error counters 35 1 16 ACCM (SLI) A reserved 16-bit word set to 0 followed by 2 32-bit bitmasks containing Send and Receive ACCM values respectively 36 1 6+ Random Vector (all messages) Variable length octet string containing a random sequence of values used to accomplish the optional "hiding" of other AVP values (See "H" bit description in Sec. 5.7). 37 0 6+ Private Group ID (iccn) Variable length octet value used by the LAC or LNS to indicate that this call is to be associated with a particular customer group. 38 0 10 Rx Connect Speed (iccn, occn) 32-bit integer representing actual receive line speed of connection. Suggests possibility of asymmetric connection. 39 1 6 Sequencing Required (iccn, occn) If present, indicates to the LNS that it MUST NOT dynamically disable sequencing. 5.6 Result and Error Code Summary The StopCCN and CDN message types contain a Result Code AVP which indicates the result of the previously requested operation. The Result Code can indicate that additional information pertaining to an error situation can be found in the Error Code field of the Result Valencia expires June 1999 [Page 26] INTERNET DRAFT October 1998 Code AVP. The meaning of the result code is tabulated under the specific type of message containing the result. Each 16-bit Result Code is immediately followed (in the same AVP) by a 16-bit General Error code value. General error codes pertain to types of errors which are not specific to any particular L2TP request, but rather to protocol or message format errors. If an L2TP reply indicates in 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 Call 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. If the length of the Result Code AVP specifies that the Value field is more than four octets in length, the remaining octets after the General Error Code field are an arbitrary string providing further (possibly 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 [18]. Generally, when a General Error Code of 6 is used, additional information about the error will be included in the Optional Message field that follows the Error Code field in the Result Code AVP. 5.7 Hiding of AVP values The H ("Hidden") bit in the header of each AVP in a control message 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 ID's. The H bit MUST NOT be set in the Random Vector AVP or Message Type AVP. The H bit MUST only be set if a shared secret exists between the peers on either end of the tunnel. AVPs involved in the establishment of the tunnel, or reporting errors involved in the establishment of the tunnel MUST NOT be hidden. These AVPs are the "Host Name" AVP in the SCCRQ and SCCRP message, the "Assigned Tunnel ID" in the SCCRQ, SCCRP, and StopCCN message and the "Result Code" in the StopCCN message. If the H bit is set in any AVP(s) in a given command message, a Random Vector AVP must also be present in the message and MUST precede the first AVP having an H bit of 1. Valencia expires June 1999 [Page 27] INTERNET DRAFT October 1998 The length of the AVP value to be hidden is first encoded in the form of 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 Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Padding ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length This is length of the Original Value to be obscured in octets. Original Value Value of hidden AVP that is to be obscured. Padding Random additional octets used to obscure length of the Original Value. The resulting subformat MAY be padded to a multiple of 16 octets in length. For example, if the Original Value to be obscured is a string containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 octets of padding would be applied. Padding does NOT alter the value placed in the Length of the Original Value, only the length of the AVP itself. Next, An MD5 hash is performed on the concatenation of: - the 2 octet Attribute number of the AVP (in network order) - the shared authentication 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 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 Value field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, the Subformat is transformed as if the 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. Valencia expires June 1999 [Page 28] INTERNET DRAFT October 1998 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 method is taken from the book "Network Security" by Kaufman, Perlman and Speciner [4] pages 109-110. A more precise 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'll need intermediate values b1, b2, etc. b1 = MD5(AV + S + RA) 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. For more details on this hiding method, consult RFC 2058 [8]. The Random Vector AVP has the following format: Random Vector 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + String length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 36 | Random Octet String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Random Vector AVP may be used in any message type. The Attribute value is 36 and it is marked mandatory. It is used to enable the hiding of the values of arbitrary AVPs. It MUST precede any AVP containing an AVP with the H bit set but it MUST NOT itself have the H bit set. More than one Random Vector AVP may appear in a message, in which case the one most closely preceding an AVP with the H bit set pertains to that AVP. The Random Octet String is the random vector value to use in computing the MD5 hash to retrieve the original value of a hidden AVP. This string can be of arbitrary length, although a random vector of at least 16 octets is recommended. The only AVP that the Random Vector AVP MUST NOT precede is the Message Type AVP (which is always the first AVP in a message). Valencia expires June 1999 [Page 29] INTERNET DRAFT October 1998 6.0 Control Connection Protocol Specification Control Connection messages are used to establish and clear user sessions. The first set of Control Connection messages are used to maintain the control connection itself. The control connection is initiated by an LAC or LNS after establishing the underlying tunnel- over-media connection. 6.0.1 Control Connection Collision For the case where an LAC and LNS both initiate tunnels to each other concurrently, and where the LAC and LNS both determine that a single tunnel suffices (generally because of media characteristic considerations, for instance, whether individual tunnels are needed to gain QOS guarantees for each tunnel), a "tie breaker" may be undertaken. The details of breaking a tie are documented with the tunnel establishment messages (Sec. 6.1). 6.0.2 Reliable Delivery of Control Messages Since L2TP may run across media where packets may be lost, an L2TP peer sending a control message will retransmit the control message after deciding that its remote peer has not received it. The reliable transport mechanism built into L2TP is essentially a lower layer transport service; the Nr and Ns fields of the control message header belong to this transport layer. The higher layer functions of L2TP are not concerned with retransmission or ordering of control messages. Each tunnel maintains a queue of control messages to be transmitted to the 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 fixed (a recommended default is 1 second) or adaptive (see Appendix D) timeout interval expires without receiving such an acknowledgment, the control message packet is retransmitted. The retransmitted packet contains the same Ns value, but the Nr value MUST be updated with the current value of Sr to reflect any packets received in the interim. Each subsequent retranmission of a packet MUST employ an exponential backoff interval. Thus, if the first retransmission occurred after 1 second, the next retransmisssion 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), 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. This permits reliable delivery of closing messages in environments where these closing messages might be dropped. Valencia expires June 1999 [Page 30] INTERNET DRAFT October 1998 A peer MUST NOT withhold acknowledgment of packets 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. A sliding window mechanism is used, by default, for control message transmission. The default is to permit four control messages to be outstanding on a given tunnel. Consider two peers A & B. Suppose A specifies a Receive Window Size AVP with a value of N in the Start-Control-Connection-Request or -Reply packets. B is now allowed to have up to N outstanding control messages. Once N have been sent, however, 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. Unlike payload sessions, a value of 0 for the Receive Window Size AVP is invalid for a control session. When transmitting control messages, an implementation SHOULD utilize a slow start method and window adjustment procedure as described in Appendix B. The transport layer at a receiving peer is responsible for making sure that control messages are delivered in order to the higher layer and that duplicate messages are not delivered to the higher layer. 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. 6.0.3 Control Message Format The following Control Connection messages are all sent as packets on the established tunnel connection between a given LNS-LAC pair. 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. Each control message has a header, specified in section 5.2, including an AVP indicating the type of control message, followed by zero or more AVP's appropriate for the given type of control message. Each control message is described first at a block level, and then with details of each AVP. 6.1 Start-Control-Connection-Request (SCCRQ) The Start-Control-Connection-Request is an L2TP control message used to initialize the tunnel between an LNS and an LAC. The tunnel must be initialized through the exchange of these control messages before any other L2TP messages can be issued. The establishment of the control connection is started by the initiator of the underlying tunnel. Valencia expires June 1999 [Page 31] INTERNET DRAFT October 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Control-Connection-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version | | Framing Capabilities | | Bearer Capabilities | | Tie Breaker | | Firmware Revision | | Host Name | | Vendor Name | | Assigned Tunnel ID | | Receive Window Size | | Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 1, indicating Start- Control-Connection-Request. The Flags indicate a mandatory option. Details associated with this tunneled session follow in additional AVP's within the packet. Protocol Version 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 0x01 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Protocol Version AVP within a Start-Control-Connection-Request packet indicates the L2TP protocol version available. The Attribute value is 2, indicating Protocol Version, and is marked mandatory. This AVP MUST be present. The Value field is a 16-bit hexadecimal value 0x100, indicating L2TP protocol version 1, revision 0. Valencia expires June 1999 [Page 32] INTERNET DRAFT October 1998 Framing Capabilities 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 |0|0|0|0|0|0|A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Framing Capabilities AVP within a Start-Control-Connection- Request indicates the type of framing that the sender of this message can provide. The Attribute value is 3, indicating Framing Capabilities, and is marked mandatory. This AVP MUST be present. The Value field is a 32-bit quantity, with two bits defined. If bit A is set, asynchronous framing is supported. If bit S is set, synchronous framing is supported. This AVP provides the peer with an indication of the types of framing that will be accepted or initiated by the sender. A peer should not initiate 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. Bearer Capabilities 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 |0|0|0|0|0|0|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Bearer Capabilities AVP within a Start-Control-Connection- Request indicates the bearer capabilities that the sender of this message can provide for outgoing calls. The Attribute value is 4, indicating Bearer Capabilities, and is marked mandatory. This AVP MUST be present if the sender can place outgoing calls when requested. The Value field is a 32-bit quantity with two bits defined. If bit A is set, analog access is supported. If bit D is set, digital access is supported. This AVP provides the peer with an indication of the bearer device types supported by the hardware interfaces of the sender for outgoing calls. An LNS should not initiate 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 Valencia expires June 1999 [Page 33] INTERNET DRAFT October 1998 during control connection establishment. Attempts to do so will result in the call being rejected. 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 in the Value field 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 the appropriate bits in the Value field of this AVP. Presence of this message is not a guarantee that a given outgoing call will be placed by the sender if requested, just that the physical capability exists. Tie Breaker 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0| 14 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | Tie Break Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...(64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Tie Breaker AVP within a Start-Control-Connection-Request contains a 64-bit Value used to break ties in tunnel establishment between an LAC-LNS pair. The Attribute value is 5, indicating Tie Breaker, and is marked optional. This AVP itself is optional. The 8 octet Value is used as a 64-bit tie breaker value. If present, it indicates the sender wishes a single tunnel to exist between the given LAC-LNS pair, and this value will be used to choose a single tunnel where both LAC and LNS initiate a tunnel concurrently. The recipient of a Start-Control-Connection-Request must check to see if a Start-Control-Connection-Request 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. If a tie breaker is received, and the outstanding Start-Control- Connection-Request 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. It is recommended that the Value be set to the MAC address of a LAN interface on the sender. If no MAC address is available, a 64-bit random number should be used instead. Valencia expires June 1999 [Page 34] INTERNET DRAFT October 1998 Firmware Revision 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | Firmware Revision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Firmware Revision AVP within a Start-Control-Connection- Request indicates the firmware revision of the issuing device. The Attribute value is 6, indicating Firmware Revision, and is marked optional. This AVP itself is optional. The Value field is a 16-bit 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. Host Name 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 6 + Host name len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | Host name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Host Name AVP within a Start-Control-Connection-Request indicates the name of the issuing LAC or LNS. The Attribute value is 7, indicating Host Name, and is marked mandatory. This AVP itself MUST be present. This name should be as broadly unique as possible; for hosts participating in DNS [4], a hostname with fully qualified domain would be appropriate. Vendor Name 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3|0|0|0|0|0|0| 6+Vendor Name len| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 | Vendor name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Vendor Name AVP within a Start-Control-Connection-Request contains a vendor specific string describing the type of LAC or LNS being used. The Attribute value is 8, indicating Vendor Name, and is marked optional. This AVP itself is optional. The Value is the indicated number of octets representing the vendor string. Valencia expires June 1999 [Page 35] INTERNET DRAFT October 1998 Assigned Tunnel ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Tunnel ID AVP within a Start-Control-Connection- Request specifies the Tunnel ID which the receiving peer MUST use in the Tunnel ID field of all subsequent packets. The Attribute value is 9, indicating Assigned Tunnel ID, and is marked mandatory. This AVP MUST be present. Before the Assigned Tunnel ID AVP is received, packets MUST be sent with a Tunnel ID value of 0. The Value is a 16-bit non-zero Tunnel ID value. Receive Window Size 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Receive Window Size AVP within a Start-Control-Connection- Request specifies the receive window size being offered to the remote peer. The Attribute value is 10, indicating Receive Window Size, and is mandatory. This AVP itself is optional. Value is a 16-bit word indicating the offered window size. If absent, the peer must assume a value of 4 for its transmit window. The remote peer may send the specified number of control messages before it must wait for an acknowledgment. Challenge 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 6 + Challenge len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | Challenge... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Challenge AVP within a Start-Control-Connection-Request indicates that the issuing peer wishes to authenticate the tunnel endpoints using a CHAP-style authentication mechanism. The Attribute value is 11, indicating Challenge, and is marked mandatory. This AVP is optional. The Value is one or more octets of challenge value. Valencia expires June 1999 [Page 36] INTERNET DRAFT October 1998 6.2 Start-Control-Connection-Reply (SCCRP) The Start-Control-Connection-Reply is an L2TP control message sent in reply to a received Start-Control-Connection-Request message. Sending this message indicates that the request was successful. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Control-Connection-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version | | Framing Capabilities | | Bearer Capabilities | | Firmware Revision | | Host Name | | Vendor Name | | Assigned Tunnel ID | | Receive Window Size | | Challenge | | Challenge Response | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-Reply 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 2, indicating Start- Control-Connection-Reply. The Flags indicate a mandatory option. Protocol Version 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 0x01 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Protocol Version AVP within a Start-Control-Connection-Reply packet indicates the L2TP protocol version available. The Attribute value is 2, indicating Protocol Version, and the Value field is a 16-bit hexadecimal value 0x100, indicating L2TP protocol version 1, revision 0. This AVP MUST be present. Valencia expires June 1999 [Page 37] INTERNET DRAFT October 1998 Framing Capabilities 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 |0|0|0|0|0|0|A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Framing Capabilities AVP within a Start-Control-Connection- Reply indicates the type of framing that the sender of this message can provide. The Attribute is 3, it is a mandatory AVP, the Value field is a 32-bit quantity, with two bits defined. If bit A is set, asynchronous framing is supported. If bit S is set, synchronous framing is supported. This AVP MUST be present. More details on the use of this AVP can be found in Sec. 6.1. Bearer Capabilities 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 |0|0|0|0|0|0|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Bearer Capabilities AVP within a Start-Control-Connection- Reply indicates the bearer capabilities that the sender of this message can provide for outgoing calls. The Attribute is 4, it is a mandatory AVP, the Value field is a 32-bit quantity with two bits defined. If bit A is set, analog access is supported. If bit D is set, digital access is supported. This AVP MUST be present if outgoing calls can be placed by the sender of this message. More details on the use of this AVP can be found in Sec. 6.1. Firmware Revision 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | Firmware Revision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires June 1999 [Page 38] INTERNET DRAFT October 1998 The Firmware Revision AVP within a Start-Control-Connection-Reply indicates the firmware revision of the issuing device. The Attribute is 6, it is not a mandatory AVP, the Value field is a 16-bit 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 is optional. Host Name 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 6 + Host Name len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | Host Name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Host Name AVP within a Start-Control-Connection-Reply indicates the name of the issuing LAC or LNS. See the notes in section 6.1 concerning Host Name contents. It is encoded as the Attribute 7, mandatory, with the indicated number of octets representing the host name string. This AVP MUST be present. Vendor Name 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0| 6+Vendor Name len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 |Vendor Name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Vendor Name AVP within a Start-Control-Connection-Reply contains a vendor specific string describing the type of LAC or LNS being used. It is encoded as the Attribute 8, not mandatory, with the indicated number of octets representing the vendor string. This AVP is optional. Assigned Tunnel ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply specifies the Tunnel ID which the receiving peer MUST use in all subsequent packets. It is encoded as the Attribute 9, mandatory, Valencia expires June 1999 [Page 39] INTERNET DRAFT October 1998 with a 16-bit non-zero Tunnel ID value. This AVP MUST be present. Receive Window Size 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Receive Window Size AVP within a Start-Control-Connection- Reply specifies the receive window size being offered to the remote peer. The Attribute value is 10, indicating Receive Window Size, and is mandatory. This AVP itself is optional. Value is a 16-bit word indicating the offered window size. If absent, the peer must assume a value of 4 for its transmit window. The remote peer may send the specified number of control messages before it must wait for an acknowledgment. Challenge 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 6 + Challenge len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | Challenge... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Challenge AVP within a Start-Control-Connection-Reply indicates that the peer wishes to authenticate the tunnel initiator using a CHAP-style authentication mechanism. It is encoded as the Attribute 11, mandatory, with at least one octet of challenge value embedded. If this AVP is not present, it indicates to the receiving peer that the sender does not wish to authenticate that peer. Challenge Response 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 22 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 13 | Response... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response... (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Response AVP within a Start-Control-Connection-Reply packet provides a response to a challenge received. The Attribute value is 13, indicating Response, and the Value field is a 128-bit value Valencia expires June 1999 [Page 40] INTERNET DRAFT October 1998 reflecting the CHAP-style response to the challenge. This AVP marked mandatory, and MUST be present if a challenge was received and this Start-Control-Connection-Reply indicates success. For purposes of the ID value in the CHAP response calculation, the value 2 (corresponding to the Value field of the Start-Control- Connection-Reply AVP) MUST be used. 6.3 Start-Control-Connection-Connected (SCCCN) The Start-Control-Connection-Connected message is an L2TP control message sent in reply to a received Start-Control-Connection-Reply message. This message provides closure to the tunnel establishment process, and includes a challenge response if the peer sent a challenge in the Start-Control-Connection-Reply message. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Control-Connection-Connected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge Response | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-Connected 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 3, indicating Start- Control-Connection-Connected. The Flags indicate a mandatory option. Challenge Response 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 22 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 13 | Response... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response... (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Challenge Response AVP within a Start-Control-Connection- Connected packet provides a response to a challenge received. The Attribute value is 13, indicating Response, and the Value field is a 128-bit value reflecting the CHAP-style response to the challenge. This AVP is marked mandatory, and MUST be present if a Valencia expires June 1999 [Page 41] INTERNET DRAFT October 1998 challenge was received, otherwise MUST be omitted. For purposes of the ID value in the CHAP response calculation, the value 3 (corresponding to the Value field of the Start-Control- Connection-Connected AVP) MUST be used. 6.4 Stop-Control-Connection-Notification (StopCCN) The Stop-Control-Connection-Notification is an L2TP control message sent by one peer of an LAC-LNS control connection to inform the other peer that the control connection should be closed. In addition to closing the control connection, all active user calls are implicitly cleared. The reason for issuing this request is indicated in the Result Code AVP. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stop-Control-Connection-Notification| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Tunnel ID | | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+ Stop-Control-Connection-Notification AVP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 4, indicating Stop- Control-Connection-Notification. The Flags indicate a mandatory option. Assigned Tunnel ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute value is 9, indicating Assigned Tunnel ID, and is marked mandatory. This AVP MUST be present. The Value MUST be the same Assigned Tunnel ID first sent to the receiving peer. This AVP permits the peer to identify the appropriate tunnel even if Stop-Control-Connection-Notification must be sent before an Assigned Tunnel ID is received. Valencia expires June 1999 [Page 42] INTERNET DRAFT October 1998 Result Code 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 10 + Message len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Optional Message ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result Code AVP within a Stop-Control-Connection-Notification packet indicates the reason for terminating the control channel. It is encoded as Attribute 1, indicating a Result Code AVP. This AVP is mandatory and MUST be present. The Result Code is a 16-bit word. The 16-bit word following the Result Code field contains the Error Code value, which for a Stop-Control-Connection- Notification is always 0. An optional message can follow the Error Code field. Its presence and length is indicated by the value of the AVP length field. Defined Result Code values are: 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 6.5 Hello The 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. 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. When a Hello is received, it MUST be ignored (after updating any effects of the indicated Nr/Ns values, and being acknowleged). 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 once every 60 seconds if 60 seconds have passed without receiving any message (payload or control, including ZLB messages) from the peer. Hello messages are global to the tunnel; the Call ID field of these Valencia expires June 1999 [Page 43] INTERNET DRAFT October 1998 control messages MUST be 0. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hello | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hello 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 6, indicating Hello The Flags indicate a mandatory option. 6.6 Outgoing-Call-Request (OCRQ) The Outgoing-Call-Request is an L2TP control message sent by the LNS to the LAC to indicate that an outbound call from the LNS is to be established. This request provides the LAC with information required to make the call. It also provides information to the LAC that is used to regulate the transmission of data to the LNS for this session once it is established. This message is the first in the "three-way handshake" used by L2TP for establishing outgoing calls. The first message requests the call; the second indicates that the call was successfully initiated. The third and final message indicates that the call was established. 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. Valencia expires June 1999 [Page 44] INTERNET DRAFT October 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing-Call-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | | Call Serial Number | | Minimum BPS | | Maximum BPS | | Bearer Type | | Framing Type | | Receive Window Size | | Packet Processing Delay | | Dialed Number | | Sub-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+ Outgoing-Call-Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 7, indicating Outgoing- Call-Request. The Outgoing-Call-Request encodes a request to an LAC to establish an outgoing call. The flags indicate a mandatory option. Assigned Call ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Call ID AVP encodes the ID being assigned to this call by the LNS. The Attribute value is 14, indicating Assigned Call ID, and is marked mandatory. This AVP MUST be present. The LAC places this value in the Call ID header field of all command and payload packets that it subsequently transmits over the tunnel that belong to this call. The Call ID value is an identifier assigned by the LNS to this session. It is used to multiplex and demultiplex data sent over that tunnel between the LNS and LAC. Valencia expires June 1999 [Page 45] INTERNET DRAFT October 1998 Call Serial Number 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 | CSN (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CSN (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call Serial