idnits 2.17.1 draft-ietf-pppext-l2tp-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 93 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 576 has weird spacing: '...ed less than...' == Line 1499 has weird spacing: '...ng with each ...' == Line 3795 has weird spacing: '...e local wai...' == Line 3796 has weird spacing: '...ndicate tunne...' == Line 3965 has weird spacing: '...e local wai...' == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'LAN' on line 353 == Unused Reference: '3' is defined on line 4317, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 4324, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1700 (ref. '5') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2309 (ref. '6') (Obsoleted by RFC 7567) == Outdated reference: A later version (-02) exists of draft-grant-tacacs-00 -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2058 (ref. '8') (Obsoleted by RFC 2138) -- Possible downref: Non-RFC (?) normative reference: ref. '12' == Outdated reference: A later version (-08) exists of draft-ietf-radius-tunnel-auth-04 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-auth (ref. '13') -- Possible downref: Non-RFC (?) normative reference: ref. '16' == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-04 Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group A. Valencia 3 INTERNET DRAFT Cisco Systems 4 Category: Internet Draft K. Hamzeh, A. Rubens 5 Title: draft-ietf-pppext-l2tp-12.txt Ascend Communications 6 Date: October 1998 T. Kolar, M. Littlewood 7 W. M. Townsley 8 Cisco Systems 9 J. Taarud 10 Copper Mountain Networks 11 G. S. Pall 12 Microsoft Corporation 13 B. Palter 14 Network Alchemy 15 W. Verthein 16 3COM Corporation 18 Layer Two Tunneling Protocol "L2TP" 20 Status of this Memo 22 This document is an Internet-Draft. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months. Internet-Drafts may be updated, replaced, or obsoleted by 29 other documents at any time. It is not appropriate to use Internet- 30 Drafts as reference material or to cite them other than as a 31 ``working draft'' or ``work in progress.'' 33 To learn the current status of any Internet-Draft, please check the 34 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 35 Directories on ftp.ietf.org, nic.nordu.net, ftp.nisc.sri.com, or 36 munnari.oz.au. 38 Abstract 40 Virtual dial-up allows many separate and autonomous protocol domains 41 to share common access infrastructure including modems, Access 42 Servers, and ISDN routers. RFC 1661 specifies multi-protocol dial-up 43 via PPP [1]. This document describes the Layer Two Tunneling 44 Protocol (L2TP) which permits the tunneling of the link layer (i.e., 45 HDLC, async HDLC) of PPP. Using such tunnels, it is possible to 46 divorce the location of the initial dial-up server from the location 47 at which the dial-up protocol connection is terminated and access to 48 the network provided. 50 Table of Contents 52 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.0 Problem Space Overview . . . . . . . . . . . . . . . . . . 6 56 2.1 Initial Assumptions . . . . . . . . . . . . . . . . . . . 6 57 2.2 Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.3 Providing Virtual Dial-up Services--a walk-through . . . . 7 59 3.0 Service Model Issues . . . . . . . . . . . . . . . . . . . 9 60 3.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.2 Address Allocation . . . . . . . . . . . . . . . . . . . . 10 62 3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 10 63 3.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.0 Protocol Overview . . . . . . . . . . . . . . . . . . . . 11 65 4.1 Control Message Overview . . . . . . . . . . . . . . . . . 13 66 4.2 Payload Packet Overview . . . . . . . . . . . . . . . . . 13 67 4.3 Flow Control . . . . . . . . . . . . . . . . . . . . . . . 16 68 5.0 Message Format and Protocol Extensibility . . . . . . . . 18 69 5.1 AVP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 5.2 Control Message Format . . . . . . . . . . . . . . . . . . 20 71 5.3 Payload Message Format . . . . . . . . . . . . . . . . . . 21 72 5.4 Control Message Types . . . . . . . . . . . . . . . . . . 22 73 5.5 AVP Summary . . . . . . . . . . . . . . . . . . . . . . . 23 74 5.6 Result and Error Code Summary . . . . . . . . . . . . . . 25 75 5.7 Hiding of AVP values . . . . . . . . . . . . . . . . . . . 27 76 6.0 Control Connection Protocol Specification . . . . . . . . 30 77 6.0.1 Control Connection Collision . . . . . . . . . . . . . . 30 78 6.0.2 Reliable Delivery of Control Messages . . . . . . . . . 30 79 6.0.3 Control Message Format . . . . . . . . . . . . . . . . . 31 80 6.1 Start-Control-Connection-Request . . . . . . . . . . . . . 31 81 6.2 Start-Control-Connection-Reply . . . . . . . . . . . . . . 37 82 6.3 Start-Control-Connection-Connected . . . . . . . . . . . . 41 83 6.4 Stop-Control-Connection-Notification . . . . . . . . . . . 42 84 6.5 Hello . . . . . . . . . . . . . . . . . . . . . . . . . . 43 85 6.6 Outgoing-Call-Request . . . . . . . . . . . . . . . . . . 44 86 6.7 Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . 49 87 6.8 Outgoing-Call-Connected . . . . . . . . . . . . . . . . . 50 88 6.9 Incoming-Call-Request . . . . . . . . . . . . . . . . . . 53 89 6.10 Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 57 90 6.11 Incoming-Call-Connected . . . . . . . . . . . . . . . . . 58 91 6.12 Call-Disconnect-Notify . . . . . . . . . . . . . . . . . 65 92 6.13 WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . 67 93 6.14 Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 68 94 7.0 Control Connection State Machines . . . . . . . . . . . . 69 95 7.1 Control Connection Protocol Operation . . . . . . . . . . 70 96 7.2 Control Connection States . . . . . . . . . . . . . . . . 70 97 7.2.1 Control Connection Establishment . . . . . . . . . . . . 70 98 7.3 Timing considerations . . . . . . . . . . . . . . . . . . 72 99 7.4 Incoming Calls . . . . . . . . . . . . . . . . . . . . . . 72 100 7.4.1 LAC Incoming Call States . . . . . . . . . . . . . . . . 72 101 7.4.2 LNS Incoming Call States . . . . . . . . . . . . . . . . 74 102 7.5 Outgoing calls . . . . . . . . . . . . . . . . . . . . . . 74 103 7.5.1 LAC Outgoing Call States . . . . . . . . . . . . . . . . 75 104 7.5.2 LNS Outgoing Call States . . . . . . . . . . . . . . . . 76 105 7.6 Tunnel Disconnection . . . . . . . . . . . . . . . . . . . 77 106 8.0 L2TP Over Specific Media . . . . . . . . . . . . . . . . . 77 107 8.1 IP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 77 108 8.2 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 109 9.0 Security Considerations . . . . . . . . . . . . . . . . . 79 110 9.1 Tunnel Endpoint Security . . . . . . . . . . . . . . . . . 79 111 9.2 Client Security . . . . . . . . . . . . . . . . . . . . . 79 112 9.3 Proxy Authentication . . . . . . . . . . . . . . . . . . . 80 113 10.0 IANA Considerations . . . . . . . . . . . . . . . . . . . 80 114 10.1 AVP Attribute Type Values . . . . . . . . . . . . . . . . 80 115 10.2 Message type values . . . . . . . . . . . . . . . . . . . 80 116 10.3 Result code values . . . . . . . . . . . . . . . . . . . 80 117 10.4 Framing Capabilities & Bearer Capabilitities . . . . . . 80 118 10.5 Proxy Authen Type values . . . . . . . . . . . . . . . . 81 119 10.6 AVP Header bits . . . . . . . . . . . . . . . . . . . . . 81 120 10.7 Message (Payload and Control) Header bits . . . . . . . . 81 121 11.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 81 122 12.0 Contacts . . . . . . . . . . . . . . . . . . . . . . . . 81 123 13.0 References . . . . . . . . . . . . . . . . . . . . . . . 82 124 Appendix A: Acknowledgment Time-Outs . . . . . . . . . . . . . 83 125 Appendix B: Acknowledgment Time-Out and Window Adjustment . . 87 126 Appendix C: Handling of out-of-order packets . . . . . . . . . 88 127 Appendix D: Transport Layer Adaptive Time-Outs 128 and Window Adjustment . . . . . . . . . . . . . . 89 129 Appendix E: Examples of L2TP sequence numbering . . . . . . . 90 130 Appendix F: Flow Control and Sequencing Negotiation . . . . . 93 132 1.0 Introduction 134 The traditional dial-up network service on the Internet is for 135 registered IP addresses only. A new class of virtual dial-up 136 application which allows multiple protocols and unregistered IP 137 addresses is also desired on the Internet. Examples of this class of 138 network application are support for privately addressed IP, IPX, and 139 AppleTalk dial-up via PPP across existing Internet infrastructure. 141 The support of these multi-protocol virtual dial-up applications is 142 of significant benefit to end users, enterprises, and Internet 143 Service providers as it allows the sharing of very large investments 144 in access and core infrastructure and allows local calls to be used. 145 It also allows existing investments in non-IP protocol applications 146 to be supported in a secure manner while still leveraging the access 147 infrastructure of the Internet. 149 It is the purpose of this document to identify the issues encountered 150 in integrating multi-protocol dial-up services into an existing 151 Internet Service Provider's Point of Presence (hereafter referred to 152 as ISP and POP, respectively), and to describe the L2TP protocol 153 which permits the leveraging of existing access protocols. 155 This protocol may solve the "multilink hunt-group splitting" problem. 156 Multilink PPP [9], often used to aggregate ISDN B channels, requires 157 that all channels composing a multilink bundle be grouped at a single 158 NAS. Because L2TP makes a PPP session terminate at a location other 159 than the point at which the session was physically received, it can 160 be used to make all channels terminate at a single NAS, allowing 161 multilink operation even when the physical calls are spread across 162 distinct physical NAS's. 164 1.1 Conventions 166 The following language conventions are used in the items of 167 specification in this document: 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [15]. 173 1.2 Terminology 175 Analog Channel 177 A circuit-switched communication path which is intended to carry 178 3.1 kHz audio in each direction. 180 Control Connection 182 A control connection operates in-band over a tunnel to control the 183 establishment, release, and maintenance of sessions and of the 184 tunnel itself. 186 Call 188 A connection or attempted connection between two terminal 189 endpoints. For example, a telephone call through the PSTN between 190 two modems. (See also: Session). 192 CHAP 194 Challenge Authentication Protocol, a PPP cryptographic 195 challenge/response authentication protocol in which the cleartext 196 password is not passed over the line. 198 CLID 200 Calling Line ID, an indication to the receiver of a call as to the 201 phone number of the caller. 203 Control Messages 205 Control messages are exchanged between LAC and LNS pairs, 206 operating in-band within the tunnel protocol. Control messages 207 govern aspects of the tunnel and sessions within the tunnel. 209 Dial User 211 An end-system or router attached to an on-demand PSTN or ISDN 212 which is either the initiator or recipient of a call. Also 213 referred to as a dial-up or Virtual dial-up client. 215 DNIS 217 Dialed Number Information String, an indication to the receiver of 218 a call as to what phone number the caller used to reach it. 220 Digital Channel 222 A circuit-switched communication path which is intended to carry 223 digital information in each direction. 225 EAP 227 Extensible Authentication Protocol, a framework for a family of 228 PPP authentication protocols, including cleartext, 229 challenge/response, and arbitrary dialog sequences. 231 L2TP Access Concentrator (LAC) 233 A Network Access Server (NAS) or host co-located with a PPP end 234 system capable of handling the L2TP protocol. The LAC needs only 235 implement the media over which L2TP is to operate to pass traffic 236 to one or more LNS's. It may tunnel any protocol carried within 237 PPP. The LAC is the initiator of incoming calls and the receiver 238 of outgoing calls. 240 L2TP Network Server (LNS) 242 An LNS operates on any platform capable of PPP termination. The 243 LNS handles the server side of the L2TP protocol. Since L2TP 244 relies only on the single media over which L2TP tunnels arrive, 245 the LNS may have only a single LAN or WAN interface, yet still be 246 able to terminate calls arriving at any LAC's full range of PPP 247 interfaces (async, synchronous ISDN, V.120, etc.). The LNS is the 248 initiator of outgoing calls and the receiver of incoming calls. 250 Network Access Server (NAS) 252 A device providing temporary, on-demand network access to users. 253 This access is point-to-point typically using PSTN or ISDN lines. 254 A NAS may also serve as an LAC, LNS or both. 256 PAP 258 Password Authentication Protocol, a simple PPP authentication 259 mechanism in which a cleartext username and password are 260 transmitted to prove identity. 262 POP 264 An Internet Service Provider's Point of Presence. 266 Quality of Service (QOS) 268 A given Quality of Service level is sometimes required for a given 269 user being tunneled between an LNS-LAC pair. For this scenario, a 270 unique L2TP tunnel is created and encapsulated directly on top of 271 the media providing the indicated QOS. 273 Session 275 L2TP is connection-oriented. The LNS and LAC maintain state for 276 each user that is attached to an LAC. A session is created when 277 an end-to-end PPP connection is attempted between a dial user and 278 the LNS, or when an outbound call is initiated. The datagrams 279 related to a session are sent over the tunnel between the LAC and 280 LNS. (See also: Call). 282 Tunnel 284 A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP 285 datagrams between the LAC and the LNS; many sessions can be 286 multiplexed over a single tunnel. A control connection operating 287 in-band over the same tunnel controls the establishment, release, 288 and maintenance of sessions and of the tunnel itself. A tunnel is 289 sometimes referred to as a control connection. 291 Zero-Length Body (ZLB) Message 293 A control or payload packet with only an L2TP header, and no 294 control message information or PPP payload. ZLB messages are used 295 for explicitly acknowledging packets on the control or data 296 channel. 298 2.0 Problem Space Overview 300 In this section we describe in high level terms the scope of the 301 problem that will be explored in more detail in later sections. 303 2.1 Initial Assumptions 305 We begin by assuming that Internet access is provided by an ISP and 306 that the ISP wishes to offer services other than traditional 307 registered IP address based services to dial-up users of the network. 309 We also assume that the user of such a service wants all of the 310 security facilities that are available to him or her in a dedicated 311 dial-up configuration. In particular, the end user requires: 313 + End System transparency: Neither the remote end system nor his 314 home site hosts should require any special software to use this 315 service in a secure manner. 317 + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or 318 through other dialogs, for instance, a textual exchange on V.120 319 before starting PPP. This will include TACACS+ [7] and RADIUS [8] 320 solutions as well as support for smart cards and one-time passwords. 321 The authentication should be manageable by the user independently of 322 the ISP. 324 + Addressing should be as manageable as dedicated dial-up solutions. 325 The address should be assigned by the home site and not the ISP. 327 + Authorization should be managed by the home site as it would in a 328 direct dial-up solution. 330 + Accounting should be performed both by the ISP (for billing 331 purposes) and by the user (for charge-back and auditing). 333 2.2 Topology 335 Shown below is a generic Internet with Public switched Telephone 336 Network (PSTN) access (i.e., async PPP via modems) and Integrated 337 Services Digital Network (ISDN) access (i.e., synchronous PPP 338 access). Remote users (either async or ISDN PPP) will access the 339 Home LAN as if they were dialed into the L2TP Network Server (LNS), 340 although their physical dial-up is via the ISP Network Access Server 341 (acting as the LAC). 343 [LAN] 344 | 345 __________ +--[Host] 346 | | | 347 [LAC]---------| Internet |-----[LNS]-----+ 348 | |__________| | 349 _____|_____ : 350 | | 351 | PSTN | 352 [User]--| or ISDN | 353 | Cloud | [LAN] 354 |___________| | 355 | ______________ +---[Host] 356 | | | | 357 [LAC]-------| Frame Relay |---[LNS]-----+ 358 | or ATM Cloud | | 359 |______________| : 361 2.3 Providing Virtual dial-up Services--a walk-through 363 To motivate the following discussion, this section walks through an 364 example of what might happen when a Virtual dial-up client initiates 365 access. 367 A Network Access Server (NAS) operating as a peer to an LNS is 368 referred to as an L2TP Access Concentrator, or "LAC". 370 The remote user initiates a PPP connection to an ISP via either the 371 PSTN or ISDN. The LAC accepts the connection and the PPP link is 372 established (L2TP also permits the LAC to check with an LNS after 373 call indication prior to accepting the call. This is useful where 374 DNIS or CLID information is available in the incoming call 375 notification). 377 The ISP may now undertake a partial authentication of the end 378 system/user. Only the username field would be interpreted to 379 determine whether the user requires a Virtual dial-up service. It is 380 expected, but not required, that usernames will be structured (e.g. 381 username@company.com). Alternatively, the ISP may maintain a 382 database mapping users to services. In the case of Virtual dial-up, 383 the mapping will name a specific endpoint, the LNS. 385 Alternatively, the ISP may have already determined the target LNS 386 from DNIS. If the LNS is willing to accept tunnel creation without 387 any authentication of the caller, the LAC may tunnel the PPP 388 connection without ever having communicated with the remote user. 390 If a virtual dial-up service is not required, standard access to the 391 Internet may be provided. 393 If no tunnel connection currently exists to the desired LNS, one is 394 initiated. L2TP is designed to be largely insulated from the details 395 of the media over which the tunnel is established; L2TP requires only 396 that the tunnel media provide packet oriented point-to-point 397 connectivity. Obvious examples of such media are UDP, Frame Relay 398 PVC's, or X.25 VC's. 400 Once the tunnel exists, an unused slot within the tunnel, a "Call 401 ID", is allocated, and a connect indication is sent to notify the LNS 402 of this new dial-up session. The LNS either accepts the connection, 403 or rejects it. Rejection MUST include a result condition and MAY 404 include an error indication, which may be displayed to the dial-up 405 user, after which the call should be disconnected. 407 The initial connect notification may include the authentication 408 information required to allow the LNS to authenticate the user and 409 decide to accept or decline the connection. In the case of CHAP, the 410 set-up packet includes the challenge, username and raw response. For 411 PAP or text dialog, it includes username and clear text password. 412 The LNS may choose to use this information to complete its 413 authentication, avoiding an additional cycle of authentication. 415 If the LAC negotiated PPP LCP [1] before initiating the tunnel, the 416 initial connect notification may also include a copy of the LCP 417 CONFREQ's sent in each direction which completed LCP negotiation. 418 The LNS may use this information to initialize its own PPP state 419 (thus avoiding an additional LCP negotiation), or it may choose to 420 initiate a new LCP CONFREQ exchange. 422 If the LNS accepts the connection, it creates a "virtual interface" 423 for PPP in a manner analogous to what it would use for a direct- 424 dialed connection. With this "virtual interface" in place, link 425 layer frames may now pass over this tunnel in both directions. 426 Frames from the remote user are received at the POP, stripped of CRC, 427 link framing, and transparency bytes, encapsulated in L2TP, and 428 forwarded over the appropriate tunnel. 430 The LNS accepts these frames, strips L2TP, and processes them as 431 normal incoming frames for the appropriate interface and protocol. 432 The "virtual interface" behaves very much like a hardware interface, 433 with the exception that the hardware in this case is physically 434 located at the ISP POP. The other direction behaves analogously, 435 with the LNS encapsulating the packet in L2TP, and the LAC stripping 436 L2TP before transmitting it out the physical interface to the remote 437 user. 439 At this point, the connectivity is a point-to-point PPP session whose 440 endpoints are the remote user's networking application on one end and 441 the termination of this connectivity into the LNS's PPP support on 442 the other. Because the remote user has become simply another dial-up 443 client of the LNS, client connectivity can now be managed using 444 traditional mechanisms with respect to further authorization, 445 protocol access, and packet filtering. 447 Accounting can be performed at both the LAC as well as the LNS. This 448 document illustrates some Accounting techniques which are possible 449 using L2TP, but the policies surrounding such Accounting are outside 450 the scope of this specification. 452 L2TP offers optional facilities which maximize compatibility with 453 legacy client requirements; L2TP connect notifications for PPP 454 clients can contain sufficient information for an LNS to authenticate 455 and initialize its LCP state machine. With these facilities, the 456 remote user need not be queried a second time for PPP authentication, 457 nor undergo multiple rounds of LCP negotiation and convergence. 458 These techniques are intended to optimize connection setup, and are 459 not intended to deprecate any functions required by the PPP 460 specification. 462 3.0 Service Model Issues 464 There are several significant differences between the standard 465 Internet access service and the Virtual dial-up service with respect 466 to authentication, address allocation, authorization and accounting. 467 The details of the differences between these services and the 468 problems presented by these differences are described below. The 469 mechanisms used for Virtual Dial-up service are intended to coexist 470 with more traditional mechanisms; it is intended that an ISP's POP 471 can simultaneously service ISP clients as well as Virtual dial-up 472 clients. 474 3.1 Security 476 For the Virtual dial-up service, the ISP pursues authentication only 477 to the extent required to discover the user's apparent identity (and 478 by implication, their desired LNS). This may involve no more than 479 detecting DNIS information when a call arrives, or may involve full 480 LCP negotiation and initiation of PPP authentication. As soon as the 481 apparent identity is determined, a call request to the LNS is 482 initiated with any authentication information gathered by the ISP. If 483 the LNS receives proxy authentication information (see section 6.11), 484 it SHOULD assume that the PPP peer is in the authentication phase, 485 awaiting an indication of success or failure. The LNS completes the 486 authentication by either accepting the call, or rejecting it. 488 The LNS may need to protect against attempts by third parties to 489 establish tunnels to the LNS. Tunnel establishment can include 490 authentication to protect against such attacks. 492 3.2 Address Allocation 494 For a traditional Internet service, the user typically accepts that 495 the IP address may be allocated dynamically from a pool of ISP 496 addresses. This model often means that the remote user has little or 497 no access to their home network's resources, due to firewalls and 498 other security policies applied by the home network to accesses from 499 external IP addresses. 501 For the Virtual dial-up service, the LNS can exist behind the home 502 firewall, allocating addresses which are internal (and, in fact, can 503 be RFC 1918 addresses, or non-IP addresses). Because L2TP tunnels 504 exclusively at the frame layer, the actual policies of such address 505 management are irrelevant to correct Virtual dial-up service; for all 506 purposes of PPP protocol handling, the dial-in user appears to have 507 connected at the LNS. 509 3.3 Authentication 511 The authentication of the user occurs in three phases; the first at 512 the ISP, and the second and optional third at the LNS. 514 The ISP uses DNIS, CLID, or a username to determine that a Virtual 515 dial-up service is required and initiates the tunnel connection to 516 the appropriate LNS. Once a tunnel is established, The ISP NAS 517 allocates a new Call ID and initiates a session by forwarding the 518 gathered authentication information. 520 The LNS undertakes the second phase by deciding whether or not to 521 accept the call. The call start indication may include CHAP, PAP, 522 EAP, or textual authentication information. Based on this 523 information, the LNS may accept the call request, or may reject it 524 (for instance, it was a PAP request and the username/password are 525 found to be incorrect). 527 Once the call is accepted, the LNS is free to pursue a third phase of 528 authentication at the PPP layer. These activities are outside the 529 scope of this specification, but might include an additional cycle of 530 LCP authentication, proprietary PPP extensions, or textual challenges 531 carried via a TCP/IP TELNET session. 533 3.4 Accounting 535 It is a requirement that both the LAC and the LNS be capable of 536 providing accounting data and hence both may count packets, octets 537 and connection start and stop times. 539 Since Virtual dial-up is an access service, accounting of connection 540 attempts (in particular, failed connection attempts) is of 541 significant interest. The LNS can reject new connections based on 542 the authentication information gathered by the LAC, with 543 corresponding logging. For cases where the LNS accepts the 544 connection and then continues with further authentication, the LNS 545 might subsequently disconnect the client. For such scenarios, the 546 disconnection indication back to the LAC may also include a reason. 548 Because the LNS can decline a connection based on the authentication 549 information collected by the LAC, accounting can easily draw a 550 distinction between a series of failed call attempts and a series of 551 brief successful connections. Lacking this facility, the LNS must 552 always accept connection requests, and would need to exchange a 553 number of PPP packets with the remote system. Note that the LNS 554 could use this information to decide to accept the connection (which 555 protects against most invalid connection attempts) while still 556 insisting on running its own CHAP authentication (for instance, to 557 protect against CHAP replay attacks). 559 4.0 Protocol Overview 561 There are two parallel components of L2TP operating over a given 562 tunnel: control messages between each LAC-LNS pair, and payload 563 packets between the same LAC-LNS pair. The latter are used to 564 transport L2TP encapsulated PPP packets for user sessions between the 565 pair. 567 Two fields important to the operation of L2TP are the Nr (Next 568 Received) and Ns (Next Sent) fields which are always present in 569 control messages, and are optionally present in payload packets. A 570 single sequence number state is maintained for all control messages, 571 and a distinct state is maintained for the payload of each user 572 session within the tunnel. The Sequence number starts at 0, Each 573 subsequent packet is sent with the next increment of the sequence 574 number. The sequence number is thus a free running counter 575 represented modulo 65536. The sequence number in the header of a 576 received packet is considered less than or equal to the last 577 received number if its value lies in the range of the last received 578 number and the preceeding 32767 values, inclusive. For example, if 579 the last received sequence number was 15, then packets with sequence 580 numbers 0 through 15, as well as 32753 through 65536, would be 581 considered less than or equal to, and would be silently discarded. 583 Otherwise it would be accepted. 585 In this document, the sequence number state for a control connection 586 and each user session is represented for clarity in the following 587 discussions by distinct pairs of state variables, Sr and Ss. Sr 588 represents the value of the next in-sequence message expected to be 589 received for a given session by a peer. Ss represents the sequence 590 number to be placed in the Ns field of the next message sent for a 591 given session by the sending peer. Each state is initialized such 592 that the first message sent and the first message expected to be 593 received for each session has an Ns value of 0. This corresponds to 594 initializing Ss and Sr in both peers to 0 for each new session. 596 As messages are sent for a given session, Nr is set in these messages 597 to reflect one more than the Ns value of the highest (modulo 2**16) 598 in-order message received for that session; if sent before any packet 599 is received Nr will be 0, indicating that the peer expects the next 600 new Ns value received to be 0. When a non-ZLB message is received 601 with an Ns value that matches the session's current Sr value, Sr is 602 incremented by 1 (modulo 2**16). It is important to note that, for 603 both control and payload sessions, Sr is not modified if a message is 604 received with a value of Ns greater than the current Sr value 605 (exceptions to this rule being the permitted handling of out-of-order 606 payload packets by the "simple receiver" discussed in Appendix C and 607 handling of payload packets with the R bit set). For the control 608 session, retransmission of outgoing messages should eventually 609 provide the receiving peer with the expected message. For payload 610 sessions, however, lost messages are never retransmitted so a 611 mechanism involving the use of the "Reset Sr" (R bit) indicator in an 612 outgoing message is used to update the peer's value of Sr to the 613 value of Ns contained in the message. See Sec. 4.2 for details of 614 this mechanism. 616 Every time a peer sends a non-ZLB message it increments its 617 corresponding Ss value for that session by 1 (modulo 2**16). This 618 increment takes place after the current Ss value is copied to Ns in 619 the message to be sent. Outgoing messages always include the current 620 value of Sr for the corresponding session in their Nr field. 622 A message (control or payload) with a zero-length body indicates that 623 the packet is only used to communicate Nr and Ns fields. The Nr and 624 Ns fields are filled in as above, but the sequence number state, Ss, 625 is not incremented. Thus a ZLB message sent after a non-ZLB message 626 will contain a new Ns value while a non-ZLB message sent after a ZLB 627 message will contain the same value of Ns as the preceding zero- 628 length message. Unless the Rbit (Reset Sr) is set, a peer receiving a 629 zero-length message does not update its Sr variable. 631 Upon receipt of an in-order non-ZLB message, the receiving peer must 632 acknowledge the message by sending back the updated value of Sr in 633 the Nr field of the next outgoing message. This updated Sr value can 634 be piggybacked in the Nr field of any non-ZLB outgoing messages that 635 the peer may happen to send back. 637 If the peer does not have a message to transmit for a short period of 638 time after receiving a non-ZLB message then it should send a ZLB 639 message containing the latest values of Sr and Ss, as described 640 above. The suggested value for this time interval is 1/4 the 641 receiving peer's value of Round-Trip-Time (RTT - see Appendix A), if 642 it computes RTT, or a maximum of 1/2 of its fixed timeout interval 643 otherwise. This timeout should provide a reasonable opportunity for 644 the receiving peer to obtain a payload message destined for its peer, 645 upon which the ACK of the received message can be piggybacked. 647 This timeout value should be treated as a suggested maximum; an 648 implementation could make this timeout quite small without adversely 649 affecting the protocol. To provide for better throughput, the 650 receiving peer should skip this timeout entirely and send a ZLB 651 message immediately in the case where its receive window fills and it 652 has no queued data to send for this connection or it can't send 653 queued data because the transmit window is closed. 655 A suggested implementation of this timer is as follows: Upon 656 receiving a non-ZLB message, the receiver starts a timer that will 657 expire in the recommended time interval. A variable, Lr (Last Nr 658 value sent), is used by the transmitter to store the last value sent 659 in the Nr field of a transmitted payload message for this connection. 660 Upon expiration of this timer, Sr is compared to Lr and, if they are 661 not equal, a ZLB ACK is issued. If they are equal, then no ACK's are 662 outstanding and no action needs to be taken. 664 This timer should not be reinitialized if a new message is received 665 while it is active since such messages will be acknowledged when the 666 timer expires. This ensures that periodic ACK's are issued with a 667 maximum period equal to the recommended timeout interval. This 668 interval should be short enough to not cause false acknowledgment 669 timeouts at the transmitter when payload messages are being sent in 670 one direction only. Since such ACK's are being sent on what would 671 otherwise be an idle data path, their affect on performance should be 672 small, if not negligible. 674 See Appendix E for some examples of how sequence numbers progress. 676 4.1 Control Message Overview 678 Before PPP tunneling can occur between an LAC and LNS, control 679 messages must be exchanged between them. Control messages are 680 exchanged over the same tunnel which will be used to forward 681 payload data once L2TP call control and management information 682 have been passed. The control messages are responsible for 683 establishment, management, and release of sessions carried through 684 the tunnel, as well as status on the tunnel itself. It is the 685 means by which an LNS is notified of an incoming call at an 686 associated LAC, as well as the means by which an LAC is instructed 687 to place an outgoing call. 689 A tunnel may be established by either an LAC (for incoming calls) 690 or an LNS (for outgoing calls). Following the establishment of 691 the tunnel, the LNS and LAC configure the tunnel by exchanging 692 Start-Control-Connection-Request and -Reply messages. These 693 messages are also used to exchange information about basic 694 operating capabilities of the LAC and LNS. Once the control 695 message exchange is complete, the LAC may initiate sessions by 696 indicating inbound requests, or the LNS by requesting outbound 697 calls. If both ends of the tunnel have the ability to act as an 698 LAC and LNS concurrently, then nothing prohibits establishing 699 incoming or outgoing calls from both sides of the same tunnel. 700 Control messages may indicate changes in operating characteristics 701 of an individual user session with a Set-Link-Info message. 702 Individual sessions may be released by either the LAC or LNS, also 703 through control messages. 705 Independent Call ID values are established for each end of a user 706 session. The sender of a packet associated with a particular 707 session places the Call ID established by its peer in the Call ID 708 header field of all outgoing packets. For the cases where a Call 709 ID has not yet been assigned from the peer (i.e., during call 710 establishment of a new session), the Call ID field is sent as 0, 711 and further fields within the message are used to identify the 712 session. The Call ID value of 0 is thus special and MUST NOT be 713 used as an Assigned Call ID. 715 A mechanism for detection of tunnel connectivity problems is 716 provided by the reliable transport layer of L2TP. The transport 717 layer of L2TP performs control message retransmission. If the 718 number of retransmission attempts for a given control message 719 exceeds a configured maximum value, the tunnel is reset. This 720 retransmission mechanism exists in both the LNS and LAC ends of 721 the tunnel. 723 A keepalive mechanism is employed by the L2TP higher layer in 724 order to differentiate tunnel outages from extended periods of no 725 control or data activity on a tunnel. This is accomplished by the 726 higher layer injecting Hello control messages into the control 727 stream after a specified period of time elapses since the last 728 data or control message was received on the tunnel. As for any 729 other control message, if the transport does not receive an ACK 730 for the Hello message after the normal number of retransmissions 731 the tunnel is declared down and is reset. The transport layer 732 reset mechanism along with the injection of Hello messages ensures 733 that a connectivity failure between the LNS and the LAC will be 734 detected at both ends of a tunnel in a timely manner. 736 It is intended that control messages will also carry management 737 related information in the future, such as a message allowing the 738 LNS to request the status of a given LAC; these message types are 739 not defined in this document. 741 4.2 Payload Packet Overview 743 Once a tunnel is established and control messages have completed 744 tunnel setup, the tunnel can be used to carry user session PPP 745 packets for sessions involving a given LNS-LAC pair. The "Call 746 ID" field in the L2TP header indicates to which session a 747 particular PPP packet belongs. In this manner, PPP packets are 748 multiplexed and demultiplexed over a single tunnel between a given 749 LNS-LAC pair. The "Call ID" field value is established during the 750 exchange of call setup control messages. 752 It is legal for multiple tunnels to exist between a given LNS-LAC 753 pair. This is useful where each tunnel is used for a single user 754 session, and the tunnel media has specific QOS attributes 755 dedicated to a given user. L2TP provides a tunnel identifier so 756 that individual tunnels can be identified, even when arriving from 757 a single source LAC or LNS. 759 The L2TP header also contains optional acknowledgment and 760 sequencing information that can be used to provide flow-control 761 across the underlying medium (which may be an internetwork) as 762 well as congestion control in the network itself (see section 763 4.3). In this document, these mechanisms will be referred to 764 collectively as "flow control". Control messages are used to 765 determine rate and buffering parameters that are used to regulate 766 the flow of PPP packets for a particular session over the tunnel. 768 The receiving peer indicates whether flow control is to be 769 performed for payload packets sent to it. If a peer issues a 770 Receive Window Size AVP with a non-zero value during session 771 establishment, then the sending peer MUST abide by the indicated 772 window size value as long as sequence numbers are provided. If a 773 receiving peer does not wish to flow control the payload packets 774 sent to it, it should not issue the Receive Window Size AVP with a 775 non-zero value. Issuing a Receive Window Size AVP with a zero 776 value has special significance. It indicates that the receiver 777 does not want to perform flow-control but it does want the sending 778 peer to provide Ns values in payload packets so that it can detect 779 lost packets or packets received out of order. A peer SHOULD NOT 780 send ZLB ACK's when its advertised Receive Window is zero or not 781 present (flow control is not requested). 783 In the case where neither peer issues a Receive Window Size AVP 784 during session establishment, the optional Nr and Ns fields are 785 absent in all payload packets for that session. In the case where 786 either peer wishes to perform flow-control or to detect out-of- 787 order receive messages (as indicated by the sending of the Receive 788 Window Size AVP with non-zero or zero value, respectively) the Nr 789 and Ns fields MUST be present in payload packets sent by both 790 peers. A proper Ns value starts at 0 and increments by one for 791 each transmitted payload message and a proper Nr value is the 792 current value of the receive sequence number state variable, Sr. 793 See Appendix F for a table detailing when to send sequence numbers 794 with regard to the Receive Window AVP. 796 Unless the LAC sends the Sequencing Required AVP (see section 6.7 797 and 6.8) in the ICCN or OCCN message, the LNS has the authority to 798 dynamically enable or disable sending of Ns/Nr and hence 799 controlling the capability of loss detection, reordering and flow 800 control over the link. To disable sequence numbers, the LNS sends 801 a packet with the F bit set to 0 and Ns/Nr fields not present. The 802 LAC, upon receiving such a data packet, MUST process the packet 803 and discontinue inclusion of Ns/Nr fields in any subsequent data 804 packets. Any packets which have been received by L2TP but are 805 being held in queue for reordering SHOULD be flushed without 806 waiting for an ACK from the peer (as if an R bit packet with Ns 807 equal to the current Sr value was received). Ss and Sr should be 808 updated and saved accordingly. 810 All data packets will continue to be exchanged without sequence 811 numbers until the end of the session or until the LNS resumes 812 sequence numbers by sending a packet with the F bit set and Ns/Nr 813 present. The LAC, upon receiving a packet with the F bit set, MUST 814 resume sending sequence numbers in further packets. In order to 815 properly resume, the LNS and LAC MUST preserve the state of Ss and 816 Sr between periods of disabled sequencing. 818 While the LNS may initiate disabling of sequencing at any time 819 during the session (including the first data packet sent), it is 820 recommended that for links where reordering or packet loss may 821 occur, sequence numbers always be enabled during the initial 822 negotiation stages of PPP and disabled only when and if the risk 823 is considered acceptable. For instance, if the PPP session being 824 tunneled is not utilizing any stateful compression or encryption 825 protocols and is only carrying IP (as determined by the NCP's that 826 are established), then the LNS might decide to disable sequencing, 827 thus allowing higher level protocols to perform necessary flow 828 control end to end and reducing the per packet L2TP processing 829 burden on the LNS substantially. Further discussion of some of the 830 tradeoffs associated with disabling sequencing over media which 831 may reorder or silently drop packets is given in section 8.2. 833 4.3 Flow Control 835 If a receiving peer offers a non-zero receive window size to a 836 sending peer then the sending peer MUST abide by this window size 837 value as long as sequence numbers are being exchanged (See 838 Appendix F for details of when flow control is enabled in relation 839 to sending of the receive window AVP). The sending peer MUST stop 840 sending payload packets when the window is full; i.e., x 841 consecutive messages have been sent but have not been 842 acknowledged, where x is the value of the Receive Window Size AVP. 843 Implementors should take care to avoid the situation where loss of 844 an ACK by a sending peer with a full transmit window causes a 845 session to hang forever, due to the fact there are no 846 retransmissions of payload packets. Steps must be taken to reopen 847 the transmit window (at least to a value of 1) upon expiration of 848 an ACK wait timeout. See Appendix B for more details. 850 When sending to a peer that has issued a non-zero receive window 851 size, the sending peer is responsible for resetting the receiver's 852 Sr value when a sent payload message is lost during transmission. 854 When a sent message is lost, the receiving peer's Sr value (and 855 hence the Nr value it sends) will "stick" at the Ns value of the 856 first missing payload message. The "Reset Sr" (R bit) in the 857 payload message header (see Section 5.3) provides a mechanism for 858 the sending peer to indicate to the receiver that it (the sending 859 peer) recognizes that at least one payload message has been lost 860 and that the receiving peer should now reset its Sr value beyond 861 the lost message(s). If the sending peer is performing adaptive 862 window adjustment (see Appendix B.1) then it is this recognition 863 of a lost message that is used to indicate that a window 864 adjustment at the sending peer should be performed. 866 The sender may use a timer mechanism similar to that used to 867 retransmit lost control messages to determine when transmitted 868 payload packets have been lost. When the timer expires, a payload 869 message (zero or non-zero length) with the R bit set can be issued 870 to indicate to the receiver that it needs to reset its Sr value. 871 Upon receipt of a payload message with the R bit set, the receiver 872 resets Sr to the value of Ns contained in the message, or, if 873 highly congested, to a value between its current value and the 874 value of Ns contained in the message. 876 Upon receipt of a payload message with R bit set, the receiver 877 takes the following actions: First, the receiver checks for the 878 presence of the R bit in a received payload message before 879 comparing the message's Ns value to its Sr value. If the R bit is 880 set, the receiver will typically set its Sr value equal to that of 881 Ns contained in the message and fall through to normal receive 882 message processing in which Sr will be incremented (modulo 2**16) 883 if the message is non-ZLB and will remain the same if it is ZLB. 884 However, if the receiver is known to be heavily congested, it MAY 885 choose to not update or set its new Sr value between (modulo 886 2**16) the current Sr value and that of Ns contained in the 887 message. This effectively spoofs the transmitter into believing 888 that the R bit packets that have been sent are not being received, 889 ultimately causing the transmitter to backoff more quickly. 891 In order to prevent an R bit message received out of order from 892 setting Sr to an old value, the receiving peer should compare the 893 value of Ns in an R bit message to its current value of Sr. The 894 receiving peer should reset its Sr value only if Ns is greater 895 than (modulo 2**16) its current value of Sr. 897 The sender of the R bit can decide whether it wishes to advance 898 the receiver's Sr value to the value just past the highest (modulo 899 2**16) Nr value received (the Ns value of the message just past 900 that of the first lost message) or to its current value of Ss. 901 Resetting it to that just past the first lost message enables the 902 sender to determine if other messages in the same transmit window 903 were also lost. Setting it to the current Ss value of the sender 904 treats losses of multiple messages in the same window the same as 905 the loss of a single message. An implementation may use either, 906 or a combination of both methods. If the transmitter detects that 907 the receiver is heavily congested, piggybacking the R bit on data 908 packets should be refrained in favor of a ZLB with the R bit set 909 for resetting the receiver's Sr. 911 It is permissible for a sending peer to set the R bit (and hence 912 reset the transmit window) in all transmitted payload packets as 913 an indication that flow control has been disabled at the 914 transmitter. 916 Receipt of an R bit is NOT an explicit indication to immediately 917 flush all packets which might be in queue to PPP for processing. 918 There are a number of tradeoffs as to precisely when a receiver 919 should decide to pass packets from L2TP to PPP, many dependent on 920 what protocols are being carried by PPP. In general, packets 921 should be declared lost and passed to PPP in a timely enough 922 manner so as to not cause retransmissions by reliable higher layer 923 protocols due to packets that are held in queue by l2tp. 925 L2TP does not specify the particular timeout algorithms to use for 926 flow control. Suggested algorithms for the determination of 927 adaptive timeouts to recover from dropped data or acknowledgments 928 on the tunnel are included in Appendix A of this document. 929 Additional examples for sequencing and flow control are included 930 in Appendix E. 932 5.0 Message Format and Protocol Extensibility 934 L2TP defines a set of control messages sent in packets over the 935 tunnel between an LNS and a given LAC. The exact technique for 936 initiating a tunnel between an LNS-LAC pair is specific to the tunnel 937 media, and specific media are described in section 8.0. 939 Once media-level connectivity is reached, L2TP message formats define 940 the protocol for an LAC and LNS to manage the tunnel and its 941 associated sessions. 943 In each case where a field is optional, if the field is not present, 944 its space does not exist in the packet. Existing fields are placed 945 back-to-back to form the packet. 947 5.1 AVP 949 To maximize extensibility while still permitting interoperability, 950 a uniform method for encoding message types and bodies is used 951 throughout L2TP. This encoding will be termed an AVP (Attribute- 952 Value Pair) in the remainder of this document. Each AVP is 953 encoded as: 955 0 1 2 3 956 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 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 |M|H|0|0|0|0| Overall Length | Vendor ID | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Attribute | Value... | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | [until Overall Length is reached]... | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 The first six bits are a bit mask, describing the general 966 attributes of the AVP. 968 The 0 bits indicate reserved bit fields and MUST be set to 0. An 969 AVP received with a reserved bit set to 1 MUST be treated as an 970 unrecognized AVP, unless the reserved bit is defined for an 971 extension that is known to the implementation. 973 The M bit, known as the "mandatory" bit, controls the behavior 974 required of an implementation which receives an AVP which it does 975 not recognize. If M is set on an unrecognized AVP associated with 976 call (session) management, any session associated with this AVP 977 MUST be terminated. If M is set on an unrecognized AVP associated 978 with the overall tunnel, the entire tunnel (and all sessions 979 within) MUST be terminated. If M is not set, an unrecognized AVP 980 MUST be ignored. 982 The H bit, known as the "hidden" bit, controls the hiding of the 983 data in the value field of an AVP. This capability can be used to 984 avoid the passing of sensitive data, such as user passwords, as 985 cleartext in an AVP. Section 5.7 describes the procedure for 986 performing AVP value hiding. 988 Overall Length encodes the number of octets (including the Overall 989 Length field itself) contained in this AVP. It is 10 bits, 990 permitting a maximum of 1023 octets of data in a single AVP. 992 Vendor ID is the IANA assigned "SMI Network Management Private 993 Enterprise Codes" [12] value, encoded in network byte order. The 994 value 0, reserved in this table, corresponds to IETF adopted 995 Attribute values defined within this document. Any vendor wishing 996 to implement L2TP extensions can use their own Vendor ID along 997 with private Attribute values, guaranteeing that they will not 998 collide with any other vendor's extensions, nor with future IETF 999 extensions. Note that there are 16 bits allocated for various 1000 organizations to design and define non-standard attributes. This 1001 limits the ability to define new proprietary AVP implementations 1002 to the first 65,535 enterprises. 1004 Attribute is the actual attribute, a 16-bit value specified in 1005 network byte order with a unique interpretation across all AVP's 1006 defined under a given Vendor ID. 1008 Value follows immediately after the Attribute field, and runs for 1009 the remaining octets indicated in the Overall Length (i.e., 1010 Overall Length minus six octets of header). 1012 AVP's should be kept compact; the combined AVP's within a control 1013 message MUST NOT ever cause a control message's total length to 1014 exceed 1500 octets in length. 1016 5.2 Control Message Format 1018 Each L2TP control message begins with a 12 octet header portion 1019 followed by an 8 octet Message Type AVP and zero or more AVP's. 1020 This header is formatted: 1022 0 1 2 3 1023 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 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 |T|L|0|0|F|0|0|0|0|0|0|0|0| Ver | Length | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Tunnel ID | Call ID | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Ns | Nr | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Message Type AVP... 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 ... (8 octets) | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 The 0 bits indicate reserved bit fields and MUST be set to 0. A 1037 control message received with a reserved bit set to 1 in the 1038 header MUST be treated as an unrecognized control message, unless 1039 the bit is defined for an extension that is known to the 1040 implementation. 1042 The L and F bits must be 1, indicating that the length, Ns and Nr 1043 fields are present. 1045 The T bit MUST be 1, indicating a control message. 1047 Ver MUST be the value 2, indicating a version 1 L2TP message (the 1048 value 1 is reserved to permit detection of L2F [2] packets should 1049 they arrive intermixed, the value 0 is undefined). 1051 Length is the overall length of the message specified in network 1052 byte order. Calculation of the length includes the L2TP header, 1053 message type AVP, plus any additional AVP's associated with a 1054 given control message type. 1056 Tunnel ID and Call ID identify the tunnel and user session within 1057 the tunnel to which a control message applies. If a control 1058 message does not apply to a single user session within the tunnel 1059 (for instance, a Stop-Control-Connection-Notification message), 1060 Call ID MUST be set to 0. If an Assigned Tunnel ID has not yet 1061 been received from the peer, Tunnel ID MUST be set to 0. Once an 1062 Assigned Tunnel ID is received, all further packets MUST be sent 1063 with Tunnel ID set to the indicated value. Note that the Assigned 1064 Tunnel ID and Call ID SHOULD be selected in an unpredictable 1065 manner rather than sequentially or otherwise. Doing so will help 1066 to deter hijacking of a session by a malicious user who does not 1067 have access to packet traces between the LAC and LNS. 1069 Ns is copied from the send sequence number state variable, Ss, at 1070 the time the message is transmitted. Ss is incremented after 1071 copying if the control message is not a ZLB ACK. Nr is copied 1072 from the receive sequence number state variable, Sr, and indicates 1073 the sequence number, Ns, + 1 of the highest (modulo 2**16) in- 1074 sequence message received. See section 4.0. 1076 5.3 Payload Message Format 1078 PPP payload packets tunneled within L2TP have a smaller 1079 encapsulation than the L2TP control message header, reducing 1080 overhead of L2TP during the life of a tunneled PPP session. The 1081 LNS is expected to be able to process user data packets of at 1082 least the default MRU for PPP, not including L2TP and media 1083 encapsulation. The L2TP header has an optional padding field to 1084 allow for alignment correction if desired. The smallest L2TP 1085 encapsulation is 6 octets; the largest is 14 octets (plus padding 1086 octets, if present). See section 8.1 for further MTU 1087 considerations. 1089 0 1 2 3 1090 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 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 |T|L|R|0|F|0|S|P|0|0|0|0|0| Ver | Length (opt) | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Tunnel ID | Call ID | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Ns (opt) | Nr (opt) | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Offset Size (opt) | Offset pad... (opt) | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 The 0 bits indicate reserved bit fields and MUST be set to 0. A 1102 packet received with a reserved bit set to 1 in the payload 1103 message header MUST be silently discarded, unless the bit is 1104 defined for an extension that is known to the implementation. 1106 The T bit MUST be 0, indicating payload. 1108 Ver MUST be 2, indicating version 1 of the L2TP protocol. 1110 If the L bit is set, the Length field is present, indicating the 1111 total length of the packet sent. 1113 The R bit, "Reset Sr", is used for flow control and indicates that 1114 the receiver SHOULD reset its receive state variable, Sr, for this 1115 session to the value contained in the Ns field of this message 1116 header. Sr is reset to the value of Ns only if Ns is greater than 1117 (modulo 2**16) the receiver's current value of Sr. Normal receive 1118 processing of the message is performed after the value of Sr is 1119 reset. Note that if the F bit is not set, then this bit MUST be 1120 0. See section 4.2 for a detailed discussion of the use of this 1121 bit for flow control on the data channel. See Appendix E for 1122 examples of proper R bit usage. 1124 If the F bit is set, both the Nr and Ns fields MUST be present. 1125 Ns indicates the sequence number of the packet being sent. The Ns 1126 value of a message being transmitted is copied from the current 1127 value of the send sequence number state variable, Ss. Ss is 1128 incremented by one (modulo 2**16) after copying to the Ns field 1129 only if the message being sent is not a ZLB ACK. Nr indicates the 1130 sequence number of the next in-order message sequence number to be 1131 received (if the last in-order non-ZLB data packet had Ns set to 1132 1, the Nr sent back would be 2). The value of Nr is copied from 1133 the current receive state variable, Sr. Together, Nr and Ns can 1134 be used to handle out-of-order packets and, together with the R 1135 bit, to provide flow control for the connection. 1137 An L2TP peer setting the F bit, and placing Nr and Ns fields in 1138 its messages, MUST have previously received or sent a Receive 1139 Window Size AVP during establishment of the session. The Nr and 1140 Ns fields are present and updated as described in section 4.0 if 1141 either side has specified an intention to do payload flow control. 1143 The Offset Size field is present if the S bit is set in the header 1144 flags. This field specifies the number of octets past the L2TP 1145 header at which the payload data is expected to start. It is 1146 recommended that data thus skipped be initialized to 0's. If 1147 Offset Size is 0, or the S bit is not set, the first octet 1148 following the last octet of L2TP header is the first octet of 1149 payload data. 1151 If the P bit is set, this packet should receive preferential 1152 treatment at the LAC in its queuing for transmission to the 1153 client. LCP echo requests used as a keepalive for the link, for 1154 instance, should generally be sent from the LNS with this bit set. 1155 Without it, a temporary interval of congestion of the transmission 1156 queues could result in the interference with keepalive messages 1157 and unnecessary loss of the link. 1159 5.4 Control Message Types 1161 Control message and AVP types defined in this specification exist 1162 under Vendor ID 0, indicating IETF defined behavior. The actual 1163 message and AVP semantics are defined in the next section. This 1164 section includes tables that summarize all currently defined 1165 message and AVP types. Note that while an AVP may legally occur 1166 under more than one type of control message, an AVP's specific 1167 interpretation is unique to the specific control message. 1169 Each message type entry in the table below indicates: the integer 1170 value assigned to the message type; the message type abbreviation 1171 used in the AVP Summary Table of Sec. 5.5; and the full name of 1172 the message type. 1174 The integer value assigned to each message type is placed in the 1175 Value field of the Message Type AVP. This AVP MUST be the first 1176 AVP in a message. The currently defined control message types, 1177 grouped by function, are: 1179 Control Connection Management 1181 1 (SCCRQ) Start-Control-Connection-Request 1182 2 (SCCRP) Start-Control-Connection-Reply 1183 3 (SCCCN) Start-Control-Connection-Connected 1184 4 (StopCCN) Stop-Control-Connection-Notification 1185 5 (reserved) 1186 6 Hello 1188 Call Management 1190 7 (OCRQ) Outgoing-Call-Request 1191 8 (OCRP) Outgoing-Call-Reply 1192 9 (OCCN) Outgoing-Call-Connected 1193 10 (ICRQ) Incoming-Call-Request 1194 11 (ICRP) Incoming-Call-Reply 1195 12 (ICCN) Incoming-Call-Connected 1196 13 (reserved) 1197 14 (CDN) Call-Disconnect-Notify 1199 Error Reporting 1201 15 (WEN) WAN-Error-Notify 1203 PPP Session Control 1205 16 (SLI) Set-Link-Info 1207 5.5 AVP Summary 1209 The following table lists all standard L2TP attributes currently 1210 defined. The "Attr" column indicates the integer value assigned 1211 to this attribute. The "M" column indicates the setting of the 1212 "Mandatory" bit of the AVP header for each attribute. The "Len" 1213 field indicates the size of the AVP including the AVP header. A 1214 "+" in this column indicates that the length varies depending upon 1215 the length of the actual contents of the value field. 1217 The "(usage)" list for each entry indicates the message types that 1218 utilize each AVP (See command table of Sec. 5.4). An abbreviation 1219 shown in mixed or upper case letters indicates that the 1220 corresponding AVP MUST be present in this message type; All lower 1221 case indicates that the AVP may optionally appear in this message 1222 type. Some AVPs MUST be present only when a corresponding optional 1223 AVP is present, these AVPs are shown in lower case as well. 1225 A brief summary of the type and contents of the value field for 1226 each attribute is also given for each entry. Refer to the 1227 individual message type descriptions that appear in Section 6 for 1228 further details about the use of a particular AVP in a particular 1229 message type. This table is provided only as a convenient overview 1230 of AVPs, individual message AVP descriptions always enjoy priority 1231 to summary descriptions provided in this table. 1233 Attr M Len Attribute Name (usage) 1235 0 1 8 Message Type (ALL MESSAGES) 1236 16-bit integer value indicating the message type, as defined in 1237 table above. MUST be the first AVP in each message 1239 1 1 10+ Result Code (CDN, StopCCN) 1240 16-bit Integer value indicating result of corresponding request 1241 or reason for issuing a request, 16-bit integer General Error 1242 code and an optional ASCII string error message. See Result 1243 and General Error code tables below. 1245 2 1 8 Protocol Version (SCCRP, SCCRQ) 1246 8-bit L2TP Protocol and Revision numbers 1248 3 1 10 Framing Capabilities (SCCRP, SCCRQ) 1249 32-bit bitmask indicating supported framing types (e.g., 1250 synchronous and asynchronous) 1252 4 1 10 Bearer Capabilities (sccrp, sccrq) 1253 32-bit bitmask indicating supported bearer types (e.g., analog 1254 and digital) 1256 5 0 14 Tie Breaker (sccrq) 1257 8 octet value used to break control connection establishment 1258 collisions 1260 6 0 8 Firmware Revision (sccrp, sccrq) 1261 16-bit integer representing vendor's firmware revision 1263 7 1 6+ Host Name (SCCRP, SCCRQ) 1264 ASCII string name (e.g., DNS name) of issuer 1266 8 0 6+ Vendor Name (sccrp, sccrq) 1267 ASCII string describing issuing device 1269 9 1 8 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 1270 16-bit integer tunnel ID assigned by sender 1272 10 1 8 Receive Window Size (iccn, icrp, occn, ocrq, sccrp, 1273 sccrq) 1274 16-bit integer receive window size offered by sender for a 1275 given call or control session 1277 11 1 6+ Challenge (sccrp, sccrq) 1278 1 or more octet value issued by sender wishing to authenticate 1279 control session peer 1281 12 1 9+ Q.931 Cause Code (cdn) 1282 16-bit cause code, 1 octet cause message, and optional ASCII 1283 advisory message 1285 13 1 22 Challenge Response (scccn, sccrp) 1286 16 octet CHAP type response to peer's Challenge 1288 14 1 8 Assigned Call ID (CDN, ICRP, ICRQ, OCRP, OCRQ) 1289 16-bit integer ID assigned to a call by sender 1291 15 1 10 Call Serial Number (ICRQ, OCRQ) 1292 1 or more octet identifier assigned to a call 1294 16 1 10 Minimum BPS (OCRQ) 1295 32-bit integer indicating lowest acceptable line speed for call 1297 17 1 10 Maximum BPS (OCRQ) 1298 32-bit integer indicating highest acceptable line speed for 1299 call 1301 18 1 10 Bearer Type (icrq, OCRQ) 1302 Indicates bearer type (i.e., analog or digital) for call 1304 19 1 10 Framing Type (ICCN, OCCN, OCRQ) 1305 Indicates framing type (i.e., synchronous or asynchronous) for 1306 call 1308 20 1 8 Packet Processing Delay (iccn, icrp, occn, ocrq) 1309 16-bit integer estimate of processing time of full window of 1310 received packets by sender 1312 21 1 6+ Dialed Number (icrq, OCRQ) 1313 ASCII string phone number called or to be called 1315 22 1 6+ Dialing Number (icrq) 1316 ASCII string phone number of caller 1318 23 1 6+ Sub-Address (icrq, ocrq) 1319 ASCII string containing additional dialing information 1321 24 1 10 (Tx) Connect Speed (ICCN, OCCN) 1322 32-bit integer representing actual (or transmit) line speed of 1323 connection 1325 25 0 10 Physical Channel ID (icrq, ocrp) 1326 32-bit vendor specific physical device identifier used for call 1328 26 0 6+ Initial Received LCP CONFREQ (iccn) 1329 Octet string containing initial CONFREQ received from client 1331 27 0 6+ Last Sent LCP CONFREQ (iccn) 1332 Octet string containing final CONFREQ sent to client 1334 28 0 6+ Last Received LCP CONFREQ (iccn) 1335 Octet string containing final CONFREQ received from client 1337 29 0 8 Proxy Authen Type (iccn) 1338 16-bit integer code indicating client authentication type 1339 negotiated (e.g., PAP, CHAP) 1341 30 0 6+ Proxy Authen Name (iccn) 1342 ASCII string containing name returned by client in 1343 authentication response 1345 31 0 6+ Proxy Authen Challenge (iccn) 1346 Octet string Challenge presented by LAC to client 1348 32 0 8 Proxy Authen ID (iccn) 1349 16-bit integer of which low order octet is ID presented to 1350 client with Challenge. High order octet must be 0. 1352 33 0 6+ Proxy Authen Response (iccn) 1353 Octet string CHAP response or ASCII string password depending 1354 on authentication type used 1356 34 1 32 Call Errors (WEN) 1357 A reserved 16-bit word set to 0 followed by 6 32-bit integer 1358 connection error counters 1360 35 1 16 ACCM (SLI) 1361 A reserved 16-bit word set to 0 followed by 2 32-bit bitmasks 1362 containing Send and Receive ACCM values respectively 1364 36 1 6+ Random Vector (all messages) 1365 Variable length octet string containing a random sequence of 1366 values used to accomplish the optional "hiding" of other AVP 1367 values (See "H" bit description in Sec. 5.7). 1369 37 0 6+ Private Group ID (iccn) 1370 Variable length octet value used by the LAC or LNS to indicate 1371 that this call is to be associated with a particular customer 1372 group. 1374 38 0 10 Rx Connect Speed (iccn, occn) 1375 32-bit integer representing actual receive line speed of 1376 connection. Suggests possibility of asymmetric connection. 1378 39 1 6 Sequencing Required (iccn, occn) 1379 If present, indicates to the LNS that it MUST NOT dynamically 1380 disable sequencing. 1382 5.6 Result and Error Code Summary 1384 The StopCCN and CDN message types contain a Result Code AVP which 1385 indicates the result of the previously requested operation. The 1386 Result Code can indicate that additional information pertaining to an 1387 error situation can be found in the Error Code field of the Result 1388 Code AVP. The meaning of the result code is tabulated under the 1389 specific type of message containing the result. Each 16-bit Result 1390 Code is immediately followed (in the same AVP) by a 16-bit General 1391 Error code value. 1393 General error codes pertain to types of errors which are not specific 1394 to any particular L2TP request, but rather to protocol or message 1395 format errors. If an L2TP reply indicates in its Result Code that a 1396 general error occurred, the General Error value should be examined to 1397 determine what the error was. The currently defined General Error 1398 codes and their meanings are: 1400 0 - No general error 1401 1 - No control connection exists yet for this LAC-LNS pair 1402 2 - Length is wrong 1403 3 - One of the field values was out of range or reserved field was 1404 non-zero 1405 4 - Insufficient resources to handle this operation now 1406 5 - The Call ID is invalid in this context 1407 6 - A generic vendor-specific error occurred in the LAC 1408 7 - Try another. If LAC is aware of other possible LNS 1409 destinations, it should try one of them. This can be used to 1410 guide an LAC based on LNS policy, for instance, the existence 1411 of multilink PPP bundles. 1413 If the length of the Result Code AVP specifies that the Value field 1414 is more than four octets in length, the remaining octets after the 1415 General Error Code field are an arbitrary string providing further 1416 (possibly human readable) text associated with the condition. Human 1417 readable text in all error messages MUST be provided in the UTF-8 1418 charset using the Default Language [18]. 1420 Generally, when a General Error Code of 6 is used, additional 1421 information about the error will be included in the Optional Message 1422 field that follows the Error Code field in the Result Code AVP. 1424 5.7 Hiding of AVP values 1426 The H ("Hidden") bit in the header of each AVP in a control message 1427 provides a mechanism to indicate to the receiving peer whether the 1428 contents of the AVP are hidden or present in cleartext. This feature 1429 can be used to hide sensitive control message data such as user 1430 passwords or user ID's. The H bit MUST NOT be set in the Random 1431 Vector AVP or Message Type AVP. 1433 The H bit MUST only be set if a shared secret exists between the 1434 peers on either end of the tunnel. AVPs involved in the establishment 1435 of the tunnel, or reporting errors involved in the establishment of 1436 the tunnel MUST NOT be hidden. These AVPs are the "Host Name" AVP in 1437 the SCCRQ and SCCRP message, the "Assigned Tunnel ID" in the SCCRQ, 1438 SCCRP, and StopCCN message and the "Result Code" in the StopCCN 1439 message. If the H bit is set in any AVP(s) in a given command 1440 message, a Random Vector AVP must also be present in the message and 1441 MUST precede the first AVP having an H bit of 1. 1443 The length of the AVP value to be hidden is first encoded in the form 1444 of a Hidden AVP Subformat as follows: 1446 0 1 2 3 1447 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 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Length of Original Value | Original Value ... 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 ... | Padding ... 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 Length 1455 This is length of the Original Value to be obscured in octets. 1457 Original Value 1458 Value of hidden AVP that is to be obscured. 1460 Padding 1461 Random additional octets used to obscure length of the Original 1462 Value. 1464 The resulting subformat MAY be padded to a multiple of 16 octets in 1465 length. For example, if the Original Value to be obscured is a string 1466 containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 1467 octets of padding would be applied. Padding does NOT alter the value 1468 placed in the Length of the Original Value, only the length of the 1469 AVP itself. 1471 Next, An MD5 hash is performed on the concatenation of: 1473 - the 2 octet Attribute number of the AVP (in network order) 1474 - the shared authentication secret 1475 - an arbitrary length random vector 1477 The value of the random vector used in this hash is passed in the 1478 value field of a Random Vector AVP. This Random Vector AVP must be 1479 placed in the message by the sender before any hidden AVPs. The same 1480 random vector may be used for more than one hidden AVP in the same 1481 message. If a different random vector is used for the hiding of 1482 subsequent AVPs then a new Random Vector AVP must be placed in the 1483 command message before the first AVP to which it applies. 1485 The MD5 hash value is then XORed with the first 16 octet or less 1486 segment of the Hidden AVP Subformat and placed in the Value field of 1487 the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, 1488 the Subformat is transformed as if the Value field had been padded to 1489 16 octets before the XOR, but only the actual octets present in the 1490 Subformat are modified, and the length of the AVP is not altered. 1492 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1493 is calculated over a stream of octets consisting of the shared secret 1494 followed by the result of the first XOR. That hash is XORed with the 1495 second 16 octet or less segment of the Subformat and placed in the 1496 corresponding octets of the Value field of the Hidden AVP. 1498 If necessary, this operation is repeated, with the shared secret used 1499 along with each XOR result to generate the next hash to XOR the next 1500 segment of the value with. 1502 The method is taken from the book "Network Security" by Kaufman, 1503 Perlman and Speciner [4] pages 109-110. A more precise explanation 1504 of the method follows: 1506 Call the shared secret S, the Random Vector RV, and the Attribute 1507 Value AV, Break the value field into 16-octet chunks p1, p2, etc. 1508 with the last one padded at the end with random data to a 16-octet 1509 boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need 1510 intermediate values b1, b2, etc. 1512 b1 = MD5(AV + S + RA) c(1) = p1 xor b1 1513 b2 = MD5(S + c(1)) c(2) = p2 xor b2 1514 . . 1515 . . 1516 . . 1517 bi = MD5(S + c(i-1)) c(i) = pi xor bi 1519 The String will contain c(1)+c(2)+...+c(i) where + denotes 1520 concatenation. 1522 On receipt, the random vector is taken from the last Random Vector 1523 AVP encountered in the message prior to the AVP to be unhidden. The 1524 above process is then reversed to yield the original value. For more 1525 details on this hiding method, consult RFC 2058 [8]. 1527 The Random Vector AVP has the following format: 1529 Random Vector 1531 0 1 2 3 1532 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 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 |1|0|0|0| 6 + String length | 0 | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | 36 | Random Octet String ... 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 The Random Vector AVP may be used in any message type. The Attribute 1540 value is 36 and it is marked mandatory. It is used to enable the 1541 hiding of the values of arbitrary AVPs. It MUST precede any AVP 1542 containing an AVP with the H bit set but it MUST NOT itself have the 1543 H bit set. More than one Random Vector AVP may appear in a message, 1544 in which case the one most closely preceding an AVP with the H bit 1545 set pertains to that AVP. The Random Octet String is the random 1546 vector value to use in computing the MD5 hash to retrieve the 1547 original value of a hidden AVP. This string can be of arbitrary 1548 length, although a random vector of at least 16 octets is 1549 recommended. The only AVP that the Random Vector AVP MUST NOT precede 1550 is the Message Type AVP (which is always the first AVP in a message). 1552 6.0 Control Connection Protocol Specification 1554 Control Connection messages are used to establish and clear user 1555 sessions. The first set of Control Connection messages are used to 1556 maintain the control connection itself. The control connection is 1557 initiated by an LAC or LNS after establishing the underlying tunnel- 1558 over-media connection. 1560 6.0.1 Control Connection Collision 1562 For the case where an LAC and LNS both initiate tunnels to each 1563 other concurrently, and where the LAC and LNS both determine that 1564 a single tunnel suffices (generally because of media 1565 characteristic considerations, for instance, whether individual 1566 tunnels are needed to gain QOS guarantees for each tunnel), a "tie 1567 breaker" may be undertaken. The details of breaking a tie are 1568 documented with the tunnel establishment messages (Sec. 6.1). 1570 6.0.2 Reliable Delivery of Control Messages 1572 Since L2TP may run across media where packets may be lost, an L2TP 1573 peer sending a control message will retransmit the control message 1574 after deciding that its remote peer has not received it. The 1575 reliable transport mechanism built into L2TP is essentially a 1576 lower layer transport service; the Nr and Ns fields of the control 1577 message header belong to this transport layer. The higher layer 1578 functions of L2TP are not concerned with retransmission or 1579 ordering of control messages. 1581 Each tunnel maintains a queue of control messages to be 1582 transmitted to the peer. The message at the front of the queue is 1583 sent with a given Ns value, and is held until a control message 1584 arrives from the peer in which the Nr field indicates receipt of 1585 this message. After a fixed (a recommended default is 1 second) 1586 or adaptive (see Appendix D) timeout interval expires without 1587 receiving such an acknowledgment, the control message packet is 1588 retransmitted. The retransmitted packet contains the same Ns 1589 value, but the Nr value MUST be updated with the current value of 1590 Sr to reflect any packets received in the interim. Each subsequent 1591 retranmission of a packet MUST employ an exponential backoff 1592 interval. Thus, if the first retransmission occurred after 1 1593 second, the next retransmisssion should occur after 2 seconds has 1594 elapsed, then 4 seconds, etc. An implementation MAY place a cap 1595 upon the maximum interval between retransmissions. This cap MUST 1596 be no less than 8 seconds per retransmission. If no peer response 1597 is detected after several retransmissions (a recommended default 1598 is 5), the tunnel and all sessions within MUST be cleared. 1600 When a tunnel is being shut down for reasons other than loss of 1601 connectivity, the state and reliable delivery mechanisms MUST be 1602 maintained and operated for the full retransmission interval after 1603 the final message exchange has occurred. This permits reliable 1604 delivery of closing messages in environments where these closing 1605 messages might be dropped. 1607 A peer MUST NOT withhold acknowledgment of packets as a technique 1608 for flow controlling control messages. An L2TP implementation is 1609 expected to be able to keep up with incoming control messages, 1610 possibly responding to some with errors reflecting an inability to 1611 honor the requested action. 1613 A sliding window mechanism is used, by default, for control 1614 message transmission. The default is to permit four control 1615 messages to be outstanding on a given tunnel. Consider two peers 1616 A & B. Suppose A specifies a Receive Window Size AVP with a value 1617 of N in the Start-Control-Connection-Request or -Reply packets. B 1618 is now allowed to have up to N outstanding control messages. Once 1619 N have been sent, however, it must wait for an acknowledgment that 1620 advances the window before sending new control messages. An 1621 implementation may support a receive window of only 1 (i.e., by 1622 sending out a Receive Window Size AVP with a value of 1), but MUST 1623 accept a window of up to 4 from its peer. Unlike payload 1624 sessions, a value of 0 for the Receive Window Size AVP is invalid 1625 for a control session. When transmitting control messages, an 1626 implementation SHOULD utilize a slow start method and window 1627 adjustment procedure as described in Appendix B. 1629 The transport layer at a receiving peer is responsible for making 1630 sure that control messages are delivered in order to the higher 1631 layer and that duplicate messages are not delivered to the higher 1632 layer. Messages arriving out of order may be queued for in-order 1633 delivery when the missing messages are received or they may be 1634 discarded, requiring a retransmission. 1636 6.0.3 Control Message Format 1638 The following Control Connection messages are all sent as packets 1639 on the established tunnel connection between a given LNS-LAC pair. 1640 All data is sent in network order (high order octets first). Any 1641 "reserved" or "empty" fields MUST be sent as 0 values to allow for 1642 protocol extensibility. 1644 Each control message has a header, specified in section 5.2, 1645 including an AVP indicating the type of control message, followed 1646 by zero or more AVP's appropriate for the given type of control 1647 message. Each control message is described first at a block 1648 level, and then with details of each AVP. 1650 6.1 Start-Control-Connection-Request (SCCRQ) 1652 The Start-Control-Connection-Request is an L2TP control message used 1653 to initialize the tunnel between an LNS and an LAC. The tunnel must 1654 be initialized through the exchange of these control messages before 1655 any other L2TP messages can be issued. The establishment of the 1656 control connection is started by the initiator of the underlying 1657 tunnel. 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | L2TP Control Message Header | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | Start-Control-Connection-Request | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | Protocol Version | 1665 | Framing Capabilities | 1666 | Bearer Capabilities | 1667 | Tie Breaker | 1668 | Firmware Revision | 1669 | Host Name | 1670 | Vendor Name | 1671 | Assigned Tunnel ID | 1672 | Receive Window Size | 1673 | Challenge | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+ 1676 Start-Control-Connection-Request 1678 0 1 2 3 1679 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 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 |1|0|0|0|0|0| 8 | 0 | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | 0 | 1 | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 The Message Type AVP contains a Value of 1, indicating Start- 1687 Control-Connection-Request. The Flags indicate a mandatory 1688 option. Details associated with this tunneled session follow in 1689 additional AVP's within the packet. 1691 Protocol Version 1693 0 1 2 3 1694 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 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 |1|0|0|0|0|0| 8 | 0 | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | 2 | 0x01 | 0x00 | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 The Protocol Version AVP within a Start-Control-Connection-Request 1702 packet indicates the L2TP protocol version available. The 1703 Attribute value is 2, indicating Protocol Version, and is marked 1704 mandatory. This AVP MUST be present. The Value field is a 16-bit 1705 hexadecimal value 0x100, indicating L2TP protocol version 1, 1706 revision 0. 1708 Framing Capabilities 1710 0 1 2 3 1711 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 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 |1|0|0|0|0|0| 10 | 0 | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | 3 | 0x00 | 0x00 | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | 0x00 |0|0|0|0|0|0|A|S| 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 The Framing Capabilities AVP within a Start-Control-Connection- 1721 Request indicates the type of framing that the sender of this 1722 message can provide. The Attribute value is 3, indicating Framing 1723 Capabilities, and is marked mandatory. This AVP MUST be present. 1724 The Value field is a 32-bit quantity, with two bits defined. If 1725 bit A is set, asynchronous framing is supported. If bit S is set, 1726 synchronous framing is supported. 1728 This AVP provides the peer with an indication of the types of 1729 framing that will be accepted or initiated by the sender. A peer 1730 should not initiate an incoming or outgoing call with a Framing 1731 Type AVP specifying a value not advertised in the Framing 1732 Capabilities AVP it received during control connection 1733 establishment. Attempts to do so will result in the call being 1734 rejected. 1736 Bearer Capabilities 1738 0 1 2 3 1739 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 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 |1|0|0|0|0|0| 10 | 0 | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | 4 | 0x00 | 0x00 | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | 0x00 |0|0|0|0|0|0|A|D| 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 The Bearer Capabilities AVP within a Start-Control-Connection- 1749 Request indicates the bearer capabilities that the sender of this 1750 message can provide for outgoing calls. The Attribute value is 4, 1751 indicating Bearer Capabilities, and is marked mandatory. This AVP 1752 MUST be present if the sender can place outgoing calls when 1753 requested. The Value field is a 32-bit quantity with two bits 1754 defined. If bit A is set, analog access is supported. If bit D 1755 is set, digital access is supported. 1757 This AVP provides the peer with an indication of the bearer device 1758 types supported by the hardware interfaces of the sender for 1759 outgoing calls. An LNS should not initiate an outgoing call 1760 specifying a value in the Bearer Type AVP for a device type not 1761 advertised in the Bearer Capabilities AVP it received from the LAC 1762 during control connection establishment. Attempts to do so will 1763 result in the call being rejected. 1765 Note that an LNS that cannot act as an LAC as well will not 1766 support hardware devices for handling incoming and outgoing calls 1767 and should therefore set the A and D bits in the Value field of 1768 this AVP to 0, or should not send the AVP at all. An LNS that can 1769 also act as an LAC and place outgoing calls should set the 1770 appropriate bits in the Value field of this AVP. Presence of this 1771 message is not a guarantee that a given outgoing call will be 1772 placed by the sender if requested, just that the physical 1773 capability exists. 1775 Tie Breaker 1777 0 1 2 3 1778 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 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 |0|0|0|0|0|0| 14 | 0 | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | 5 | Tie Break Value... | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Value... | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | ...(64 bits) | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 The Tie Breaker AVP within a Start-Control-Connection-Request 1790 contains a 64-bit Value used to break ties in tunnel establishment 1791 between an LAC-LNS pair. The Attribute value is 5, indicating Tie 1792 Breaker, and is marked optional. This AVP itself is optional. 1793 The 8 octet Value is used as a 64-bit tie breaker value. 1795 If present, it indicates the sender wishes a single tunnel to 1796 exist between the given LAC-LNS pair, and this value will be used 1797 to choose a single tunnel where both LAC and LNS initiate a tunnel 1798 concurrently. The recipient of a Start-Control-Connection-Request 1799 must check to see if a Start-Control-Connection-Request has been 1800 sent to the peer, and if so, must compare its Tie Breaker value 1801 with the received one. The lower value "wins", and the "loser" 1802 MUST silently discard its tunnel. In the case where a tie breaker 1803 is present on both sides, and the value is equal, both sides MUST 1804 discard their tunnels. 1806 If a tie breaker is received, and the outstanding Start-Control- 1807 Connection-Request had no tie breaker value, the initiator which 1808 included the Tie Breaker AVP "wins". If neither side issues a Tie 1809 breaker, then two separate tunnels are opened. 1811 It is recommended that the Value be set to the MAC address of a 1812 LAN interface on the sender. If no MAC address is available, a 1813 64-bit random number should be used instead. 1815 Firmware Revision 1817 0 1 2 3 1818 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 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 |0|0|0|0|0|0| 8 | 0 | 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 | 6 | Firmware Revision | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 The Firmware Revision AVP within a Start-Control-Connection- 1826 Request indicates the firmware revision of the issuing device. 1827 The Attribute value is 6, indicating Firmware Revision, and is 1828 marked optional. This AVP itself is optional. The Value field is 1829 a 16-bit integer encoded in a vendor specific format. For devices 1830 which do not have a firmware revision (general purpose computers 1831 running L2TP software modules, for instance), the revision of the 1832 L2TP software module may be reported instead. 1834 Host Name 1836 0 1 2 3 1837 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 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 |1|0|0|0|0|0| 6 + Host name len | 0 | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | 7 | Host name... 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 The Host Name AVP within a Start-Control-Connection-Request 1845 indicates the name of the issuing LAC or LNS. The Attribute value 1846 is 7, indicating Host Name, and is marked mandatory. This AVP 1847 itself MUST be present. This name should be as broadly unique as 1848 possible; for hosts participating in DNS [4], a hostname with 1849 fully qualified domain would be appropriate. 1851 Vendor Name 1853 0 1 2 3 1854 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 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 3|0|0|0|0|0|0| 6+Vendor Name len| 0 | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | 8 | Vendor name... 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 The Vendor Name AVP within a Start-Control-Connection-Request 1862 contains a vendor specific string describing the type of LAC or 1863 LNS being used. The Attribute value is 8, indicating Vendor Name, 1864 and is marked optional. This AVP itself is optional. The Value 1865 is the indicated number of octets representing the vendor string. 1867 Assigned Tunnel ID 1869 0 1 2 3 1870 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 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 |1|0|0|0|0|0| 8 | 0 | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | 9 | Tunnel ID | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 The Assigned Tunnel ID AVP within a Start-Control-Connection- 1878 Request specifies the Tunnel ID which the receiving peer MUST use 1879 in the Tunnel ID field of all subsequent packets. The Attribute 1880 value is 9, indicating Assigned Tunnel ID, and is marked 1881 mandatory. This AVP MUST be present. Before the Assigned Tunnel 1882 ID AVP is received, packets MUST be sent with a Tunnel ID value of 1883 0. The Value is a 16-bit non-zero Tunnel ID value. 1885 Receive Window Size 1887 0 1 2 3 1888 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 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 |1|0|0|0|0|0| 8 | 0 | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | 10 | Size | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 The Receive Window Size AVP within a Start-Control-Connection- 1896 Request specifies the receive window size being offered to the 1897 remote peer. The Attribute value is 10, indicating Receive Window 1898 Size, and is mandatory. This AVP itself is optional. Value is a 1899 16-bit word indicating the offered window size. If absent, the 1900 peer must assume a value of 4 for its transmit window. The remote 1901 peer may send the specified number of control messages before it 1902 must wait for an acknowledgment. 1904 Challenge 1906 0 1 2 3 1907 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 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 |1|0|0|0|0|0| 6 + Challenge len | 0 | 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 | 11 | Challenge... 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 The Challenge AVP within a Start-Control-Connection-Request 1915 indicates that the issuing peer wishes to authenticate the tunnel 1916 endpoints using a CHAP-style authentication mechanism. The 1917 Attribute value is 11, indicating Challenge, and is marked 1918 mandatory. This AVP is optional. The Value is one or more octets 1919 of challenge value. 1921 6.2 Start-Control-Connection-Reply (SCCRP) 1923 The Start-Control-Connection-Reply is an L2TP control message sent in 1924 reply to a received Start-Control-Connection-Request message. Sending 1925 this message indicates that the request was successful. 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | L2TP Control Message Header | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | Start-Control-Connection-Reply | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Protocol Version | 1933 | Framing Capabilities | 1934 | Bearer Capabilities | 1935 | Firmware Revision | 1936 | Host Name | 1937 | Vendor Name | 1938 | Assigned Tunnel ID | 1939 | Receive Window Size | 1940 | Challenge | 1941 | Challenge Response | 1942 +-+-+-+-+-+-+-+-+-+-+-+-+ 1944 Start-Control-Connection-Reply 1946 0 1 2 3 1947 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 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 |1|0|0|0|0|0| 8 | 0 | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 | 0 | 2 | 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 The Message Type AVP contains a Value of 2, indicating Start- 1955 Control-Connection-Reply. The Flags indicate a mandatory option. 1957 Protocol Version 1959 0 1 2 3 1960 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 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 |1|0|0|0|0|0| 8 | 0 | 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 | 2 | 0x01 | 0x00 | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 The Protocol Version AVP within a Start-Control-Connection-Reply 1968 packet indicates the L2TP protocol version available. The 1969 Attribute value is 2, indicating Protocol Version, and the Value 1970 field is a 16-bit hexadecimal value 0x100, indicating L2TP 1971 protocol version 1, revision 0. This AVP MUST be present. 1973 Framing Capabilities 1975 0 1 2 3 1976 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 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 |1|0|0|0|0|0| 10 | 0 | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 | 3 | 0x00 | 0x00 | 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 | 0x00 |0|0|0|0|0|0|A|S| 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 The Framing Capabilities AVP within a Start-Control-Connection- 1986 Reply indicates the type of framing that the sender of this 1987 message can provide. The Attribute is 3, it is a mandatory AVP, 1988 the Value field is a 32-bit quantity, with two bits defined. If 1989 bit A is set, asynchronous framing is supported. If bit S is set, 1990 synchronous framing is supported. This AVP MUST be present. 1992 More details on the use of this AVP can be found in Sec. 6.1. 1994 Bearer Capabilities 1996 0 1 2 3 1997 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 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 |1|0|0|0|0|0| 10 | 0 | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | 4 | 0x00 | 0x00 | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | 0x00 |0|0|0|0|0|0|A|D| 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 The Bearer Capabilities AVP within a Start-Control-Connection- 2007 Reply indicates the bearer capabilities that the sender of this 2008 message can provide for outgoing calls. The Attribute is 4, it is 2009 a mandatory AVP, the Value field is a 32-bit quantity with two 2010 bits defined. If bit A is set, analog access is supported. If 2011 bit D is set, digital access is supported. This AVP MUST be 2012 present if outgoing calls can be placed by the sender of this 2013 message. 2015 More details on the use of this AVP can be found in Sec. 6.1. 2017 Firmware Revision 2019 0 1 2 3 2020 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 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 |0|0|0|0|0|0| 8 | 0 | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | 6 | Firmware Revision | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 The Firmware Revision AVP within a Start-Control-Connection-Reply 2027 indicates the firmware revision of the issuing device. The 2028 Attribute is 6, it is not a mandatory AVP, the Value field is a 2029 16-bit integer encoded in a vendor specific format. For devices 2030 which do not have a firmware revision (general purpose computers 2031 running L2TP software modules, for instance), the revision of the 2032 L2TP software module may be reported instead. This AVP is 2033 optional. 2035 Host Name 2037 0 1 2 3 2038 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 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 |1|0|0|0|0|0| 6 + Host Name len | 0 | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | 7 | Host Name... 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 The Host Name AVP within a Start-Control-Connection-Reply 2046 indicates the name of the issuing LAC or LNS. See the notes in 2047 section 6.1 concerning Host Name contents. It is encoded as the 2048 Attribute 7, mandatory, with the indicated number of octets 2049 representing the host name string. This AVP MUST be present. 2051 Vendor Name 2053 0 1 2 3 2054 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 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 |0|0|0|0|0|0| 6+Vendor Name len | 0 | 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | 8 |Vendor Name... 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 The Vendor Name AVP within a Start-Control-Connection-Reply 2062 contains a vendor specific string describing the type of LAC or 2063 LNS being used. It is encoded as the Attribute 8, not mandatory, 2064 with the indicated number of octets representing the vendor 2065 string. This AVP is optional. 2067 Assigned Tunnel ID 2069 0 1 2 3 2070 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 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 |1|0|0|0|0|0| 8 | 0 | 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 | 9 | Tunnel ID | 2075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply 2078 specifies the Tunnel ID which the receiving peer MUST use in all 2079 subsequent packets. It is encoded as the Attribute 9, mandatory, 2080 with a 16-bit non-zero Tunnel ID value. This AVP MUST be present. 2082 Receive Window Size 2084 0 1 2 3 2085 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 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 |1|0|0|0|0|0| 8 | 0 | 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 | 10 | size | 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 The Receive Window Size AVP within a Start-Control-Connection- 2093 Reply specifies the receive window size being offered to the 2094 remote peer. The Attribute value is 10, indicating Receive Window 2095 Size, and is mandatory. This AVP itself is optional. Value is a 2096 16-bit word indicating the offered window size. If absent, the 2097 peer must assume a value of 4 for its transmit window. The remote 2098 peer may send the specified number of control messages before it 2099 must wait for an acknowledgment. 2101 Challenge 2103 0 1 2 3 2104 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 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 |1|0|0|0|0|0| 6 + Challenge len | 0 | 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 | 11 | Challenge... 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 The Challenge AVP within a Start-Control-Connection-Reply 2112 indicates that the peer wishes to authenticate the tunnel 2113 initiator using a CHAP-style authentication mechanism. It is 2114 encoded as the Attribute 11, mandatory, with at least one octet of 2115 challenge value embedded. If this AVP is not present, it 2116 indicates to the receiving peer that the sender does not wish to 2117 authenticate that peer. 2119 Challenge Response 2121 0 1 2 3 2122 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 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 |1|0|0|0|0|0| 22 | 0 | 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 | 13 | Response... | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | Response... (128 bits) | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 The Response AVP within a Start-Control-Connection-Reply packet 2132 provides a response to a challenge received. The Attribute value 2133 is 13, indicating Response, and the Value field is a 128-bit value 2134 reflecting the CHAP-style response to the challenge. This AVP 2135 marked mandatory, and MUST be present if a challenge was received 2136 and this Start-Control-Connection-Reply indicates success. For 2137 purposes of the ID value in the CHAP response calculation, the 2138 value 2 (corresponding to the Value field of the Start-Control- 2139 Connection-Reply AVP) MUST be used. 2141 6.3 Start-Control-Connection-Connected (SCCCN) 2143 The Start-Control-Connection-Connected message is an L2TP control 2144 message sent in reply to a received Start-Control-Connection-Reply 2145 message. This message provides closure to the tunnel establishment 2146 process, and includes a challenge response if the peer sent a 2147 challenge in the Start-Control-Connection-Reply message. 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | L2TP Control Message Header | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | Start-Control-Connection-Connected | 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | Challenge Response | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+ 2157 Start-Control-Connection-Connected 2159 0 1 2 3 2160 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 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 |1|0|0|0|0|0| 8 | 0 | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | 0 | 3 | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 The Message Type AVP contains a Value of 3, indicating Start- 2168 Control-Connection-Connected. The Flags indicate a mandatory 2169 option. 2171 Challenge Response 2173 0 1 2 3 2174 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 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 |1|0|0|0|0|0| 22 | 0 | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | 13 | Response... | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 | Response... (128 bits) | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 The Challenge Response AVP within a Start-Control-Connection- 2184 Connected packet provides a response to a challenge received. The 2185 Attribute value is 13, indicating Response, and the Value field is 2186 a 128-bit value reflecting the CHAP-style response to the 2187 challenge. This AVP is marked mandatory, and MUST be present if a 2188 challenge was received, otherwise MUST be omitted. For purposes 2189 of the ID value in the CHAP response calculation, the value 3 2190 (corresponding to the Value field of the Start-Control- 2191 Connection-Connected AVP) MUST be used. 2193 6.4 Stop-Control-Connection-Notification (StopCCN) 2195 The Stop-Control-Connection-Notification is an L2TP control message 2196 sent by one peer of an LAC-LNS control connection to inform the other 2197 peer that the control connection should be closed. In addition to 2198 closing the control connection, all active user calls are implicitly 2199 cleared. The reason for issuing this request is indicated in the 2200 Result Code AVP. 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | L2TP Control Message Header | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | Stop-Control-Connection-Notification| 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | Assigned Tunnel ID | 2208 | Result Code | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+ 2211 Stop-Control-Connection-Notification AVP 2213 0 1 2 3 2214 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 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 |1|0|0|0|0|0| 8 | 0 | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | 0 | 4 | 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 The Message Type AVP contains a Value of 4, indicating Stop- 2222 Control-Connection-Notification. The Flags indicate a mandatory 2223 option. 2225 Assigned Tunnel ID 2227 0 1 2 3 2228 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 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 |1|0|0|0|0|0| 8 | 0 | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | 9 | Tunnel ID | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 The Attribute value is 9, indicating Assigned Tunnel ID, and is 2236 marked mandatory. This AVP MUST be present. The Value MUST be 2237 the same Assigned Tunnel ID first sent to the receiving peer. 2238 This AVP permits the peer to identify the appropriate tunnel even 2239 if Stop-Control-Connection-Notification must be sent before an 2240 Assigned Tunnel ID is received. 2242 Result Code 2244 0 1 2 3 2245 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 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 |1|0|0|0|0|0| 10 + Message len | 0 | 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | 1 | Result Code | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 | Error Code | Optional Message ... 2252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 The Result Code AVP within a Stop-Control-Connection-Notification 2255 packet indicates the reason for terminating the control channel. 2256 It is encoded as Attribute 1, indicating a Result Code AVP. This 2257 AVP is mandatory and MUST be present. The Result Code is a 16-bit 2258 word. The 16-bit word following the Result Code field contains 2259 the Error Code value, which for a Stop-Control-Connection- 2260 Notification is always 0. An optional message can follow the 2261 Error Code field. Its presence and length is indicated by the 2262 value of the AVP length field. Defined Result Code values are: 2264 1 - General request to clear control connection 2265 2 - General error--Error Code indicates the problem 2266 3 - Control channel already exists 2267 4 - Requester is not authorized to establish a control channel 2268 5 - The protocol version of the requester is not supported 2269 Error Code indicates highest version supported 2270 6 - Requester is being shut down 2271 7 - Finite State Machine error 2273 6.5 Hello 2275 The Hello message is an L2TP control message sent by either peer of a 2276 LAC-LNS control connection. This control message is used as a 2277 "keepalive" for the tunnel. 2279 The sending of Hello messages and the policy for sending them are 2280 left up to the implementation. A peer MUST NOT "expect" Hello 2281 messages at any time or interval. When a Hello is received, it MUST 2282 be ignored (after updating any effects of the indicated Nr/Ns values, 2283 and being acknowleged). 2285 Since a Hello is a control message, and control messages are reliably 2286 sent by the lower level transport, this keepalive function operates 2287 by causing the transport level to reliably deliver a message. If a 2288 media interruption has occurred, the reliable transport will be 2289 unable to deliver the Hello across, and will clean up the tunnel. 2291 Keepalives for the tunnel MAY be implemented by sending a Hello once 2292 every 60 seconds if 60 seconds have passed without receiving any 2293 message (payload or control, including ZLB messages) from the peer. 2295 Hello messages are global to the tunnel; the Call ID field of these 2296 control messages MUST be 0. 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 | L2TP Control Message Header | 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 | Hello | 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 Hello 2306 0 1 2 3 2307 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 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 |1|0|0|0|0|0| 8 | 0 | 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 | 0 | 6 | 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2314 The Message Type AVP contains a Value of 6, indicating Hello The 2315 Flags indicate a mandatory option. 2317 6.6 Outgoing-Call-Request (OCRQ) 2319 The Outgoing-Call-Request is an L2TP control message sent by the LNS 2320 to the LAC to indicate that an outbound call from the LNS is to be 2321 established. This request provides the LAC with information required 2322 to make the call. It also provides information to the LAC that is 2323 used to regulate the transmission of data to the LNS for this session 2324 once it is established. 2326 This message is the first in the "three-way handshake" used by L2TP 2327 for establishing outgoing calls. The first message requests the 2328 call; the second indicates that the call was successfully initiated. 2329 The third and final message indicates that the call was established. 2331 An LNS MUST have received a Bearer Capabilities AVP during tunnel 2332 establishment from an LAC in order to request an outgoing call to 2333 that LAC. 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | L2TP Control Message Header | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | Outgoing-Call-Request | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | Assigned Call ID | 2341 | Call Serial Number | 2342 | Minimum BPS | 2343 | Maximum BPS | 2344 | Bearer Type | 2345 | Framing Type | 2346 | Receive Window Size | 2347 | Packet Processing Delay | 2348 | Dialed Number | 2349 | Sub-Address | 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 Outgoing-Call-Request 2354 0 1 2 3 2355 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 2356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 |1|0|0|0|0|0| 8 | 0 | 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 | 0 | 7 | 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2362 The Message Type AVP contains a Value of 7, indicating Outgoing- 2363 Call-Request. The Outgoing-Call-Request encodes a request to an 2364 LAC to establish an outgoing call. The flags indicate a mandatory 2365 option. 2367 Assigned Call ID 2369 0 1 2 3 2370 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 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 |1|0|0|0|0|0| 8 | 0 | 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 | 14 | Call ID | 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 The Assigned Call ID AVP encodes the ID being assigned to this 2378 call by the LNS. The Attribute value is 14, indicating Assigned 2379 Call ID, and is marked mandatory. This AVP MUST be present. The 2380 LAC places this value in the Call ID header field of all command 2381 and payload packets that it subsequently transmits over the tunnel 2382 that belong to this call. The Call ID value is an identifier 2383 assigned by the LNS to this session. It is used to multiplex and 2384 demultiplex data sent over that tunnel between the LNS and LAC. 2386 Call Serial Number 2388 0 1 2 3 2389 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 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 |1|0|0|0|0|0| 10 | 0 | 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 | 15 | CSN (H) | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | CSN (L) | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 Call Serial Number AVP encodes an identifier assigned by the LNS to 2399 this call. Attribute is 15, indicating Call Serial Number, and is 2400 marked mandatory. This AVP MUST be present. The Call Serial Number 2401 is intended to be an easy reference for administrators on both ends of 2402 a tunnel to use when investigating call failure problems. Call Serial 2403 Numbers should be set to progressively increasing values, which are 2404 likely to be unique for a significant period of time across all 2405 interconnected LNS and LACs. Other identification information may 2406 also be prepended. 2408 Minimum BPS 2410 0 1 2 3 2411 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 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 |1|0|0|0|0|0| 10 | 0 | 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 | 16 | BPS (H) | 2416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2417 | BPS (L) | 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 Minimum BPS AVP encodes the lowest acceptable line speed for this 2421 call. Attribute is 16, Minimum BPS, and is marked mandatory. 2422 This AVP MUST be present. The BPS value indicates the speed in 2423 bits/second. 2425 Maximum BPS 2427 0 1 2 3 2428 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 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 |1|0|0|0|0|0| 10 | 0 | 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | 17 | BPS (H) | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | BPS (L) | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2437 Maximum BPS AVP encodes the highest acceptable line speed for this 2438 call. Attribute is 17, indicating Maximum BPS, and is marked 2439 mandatory. This AVP MUST be present. The BPS value indicates the 2440 speed in bits/second. 2442 Bearer Type 2444 0 1 2 3 2445 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 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 |1|0|0|0|0|0| 10 | 0 | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2454 Bearer Type AVP encodes the bearer type for the requested call. 2455 The Attribute is 18, indicating Bearer Type, and is marked 2456 mandatory. This AVP MUST be present. The Value is a 32-bit 2457 quantity indicating the bearer capability required for this 2458 outgoing call. If set, bit A indicates that the call should be on 2459 an analog channel. If set, bit D indicates that the call should 2460 be on a digital channel. Both may be set, indicating that the 2461 call can be of either type. 2463 A particular bit in the Value field of this AVP MAY only be set by 2464 the LNS if it was set in the Bearer Capabilities AVP received from 2465 the LAC during control session establishment. 2467 Framing Type 2469 0 1 2 3 2470 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 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 |1|0|0|0|0|0| 10 | 0 | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 Framing Type AVP encodes the framing type for the requested call. 2480 Attribute is 19, indicating Framing Type, and is marked mandatory. 2481 This AVP MUST be present. The 32-bit field indicates the type of 2482 PPP framing to be used for the outgoing call. If set, Bit A 2483 indicates that asynchronous framing should be used. If set, Bit S 2484 indicates that synchronous framing should be used. Both may be 2485 set, indicating that either type of framing may be used for the 2486 call. 2488 A particular bit in the Value field of this AVP MAY only be set by 2489 the LNS if it was set in the Framing Capabilities AVP received 2490 from the LAC during control session establishment. 2492 Receive Window Size 2494 0 1 2 3 2495 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 2496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2497 |1|0|0|0|0|0| 8 | 0 | 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 | 10 | Size | 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2502 Receive Window Size AVP encodes the window size being advertised 2503 by the LNS for this call. Attribute is 10, indicating Receive 2504 Window Size, and is marked mandatory. This AVP is optional. The 2505 Size value indicates the number of received data packets the LNS 2506 will buffer for this call, which is also the maximum number of 2507 data packets the LAC should send before waiting for an 2508 acknowledgment. The absence of this AVP indicates that Sequence 2509 and Acknowledgment Numbers are not to be used in the payload 2510 session for this call. 2512 Packet Processing Delay 2514 0 1 2 3 2515 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 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 |1|0|0|0|0|0| 8 | 0 | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 | 20 | Delay | 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 The Packet Processing Delay AVP encodes the delay that is expected 2523 at the LNS in processing a window full of packets sent by the LAC. 2524 Attribute is 20, indicating Packet Processing Delay, and is marked 2525 mandatory. This AVP is optional. The Delay value is specified in 2526 units of 1/10 seconds. Refer to Appendix A for a description of 2527 how this value is determined and used. 2529 Dialed Number 2531 0 1 2 3 2532 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 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 |1|0|0|0|0|0| 6+Phone Number len| 0 | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 | 21 | Phone Number.. 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 Phone Number AVP encodes the phone number to be called. Attribute 2540 is 21, indicating Phone Number, and is marked mandatory. This AVP 2541 MUST be present. The Phone Number value is an ASCII string. 2542 Contact between the administrator of the LAC and the LNS may be 2543 necessary to coordinate the value needed in this AVP. 2545 Sub-Address 2547 0 1 2 3 2548 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 2549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 |1|0|0|0|0|0| 6+Sub-Address len | 0 | 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 | 23 |Sub-Address ... 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 Sub-Address AVP encodes additional dialing information. Attribute 2556 is 23, indicating Sub-Address, and is marked mandatory. This AVP 2557 is optional. The Sub-Address value is an ASCII string. Contact 2558 between the administrator of the LAC and the LNS may be necessary 2559 to coordinate the value needed in this AVP. 2561 6.7 Outgoing-Call-Reply (OCRP) 2563 The Outgoing-Call-Reply is an L2TP control message sent by the LAC to 2564 the LNS in response to a received Outgoing-Call-Request message. The 2565 reply indicates that the LAC is able to attempt the outbound call and 2566 also returns certain parameters regarding the call attempt. 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | L2TP Control Message Header | 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 | Outgoing-Call-Reply | 2572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 | Assigned Call ID | 2574 | Physical Channel Id | 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 Outgoing-Call-Reply 2579 0 1 2 3 2580 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 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 |1|0|0|0|0|0| 8 | 0 | 2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 | 0 | 8 | 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 The Message Type AVP contains a Value of 8, indicating Outgoing- 2588 Call-Reply. The Outgoing-Call-Reply message encodes the immediate 2589 result of attempting an outgoing call request. The flags indicate a 2590 mandatory option. 2592 Assigned Call ID 2594 0 1 2 3 2595 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 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 |1|0|0|0|0|0| 8 | 0 | 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 | 14 | Call ID | 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 The Assigned Call ID AVP encodes the ID being assigned to this call 2603 by the LAC. Attribute is 14, indicating Assigned Call ID, and is 2604 marked mandatory. This AVP MUST be present. Call ID value is an 2605 identifier, unique within the tunnel, assigned by the sender to this 2606 session. The remote peer MUST place this Call ID in the Call ID 2607 portion of all future packets it sends associated with this session. 2608 It is used to multiplex and demultiplex data sent over that tunnel 2609 between the LNS and LAC. 2611 Physical Channel ID 2613 0 1 2 3 2614 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 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 |0|0|0|0|0|0| 10 | 0 | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2618 | 25 | ID (H) | 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 | ID (L) | 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 Physical Channel ID AVP encodes the vendor specific physical channel 2624 number used for the call. The Attribute value is 25, indicating 2625 Physical Channel ID, and is marked optional. This AVP itself is 2626 optional. ID is a 32-bit value in network byte order. The value is 2627 used for logging purposes only. 2629 6.8 Outgoing-Call-Connected (OCCN) 2631 Outgoing-Call-Connected is an L2TP control message sent by the LAC to 2632 the LNS to indicate that the result of a requested outgoing call was 2633 successful. The LAC MUST send the corresponding Outgoing-Call-Reply 2634 to the LNS before sending this message. This message provides 2635 information to the LNS about the particular parameters used for the 2636 call. It provides information to allow the LNS to regulate the 2637 transmission of data to the LAC for this session. 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 | L2TP Control Message Header | 2641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 | Outgoing-Call-Connected | 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 | (Tx) Connect Speed | 2645 | Framing Type | 2646 | Receive Window Size | 2647 | Packet Processing Delay | 2648 | Rx Connect Speed | 2649 | Sequencing Required | 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2652 Outgoing-Call-Connected 2654 0 1 2 3 2655 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 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 |1|0|0|0|0|0| 8 | 0 | 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 | 0 | 9 | 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2662 The Message Type AVP contains a Value of 9, indicating Outgoing- 2663 Call-Connected. The Outgoing-Call-Connected message encodes the 2664 final result of an outgoing call request. The flags indicate a 2665 mandatory option. 2667 (Tx) Connect Speed 2669 0 1 2 3 2670 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 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 |1|0|0|0|0|0| 10 | 0 | 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | 24 | BPS (H) | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 | BPS (L) | 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2679 (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen 2680 for the connection attempt. The Attribute value is 24, indicating 2681 (Tx) Connect Speed, and is marked mandatory. This AVP MUST be 2682 present. BPS is a 32-bit value indicating the speed in bits/second. 2684 When the optional Rx Connect Speed AVP is present, the value in this 2685 AVP represents the transmit connect speed, from the perspective of 2686 the LAC (e.g. data flowing from the LAC to the client). When the 2687 optional Rx Connect Speed AVP is NOT present, the connection speed 2688 between the client and LAC is assumed to be symmetric and is 2689 represented by the single value in this AVP. 2691 Framing Type 2693 0 1 2 3 2694 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 2695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 |1|0|0|0|0|0| 10 | 0 | 2697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2698 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 Framing Type AVP encodes the framing type for the call. The 2704 Attribute value is 19, indicating Framing Type, and is marked 2705 mandatory. This AVP MUST be present. The bit field indicates the 2706 type of PPP framing used for the call. If set, bit A indicates that 2707 asynchronous framing is being used. If set, bit S indicates that 2708 synchronous framing is being used. A particular type of framing may 2709 be used only if it was specified in the Framing Type AVP of the 2710 Outgoing-Call-Request issued by the LNS. The framing type MAY be used 2711 as an indication to PPP on the LNS as to what link options to use for 2712 LCP (refer to "PPP in HDLC-like Framing" [14]). 2714 Receive Window Size 2716 0 1 2 3 2717 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 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 |1|0|0|0|0|0| 8 | 0 | 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 | 10 | Size | 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 Receive Window Size AVP encodes the window size being offered by the 2725 LNS for this call. The Attribute value is 10, indicating Receive 2726 Window Size, and is marked mandatory. The Size is a 16-bit value 2727 indicating the number of received data packets the LAC will buffer 2728 for this call, which is also the maximum number of data packets the 2729 LNS should send before waiting for an acknowledgment. This AVP is 2730 present only if Sequence and Acknowledgment Numbers are to be used in 2731 the payload session for this call. 2733 Packet Processing Delay 2735 0 1 2 3 2736 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 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 |1|0|0|0|0|0| 8 | 0 | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 | 20 | Delay | 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 Packet Processing Delay AVP encodes the delay the LAC expects for 2744 processing a window full of packets sent by the LNS. The Attribute 2745 value is 20, indicating Packet Processing Delay, and is marked 2746 mandatory. This AVP is optional. The Delay value is specified in 2747 units of 1/10 seconds. Refer to Appendix A to see a description of 2748 how this value is determined and used. 2750 Rx Connect Speed 2752 0 1 2 3 2753 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 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2755 |0|0|0|0|0|0| 10 | 0 | 2756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2757 | 38 | BPS (H) | 2758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2759 | BPS (L) | 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 Rx Connect Speed BPS AVP encodes the receive speed of the facility 2763 chosen for the connection attempt. The Attribute value is 38, 2764 indicating Rx Connect Speed, and is marked optional. The Rx Connect 2765 Speed represents the speed of the connection from the perspective of 2766 the LAC (e.g. data flowing from the client to the LAC). Presence of 2767 this AVP implies that the connection speed may be asymmetric, with 2768 the transmit connect speed given in the (Tx) Connect Speed AVP. BPS 2769 is a 32-bit value indicating the speed in bits/second. 2771 Sequencing Required 2773 0 1 2 3 2774 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 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 |1|0|0|0|0|0| 6 | 0 | 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | 39 | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 The Sequencing Required AVP indicates to the LNS that Sequence 2782 Numbers MUST always be present, thus the ability to dynamically drop 2783 sequencing as described in section 4.2 is not an available option. 2784 The Attribute value is 38, Sequencing Required, and is marked 2785 mandatory. The presence of this AVP is optional. This AVP MUST NOT 2786 be present if the Receive Window Size AVP is not present. There is no 2787 value field. 2789 6.9 Incoming-Call-Request (ICRQ) 2791 Incoming-Call-Request is an L2TP control message sent by the LAC to 2792 the LNS to indicate that an inbound call is to be established from 2793 the LAC. This request provides the LNS with parameter information 2794 for the incoming call. 2796 This message is the first in the "three-way handshake" used by L2TP 2797 for establishing incoming calls. The LAC may defer answering the 2798 call until it has received an Incoming-Call-Reply from the LNS 2799 indicating that the call should be established. This mechanism 2800 allows the LNS to obtain sufficient information about the call before 2801 determining whether the call should be answered or not. 2802 Alternatively, the LAC may answer the call, negotiate LCP and PPP 2803 authentication, and use the information gained to choose the LNS. In 2804 this case, the call has already been answered by the time the 2805 Incoming-Call-Reply message is received; the LAC simply spoofs the 2806 "call indication/answer call" phase in this case. 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 | L2TP Control Message Header | 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2811 | Incoming-Call-Request | 2812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2813 | Assigned Call ID | 2814 | Call Serial Number | 2815 | Bearer Type | 2816 | Physical Channel ID | 2817 | Dialed Number | 2818 | Dialing Number | 2819 | Sub-Address | 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 Incoming-Call-Request 2824 0 1 2 3 2825 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 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 |1|0|0|0|0|0| 8 | 0 | 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | 0 | 10 | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 The Message Type AVP contains a Value of 10, indicating Incoming- 2833 Call-Request. The Incoming-Call-Request message encodes an incoming 2834 call being indicated by the LAC. The flags indicate a mandatory 2835 option. 2837 Assigned Call ID 2839 0 1 2 3 2840 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 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 |1|0|0|0|0|0| 8 | 0 | 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2844 | 14 | Call ID | 2845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2847 The Assigned Call ID AVP encodes the ID being assigned to this call 2848 by the LAC. The Attribute value is 14, indicating Assigned Call ID, 2849 and is marked mandatory. This AVP MUST be present. The LNS places 2850 this value in the Call ID header field of all command and payload 2851 packets that belong to this call and are subsequently transmitted 2852 over the tunnel. The Call ID value is an identifier assigned by the 2853 LAC to this session. It is used to multiplex and demultiplex data 2854 sent over that tunnel between the LNS and LAC. 2856 Call Serial Number 2858 0 1 2 3 2859 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 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2861 |1|0|0|0|0|0| 10 | 0 | 2862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2863 | 15 | CSN (H) | 2864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 | CSN (L) | 2866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 Call Serial Number AVP encodes an identifier assigned by the LAC to 2869 this call. The Attribute value is 15, Call Serial Number, and is 2870 marked mandatory. This AVP MUST be present. Please refer to section 2871 6.6 for a description of the contents of this AVP. 2873 Bearer Type 2875 0 1 2 3 2876 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 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 |1|0|0|0|0|0| 10 | 0 | 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2880 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2882 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2885 Bearer Type AVP encodes the bearer type for the incoming call. The 2886 Attribute value is 18, Bearer Type, and is marked mandatory. This 2887 AVP is optional. The Value is a 32-bit field indicating the bearer 2888 capability being used by the incoming call. If set, bit A indicates 2889 that the call is on an analog channel. If set, bit D indicates that 2890 the call is on a digital channel. It is valid to set neither the A 2891 nor D bits. Such a setting may indicate that the call was not 2892 received over a physical link (e.g if the LAC and PPP are located in 2893 the same subsystem). 2895 Physical Channel ID 2897 0 1 2 3 2898 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 2899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2900 |0|0|0|0|0|0| 10 | 0 | 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 | 25 | ID (H) | 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2904 | ID (L) | 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2906 Physical Channel ID AVP encodes the vendor specific physical channel 2907 number used for the call. The Attribute value is 25, Physical 2908 Channel ID, and is marked optional. The presence of this AVP is 2909 optional. ID is a 32-bit value in network byte order. The value is 2910 used for logging purposes only. 2912 Dialed Number 2914 0 1 2 3 2915 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 2916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2917 |1|0|0|0|0|0| 6+Phone Number len| 0 | 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 | 21 | Phone Number.. 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2922 Dialed Number AVP encodes the dialed number for the incoming call, 2923 that is, DNIS. The Attribute value is 21, Dialed Number, and is 2924 marked mandatory. The presence of this AVP is optional. The value 2925 is an ASCII string. 2927 Dialing Number 2929 0 1 2 3 2930 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 2931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2932 |1|0|0|0|0|0| 6+Phone Number len| 0 | 2933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2934 | 22 |Phone Number... 2935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 Dialing Number AVP encodes the originating number for the incoming 2938 call, that is, CLID. The Attribute value is 22, Dialing Number, and 2939 is marked mandatory. The presence of this AVP is optional. The 2940 value is an ASCII string. Contact between the administrator of the 2941 LAC and the LNS may be necessary to coordinate the value needed in 2942 this AVP. 2944 Sub-Address 2946 0 1 2 3 2947 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 2948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2949 |1|0|0|0|0|0| 6+Sub-Address len | 0 | 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 | 23 |Sub-Address ... 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2954 Sub-Address AVP encodes additional dialing information. The 2955 Attribute value is 23, Sub-Address, and is marked mandatory. The 2956 presence of this AVP is optional. The Sub-Address value is an ASCII 2957 string. Contact between the administrator of the LAC and the LNS may 2958 be necessary to coordinate the value needed in this AVP. 2960 6.10 Incoming-Call-Reply (ICRP) 2962 The Incoming-Call-Reply is an L2TP control message sent by the LNS to 2963 the LAC in response to a received Incoming-Call-Request message. The 2964 reply indicates that the request was successful. It also provides 2965 information to allow the LAC to regulate the transmission of data to 2966 the LNS for this session. 2968 This message is the second in the three-way handshake used by L2TP 2969 for establishing incoming calls. It indicates to the LAC that the 2970 call should be answered. 2972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2973 | L2TP Control Message Header | 2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2975 | Incoming-Call-Reply | 2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2977 | Assigned Call ID | 2978 | Receive Window Size | 2979 | Packet Processing Delay | 2980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2982 Incoming-Call-Reply 2984 0 1 2 3 2985 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 2986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2987 |1|0|0|0|0|0| 8 | 0 | 2988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2989 | 0 | 11 | 2990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2992 The Message Type AVP contains a Value of 11, indicating Incoming- 2993 Call-Reply. The Incoming-Call-Reply message encodes a response by 2994 the LNS to the incoming call indication given by the LAC. The flags 2995 indicate a mandatory option. 2997 Assigned Call ID 2999 0 1 2 3 3000 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 3001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3002 |1|0|0|0|0|0| 8 | 0 | 3003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3004 | 14 | Call ID | 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3007 The Assigned Call ID AVP encodes the ID being assigned to this call 3008 by the LNS. The Attribute value is 14, indicating Assigned Call ID, 3009 and is marked mandatory. This AVP MUST be present. The LAC places 3010 this value in the Call ID header field of all command and payload 3011 packets that it subsequently transmits over the tunnel that belong to 3012 this call. The Call ID value is an identifier assigned by the LNS to 3013 this session. It is used to multiplex and demultiplex data sent over 3014 that tunnel between the LNS and LAC. 3016 Receive Window Size 3018 0 1 2 3 3019 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 3020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3021 |1|0|0|0|0|0| 8 | 0 | 3022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3023 | 10 | Size | 3024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3026 Receive Window Size AVP encodes the receive window size being offered 3027 by the LNS for this call. The Attribute value is 10, Receive Window 3028 Size, and is marked mandatory. The Size value indicates the number 3029 of received data packets the LNS will buffer for this call, which is 3030 also the maximum number of data packets the LAC should send before 3031 waiting for an acknowledgment. This AVP is present only if Sequence 3032 and Acknowledgment Numbers are to be used in the payload session for 3033 this call. 3035 Packet Processing Delay 3037 0 1 2 3 3038 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 3039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3040 |1|0|0|0|0|0| 8 | 0 | 3041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3042 | 20 | Delay | 3043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3045 Packet Processing Delay AVP encodes the expected delay that occurs at 3046 the LNS in processing a window full of packets sent by the LAC. The 3047 Attribute value is 20, Packet Processing Delay AVP, and is marked 3048 mandatory. The presence of this AVP is optional. The Delay value is 3049 specified in units of 1/10 seconds. Refer to Appendix A to see a 3050 description of how this value is determined and used. 3052 6.11 Incoming-Call-Connected (ICCN) 3054 The Incoming-Call-Connected message is an L2TP control message sent 3055 by the LAC to the LNS in response to a received Incoming-Call-Reply. 3056 It provides information to the LNS about particular parameters used 3057 for the call. It also provides information to allow the LNS to 3058 regulate the transmission of data to the LAC for this session. 3060 This message is the third in the three-way handshake used by L2TP for 3061 establishing incoming calls. It provides a mechanism for providing 3062 the LNS with additional information about the call that cannot, in 3063 general, be obtained at the time the Incoming-Call-Request is issued 3064 by the LAC. 3066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3067 | L2TP Control Message Header | 3068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3069 | Incoming-Call-Connected | 3070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3071 | (Tx) Connect Speed | 3072 | Framing Type | 3073 | Receive Window Size | 3074 | Packet Processing Delay | 3075 | Initial Received LCP CONFREQ | 3076 | Last Sent LCP CONFREQ | 3077 | Last Received LCP CONFREQ | 3078 | Proxy authen type | 3079 | Proxy authen name | 3080 | Proxy authen challenge | 3081 | Proxy authen ID | 3082 | Proxy authen response | 3083 | Private Group ID | 3084 | Rx Connect Speed | 3085 | Sequencing Required | 3086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 Incoming-Call-Connected 3090 0 1 2 3 3091 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 3092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3093 |1|0|0|0|0|0| 8 | 0 | 3094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3095 | 0 | 12 | 3096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3098 The Message Type AVP contains a Value of 12, indicating Incoming- 3099 Call-Connected. The Incoming-Call-Connected message encodes a 3100 response by the LAC to the Incoming-Call-Reply message sent by the 3101 LAC. The flags indicate a mandatory option. 3103 (Tx) Connect Speed 3105 0 1 2 3 3106 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 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 |1|0|0|0|0|0| 10 | 0 | 3109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3110 | 24 | BPS (H) | 3111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3112 | BPS (L) | 3113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3115 (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen 3116 for the connection attempt. The Attribute value is 24, indicating 3117 (Tx) Connect Speed, and is marked mandatory. This AVP MUST be 3118 present. BPS is a 32-bit value indicating the speed in bits/second. 3120 When the optional Rx Connect Speed AVP is present, the value in this 3121 AVP represents the transmit connect speed, from the perspective of 3122 the LAC (e.g. data flowing from the LAC to the client). When the 3123 optional Rx Connect Speed AVP is NOT present, the connection speed 3124 between the client and LAC is assumed to be symmetric and is 3125 represented by the single value in this AVP. 3127 Framing Type 3129 0 1 2 3 3130 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 3131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3132 |1|0|0|0|0|0| 10 | 0 | 3133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3134 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 3135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3136 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 3137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 Framing Type AVP encodes the framing type for the call. The 3140 Attribute value is 19, Framing Type, and is marked mandatory. This 3141 AVP MUST be present. The value is a 32-bit bit field indicating the 3142 type of PPP framing used for the call. If set, bit A indicates that 3143 asynchronous framing is being used. If set, bit S indicates that 3144 synchronous framing is being used. A particular type of framing may 3145 be used only if was specified in the Value field of the Framing 3146 Capabilities AVP received from the LNS during control session 3147 establishment. The framing type MAY be used as an indication to PPP 3148 on the LNS as to what link options to use for LCP if renegotiation is 3149 necessary (refer to "PPP in HDLC-like Framing" [14]). 3151 Receive Window Size 3153 0 1 2 3 3154 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 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 |1|0|0|0|0|0| 8 | 0 | 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | 10 | Size | 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 Receive Window Size AVP encodes the window size being offered by the 3162 LAC for this call. The Attribute value is 10, Receive Window Size, 3163 and is marked mandatory. This AVP is present only if Sequence and 3164 Acknowledgment Numbers are to be used in the payload session for this 3165 call. The 16-bit Size value indicates the number of received data 3166 packets the LAC will buffer for this call, which is also the maximum 3167 number of data packets the LNS should send before waiting for an 3168 acknowledgment. 3170 Packet Processing Delay 3172 0 1 2 3 3173 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 3174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 |1|0|0|0|0|0| 8 | 0 | 3176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3177 | 20 | Delay | 3178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3180 Packet Processing Delay AVP encodes the delay the LAC expects for 3181 processing a window full of packets sent by the LNS. The Attribute 3182 value is 20, Packet Processing Delay, and is marked mandatory. The 3183 presence of this AVP is optional. The 16-bit Delay value is 3184 specified in units of 1/10 seconds. Refer to Appendix A to see a 3185 description of how this value is determined and used. 3187 Initial Received LCP CONFREQ 3189 0 1 2 3 3190 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 3191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3192 |0|0|0|0|0|0| 6+LCP CONFREQ len | 0 | 3193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3194 | 26 | LCP CONFREQ... 3195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3197 The LAC may have answered the phone call and negotiated LCP with the 3198 dial-in client in order to establish the client's apparent identity. 3199 In this case, this option may be included to indicate the link 3200 properties the client requested in its initial LCP CONFREQ request. 3201 The Attribute value is 26, Initial Received LCP CONFREQ, and is 3202 marked optional. The presence of this AVP is optional. The Value 3203 field is a copy of the body of the initial CONFREQ received, starting 3204 at the first option within this packet's body. 3206 Last Sent LCP CONFREQ 3208 0 1 2 3 3209 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 3210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3211 |0|0|0|0|0|0| 6+LCP CONFREQ len | 0 | 3212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3213 | 27 | LCP CONFREQ... 3214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3216 See Initial Received LCP CONFREQ above for rationale. The Attribute 3217 value is 27, Last Sent LCP CONFREQ, and is marked optional. The 3218 presence of this AVP is optional. The Value field is a copy of the 3219 body of the final CONFREQ sent to the client to complete LCP 3220 negotiation, starting at the first option within this packet's body. 3222 Last Received LCP CONFREQ 3224 0 1 2 3 3225 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 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 |0|0|0|0|0|0| 6+LCP CONFREQ len | 0 | 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 | 28 | LCP CONFREQ... 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3232 See Initial Received LCP CONFREQ above for rationale. The Attribute 3233 value is 28, Last Received LCP CONFREQ, and is marked optional. The 3234 presence of this AVP is optional. The Value field is a copy of the 3235 body of the final CONFREQ received from the client to complete LCP 3236 negotiation, starting at the first option within this packet's body. 3238 Proxy Authen Type 3240 0 1 2 3 3241 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 3242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3243 |0|0|0|0|0|0| 8 | 0 | 3244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3245 | 29 | Type | 3246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3248 The Attribute value is 29, Proxy Authen Type, and is optional. This 3249 AVP MUST be present if proxy authentication is to be utilized. If it 3250 is not present, then it is assumed that this peer cannot perform 3251 proxy authentication, perhaps requiring a restart of the 3252 authentication phase at the LNS if the client has already entered 3253 this phase with the LAC. The value Type is a 16-bit word, holding a 3254 value: 3256 1 - Textual username/password exchange 3257 2 - PPP CHAP 3258 3 - PPP PAP 3259 4 - None 3260 5 - Microsoft CHAP (MSCHAP) 3262 Associated AVP's for each type of authentication follow. 3264 Proxy Authen Name 3266 0 1 2 3 3267 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 3268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3269 |0|0|0|0|0|0| 6 + Name length | 0 | 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3271 | 30 | Name... 3272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3274 The Attribute value is 30, Proxy Authen Name, and is marked optional. 3275 This AVP MUST be present for Proxy Authen Type values 1, 2, 3 and 5. 3277 The Name field contains the name specified in the client's 3278 authentication response. Note that the AVP H bit may be desirable 3279 for obscuring the cleartext name. 3281 Proxy Authen Challenge 3283 0 1 2 3 3284 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 3285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 |0|0|0|0|0|0| 6 + Challenge len | 0 | 3287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3288 | 31 | Challenge... 3289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3291 The Attribute value is 31, Proxy Authen Challenge, and is marked 3292 optional. The AVP itself MUST be present for Proxy authen types 2 3293 and 5. The Challenge field contains the value presented to the 3294 client by the LAC. 3296 Proxy Authen ID 3298 0 1 2 3 3299 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 3300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3301 |0|0|0|0|0|0| 8 | 0 | 3302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3303 | 32 | ID | 3304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 The Attribute value is 32, Proxy Authen ID, and is marked optional. 3307 The AVP itself MUST be present for Proxy authen types 2, 3 and 5. 3308 For CHAP and MSCHAP, the ID field contains the byte ID value 3309 presented to the client by the LAC in its Challenge. For PAP, it is 3310 the Identifier value of the Authenticate-Request. The most 3311 significant 8 bits of ID MUST be 0, and are reserved. 3313 Proxy Authen Response 3315 0 1 2 3 3316 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 3317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 |0|0|0|0|0|0| 6 + Response len | 0 | 3319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 | 33 | Response... 3321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3323 The Attribute value is 33, Proxy Authen Response, and is marked 3324 optional. The AVP itself MUST be present for Proxy authen types 1, 3325 2, 3 and 5. The Response field contains the client's response to the 3326 challenge. For Proxy authen types 2 and 5, this field contains the 3327 response value received by the LAC. For types 1 or 3, it contains 3328 the clear text password received from the client by the LAC. In the 3329 case of cleartext passwords, use of the AVP H bit is recommended. 3331 Private Group ID 3333 0 1 2 3 3334 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 3335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3336 |0|0|0|0|0|0| 6+Private ID len | 0 | 3337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3338 | 37 | Private Group ID ... 3339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 PrivateGroup ID AVP is used by the LAC to indicate that this call is 3342 to be associated with a particular customer group. The Attribute is 3343 37, Private Group ID, and is marked optional. The presence of this 3344 AVP is optional. The LNS MAY treat the PPP session as well as 3345 network traffic through this session specially in a manner determined 3346 by the peer. For example, if the LNS is individually connected to 3347 several private networks using unregistered addresses, this AVP may 3348 be included by the LAC to indicate that a given call should be 3349 associated with one of the private networks. 3351 The Private Group ID is a string corresponding to a table in the LNS 3352 that defines the particular characteristics of the selected group. A 3353 LAC MAY determine the Private Group ID from a RADIUS response 3354 containing the PrivateGroupID attribute [13]. 3356 Rx Connect Speed 3358 0 1 2 3 3359 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 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 |0|0|0|0|0|0| 10 | 0 | 3362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 | 38 | BPS (H) | 3364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3365 | BPS (L) | 3366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3368 Rx Connect Speed BPS AVP encodes the receive speed of the facility 3369 chosen for the connection attempt. The Attribute value is 38, 3370 indicating Rx Connect Speed, and is marked optional. The Rx Connect 3371 Speed represents the speed of the connection from the perspective of 3372 the LAC (e.g. data flowing from the client to the LAC). Presence of 3373 this AVP implies that the connection speed may be asymmetric, with 3374 the transmit connect speed given in the (Tx) Connect Speed AVP. BPS 3375 is a 32-bit value indicating the speed in bits/second. 3377 Sequencing Required 3379 0 1 2 3 3380 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 3381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3382 |1|0|0|0|0|0| 6 | 0 | 3383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3384 | 39 | 3385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3387 The Sequencing Required AVP indicates to the LNS that Sequence 3388 Numbers MUST always be present, thus the ability to dynamically drop 3389 sequencing as described in section 4.2 is not an available option. 3390 The Attribute value is 38, Sequencing Required, and is marked 3391 mandatory. The presence of this AVP is optional. This AVP MUST NOT 3392 be present if the Receive Window Size AVP is not present. There is no 3393 value field. 3395 6.12 Call-Disconnect-Notify (CDN) 3397 The Call-Disconnect-Notify message is an L2TP control message sent to 3398 request disconnection of a specific call within the tunnel. Its 3399 purpose is to inform the peer of the disconnection and the reason why 3400 the disconnection occurred. The peer MUST clean up any resources, 3401 and does not send back any indication of success or failure for such 3402 cleanup. 3404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3405 | L2TP Control Message Header | 3406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 | Call-Disconnect-Notify | 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3409 | Result Code | 3410 | Q.931 Cause Code | 3411 | Assigned Call ID | 3412 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3414 Call-Disconnect-Notify 3416 0 1 2 3 3417 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 3418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3419 |1|0|0|0|0|0| 8 | 0 | 3420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3421 | 0 | 14 | 3422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3424 The Message Type AVP contains a Value of 14, indicating Call- 3425 Disconnect-Notify. The Call-Disconnect-Notify message encodes a 3426 disconnect indication for a specific call within the tunnel. The 3427 flags indicate a mandatory option. 3429 Result Code 3431 0 1 2 3 3432 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 3433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3434 |1|0|0|0|0|0| 10 + Message len | 0 | 3435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 | 1 | Result Code | 3437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3438 | Error Code | Optional Message ... 3439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3441 The Result Code AVP within a Call-Disconnect-Notify message 3442 indicates the reason for the call disconnect. It is encoded as 3443 Attribute 1, indicating a Result Code AVP. This AVP is mandatory 3444 and MUST be present. The Result Code is a 16-bit word. The 16- 3445 bit word following the Result Code field contains the Error Code 3446 value. The Result Code value indicates whether the Error Code 3447 value is meaningful or not. If Error Code is not meaningful it 3448 MUST be set to 0. An optional error message can follow the Error 3449 Code field; its presence and length is indicated by the value of 3450 the AVP length field. Defined Result Code values are: 3452 1 - Call disconnected due to loss of carrier 3453 2 - Call disconnected for the reason indicated in Error Code. 3454 3 - Call disconnected for administrative reasons 3455 4 - Call failed due to no appropriate facilities being 3456 available (temporary condition) 3457 5 - Call failed due to no appropriate facilities being 3458 available (permanent condition) 3459 6 - Invalid destination 3460 7 - Call failed due to no carrier detected 3461 8 - Call failed due to detection of a busy signal 3462 9 - Call failed due to lack of a dial tone 3463 10 - Call was not established within time allotted by LAC 3464 11 - Call was connected but no appropriate framing was detected 3466 Q.931 Cause Code 3468 0 1 2 3 3469 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 3470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3471 |1|0|0|0|0|0| 9+Advisory Msg len| 0 | 3472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3473 | 12 | Cause Code | 3474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3475 | Cause Msg |Advisory Msg...| 3476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3478 The Q.931 Cause Code AVP is used to give additional information in 3479 case of unsolicited call disconnection. The Attribute value is 12, 3480 Cause Code, and is marked mandatory. The presence of this AVP is 3481 optional. The Cause Code AVP is used to give additional information 3482 about the reason for disconnecting. It is only relevant when the LAC 3483 is using Q.931/DSS1 for the call. Cause Code is the returned Q.931 3484 Cause code and Cause Msg is the returned Q.931 message code (e.g., 3485 DISCONNECT) associated with the Cause Code. Both values are returned 3486 in their native ITU encodings [16]. An additional ASCII text 3487 Advisory Message may also be included (presence indicated by the AVP 3488 length) to further explain the reason for disconnecting. 3490 Assigned Call ID 3492 0 1 2 3 3493 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 3494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3495 |1|0|0|0|0|0| 8 | 0 | 3496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3497 | 14 | Call ID | 3498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3500 The Assigned Call ID which was provided to the peer, included in the 3501 Call-Disconnect-Notify message. This permits a connection to be 3502 terminated even before the peer has provided its own Assigned Call ID 3503 (the Call ID field in the control message header is 0). The 3504 Attribute value is 14, Assigned Call ID, and is marked mandatory. 3505 This AVP MUST be present. 3507 6.13 WAN-Error-Notify (WEN) 3509 The WAN-Error-Notify message is an L2TP control message sent by the 3510 LAC to the LNS to indicate WAN error conditions (conditions that 3511 occur on the interface supporting PPP). The counters in this message 3512 are cumulative. This message should only be sent when an error 3513 occurs, and not more than once every 60 seconds. The counters are 3514 reset when a new call is established. 3516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3517 | L2TP Control Message Header | 3518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3519 | WAN-Error-Notify | 3520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3521 | Call Errors | 3522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3524 WAN-Error-Notify 3526 0 1 2 3 3527 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 3528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3529 |1|0|0|0|0|0| 8 | 0 | 3530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3531 | 0 | 15 | 3532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3534 The Message Type AVP contains a Value of 15, indicating WAN-Error- 3535 Notify. The WAN-Error-Notify message encodes information about line 3536 and other errors detected on the LAC's physical interface to the 3537 client. This message is sent by the LAC to the LNS. The flags 3538 indicate a mandatory option. 3540 Call Errors 3542 0 1 2 3 3543 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 3544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3545 |1|0|0|0|0|0| 32 | 0 | 3546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3547 | 34 | Reserved | 3548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3549 | CRC Errors | 3550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3551 | Framing Errors | 3552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3553 | Hardware Overruns | 3554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3555 | Buffer Overruns | 3556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3557 | Time-out Errors | 3558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3559 | Alignment Errors | 3560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3562 The Call Errors AVP is used by the LAC to send error information to 3563 the LNS. The Attribute value is 34, WAN-Error-Notify, and is marked 3564 mandatory. This AVP MUST be present. The value contains the 3565 following fields: 3567 Reserved - Not used, MUST be 0 3568 CRC Errors - Number of PPP frames received with CRC errors since 3569 session was established 3570 Framing Errors - Number of improperly framed PPP packets received 3571 Hardware Overruns - Number of receive buffer over-runs since 3572 session was established 3573 Buffer Overruns - Number of buffer over-runs detected since 3574 session was established 3575 Time-out Errors - Number of time-outs since call was established 3576 Alignment Errors - Number of alignment errors since call was 3577 established 3579 6.14 Set-Link-Info (SLI) 3581 The Set-Link-Info message is an L2TP control message sent by the LNS 3582 to the LAC to set PPP-negotiated options. Because these options can 3583 change at any time during the life of the call, the LAC MUST be able 3584 to update its internal call information dynamically and update its 3585 behavior on an active PPP session. 3587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3588 | L2TP Control Message Header | 3589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3590 | Set-Link-Info | 3591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3592 | ACCM | 3593 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3595 Set-Link-Info 3597 0 1 2 3 3598 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 3599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3600 |1|0|0|0|0|0| 8 | 0 | 3601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3602 | 0 | 16 | 3603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3605 The Message Type AVP contains a Value of 16, indicating Set-Link- 3606 Info. The Set-Link-Info message encodes ACCM information sent from 3607 the LNS to the LAC after it is negotiated in LCP. The flags indicate 3608 a mandatory option. 3610 ACCM 3612 0 1 2 3 3613 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 3614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3615 |1|0|0|0|0|0| 16 | 0 | 3616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3617 | 35 | Reserved | 3618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3619 | Send ACCM | 3620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3621 | Receive ACCM | 3622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3624 The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. 3625 The Attribute value is 35, ACCM, and is marked mandatory. This 3626 attribute MUST be present. The value contains Send ACCM and Receive 3627 ACCM fields. The send ACCM value should be used by the LAC to 3628 process packets it is sends on the connection. The receive ACCM 3629 value should be used by the LAC to process incoming packets on the 3630 connection. The default values used by the LAC for both these fields 3631 are 0xFFFFFFFF. The LAC should honor these fields unless it has 3632 specific configuration information to indicate that the requested 3633 mask must be modified to permit operation. 3635 7.0 Control Connection State Machines 3637 The control messages defined in section 6 are exchanged by way of state 3638 tables defined in this section. Tables are defined for incoming call 3639 placement, outgoing call placement, as well as for initiation of the 3640 tunnel itself. The state tables do not encode timeout and 3641 retransmission behavior, as this is handled in the underlying semantics 3642 defined in 6.0.2. 3644 7.1 Control Connection Protocol Operation 3646 This section describes the operation of various L2TP control 3647 connection functions and the Control Connection messages which are 3648 used to support them. 3650 Receipt of an invalid or malformed Control Connection message should 3651 be logged appropriately, and the control connection should be closed 3652 and restarted to ensure recovery into a known state. 3654 In several cases in the following tables, a protocol message is sent, 3655 and then a "clean up" occurs. Note that regardless of the initiator 3656 of the tunnel destruction, the reliable delivery mechanism must be 3657 allowed to run (see 6.0.2) before destroying the tunnel. This 3658 permits the tunnel management messages to be reliably delivered to 3659 the peer. 3661 7.2 Control Connection States 3663 Control messages are carried over the same media as the payload 3664 messages which are carried following successful connection 3665 establishment. The L2TP control connection protocol is not 3666 distinguishable between the LNS and LAC, but is distinguishable 3667 between the originator and receiver. The originating peer is the one 3668 which first initiates establishment of the tunnel (in a tie breaker 3669 situation, this is the winner of the tie). Since either LAC or LNS 3670 can be the originator, a collision can occur. See Section 6.0.1 for 3671 a description of this and its resolution. 3673 7.2.1 Control Connection Establishment 3675 State Event Action New State 3676 ----- ----- ------ --------- 3677 idle Local Send SCCRQ wait-ctl-reply 3678 Open request 3680 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3681 acceptable 3683 idle Receive SCCRQ, Send StopCCN, idle 3684 not acceptable Clean up 3686 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3687 acceptable Send tunnel-open 3688 event to waiting 3689 sessions 3691 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3692 not acceptable Clean up 3694 wait-ctl-reply Receive SCCRQ, Clean up, idle 3695 lose tie-breaker Re-queue SCCRQ 3696 for idle state 3698 wait-ctl-conn Receive SCCCN, Send tunnel-open established 3699 acceptable event to waiting 3700 sessions 3702 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3703 not acceptable Clean up 3705 established Local Send tunnel-open established 3706 Open request event to waiting 3707 (new client) sessions 3709 established Admin Send StopCCN idle 3710 Tunnel Close Clean up 3712 wait-ctl-reply, 3713 wait-ctl-conn, 3714 established Receive StopCCN Clean up idle 3716 idle 3717 Both initiator and recipient start from this state. An initiator 3718 transmits a SCCRQ, while a recipient remains in the idle state 3719 until receiving a SCCRQ. 3721 wait-ctl-reply 3722 The originator checks to see if another connection has been 3723 requested from the same peer, and if so, handles the collision 3724 situation described in Section 6.0.1. 3726 When a SCCRP is received, it is examined for a compatible version. 3727 If the version of the reply is lower than the version sent in the 3728 request, the older (lower) version should be used provided it is 3729 supported. If the version in the reply is earlier and supported, 3730 the originator moves to the established state. If the version is 3731 earlier and not supported, a StopCCN MUST be sent to the peer and 3732 the originator cleans up and terminates the tunnel. 3734 wait-ctl-conn 3735 This is where an SCCCN is awaited; upon receipt, the challenge 3736 response is checked. The tunnel is either established, or is torn 3737 down if an authorization failure is detected. 3739 established 3740 An established connection may be terminated by either a local 3741 condition or the receipt of a Stop-Control-Connection- 3742 Notification. In the event of a local termination, the originator 3743 MUST send a Stop-Control-Connection-Notification and clean up the 3744 tunnel. 3746 If the originator receives a Stop-Control-Connection-Notification 3747 it MUST also clean up the tunnel. 3749 7.3 Timing considerations 3751 Because of the real-time nature of telephone signaling, both the LNS 3752 and LAC should be implemented with multi-threaded architectures such 3753 that messages related to multiple calls are not serialized and 3754 blocked. The call and connection state figures do not specify 3755 exceptions caused by timers. These are addressed in Section 6.0.2. 3757 7.4 Incoming calls 3759 An Incoming-Call-Request message is generated by the LAC when an 3760 associated telephone line rings. The LAC selects a Call ID and 3761 serial number and indicates the call bearer type. Modems should 3762 always indicate analog call type. ISDN calls should indicate digital 3763 when unrestricted digital service or rate adaption is used and analog 3764 if digital modems are involved. CLID, DNIS, and subaddress may be 3765 included in the message if they are available from the telephone 3766 network. 3768 Once the LAC sends the Incoming-Call-Request, it waits for a response 3769 from the LNS but it does not necessarily answer the call from the 3770 telephone network yet. The LNS may choose not to accept the call if: 3772 - No resources are available to handle more sessions 3773 - The dialed, dialing, or subaddress fields do not correspond to 3774 an authorized user 3775 - The bearer service is not authorized or supported 3777 If the LNS chooses to accept the call, it responds with an Incoming- 3778 Call-Reply which may also indicate window sizes (see Appendix B). 3779 When the LAC receives the Incoming-Call-Reply, it attempts to connect 3780 the call. A final call connected message from the LAC to the LNS 3781 indicates that the call states for both the LAC and the LNS should 3782 enter the established state. If the call terminated before the LNS 3783 could accept it, a Call-Disconnect-Notify is sent by the LAC to 3784 indicate this condition. 3786 When the dialed-in client hangs up, the call is cleared normally and 3787 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 3788 clear a call, it sends a Call-Disconnect-Notify message and cleans up 3789 its session. 3791 7.4.1 LAC Incoming Call States 3793 State Event Action New State 3794 ----- ----- ------ --------- 3795 idle Bearer Ring or Initiate local wait-tunnel 3796 Ready to indicate tunnel open 3797 incoming conn. 3799 wait-tunnel tunnel-open Send ICRQ wait-reply 3801 wait-reply Receive ICRP, Answer call, established 3802 acceptable Send ICCN 3804 wait-reply Receive ICRP, Send CDN, idle 3805 not acceptable Clean up 3807 wait-reply Receive CDN Clean up idle 3809 wait-reply Local Send CDN, idle 3810 Close request Clean up 3812 established Receive CDN Hang up bearer, idle 3813 Clean up 3815 established Local Hang up bearer, idle 3816 Close request Send CDN, 3817 Clean up 3819 established Bearer Send CDN, idle 3820 Line drop Clean up 3822 The states associated with the LAC for incoming calls are: 3824 idle 3825 The LAC detects an incoming call on one of its interfaces. 3826 Typically this means an analog line is ringing or an ISDN TE has 3827 detected an incoming Q.931 SETUP message. The LAC initiates its 3828 tunnel establishment state machine, and moves to a state waiting 3829 for confirmation of the existence of a tunnel. 3831 wait-tunnel 3832 In this state the session is waiting for either the control tunnel 3833 to be opened or for verification that the tunnel is already open. 3834 Once an indication that the tunnel has/was opened, session control 3835 messages may be exchanged. The first of these is the Incoming- 3836 Call-Request. 3838 wait-reply 3839 Incoming-Call-Reply message indicating 3840 The LAC receives either a CDN message indicating non-willingness 3841 to accept the call (general error or don't accept) and moves back 3842 into the idle state, or an Incoming-Call-Reply message indicating 3843 the call is accepted, the LAC sends an Incoming-Call-Connected 3844 message and enters the established state. 3846 established 3847 Data is exchanged over the tunnel. The call may be cleared 3848 following: 3849 An event on the connected interface. The LAC sends a Call- 3850 Disconnect-Notify message 3851 Receipt of a Call-disconnect-Notify message. The LAC cleans 3852 up, disconnecting the call. 3853 A local reason. The LAC sends a Call-Disconnect-Notify 3854 message. 3856 7.4.2 LNS Incoming Call States 3858 State Event Action New State 3859 ----- ----- ------ --------- 3860 idle Receive ICRQ, Send ICRP wait-connect 3861 acceptable 3863 idle Receive ICRQ, Send CDN, idle 3864 not acceptable Clean up 3866 wait-connect Receive ICCN Prepare for established 3867 acceptable data 3869 wait-connect Receive ICCN Send CDN, idle 3870 not acceptable Clean up 3872 wait-connect, 3873 established Receive CDN Clean up idle 3875 established Local Send CDN, idle 3876 Close request Clean up 3878 The states associated with the LNS for incoming calls are: 3880 idle 3881 An Incoming-Call-Request message is received. If the request is 3882 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 3883 and the LNS remains in the idle state. If the Incoming-Call- 3884 Request message is acceptable, an Incoming-Call-Reply is sent. 3885 The session moves to the wait-connect state. 3887 wait-connect 3888 If the session is still connected on the LAC, the LAC sends an 3889 Incoming-Call-Connected message to the LNS which then moves into 3890 established state. The LAC may send a Call-Disconnect-Notify to 3891 indicate that the incoming caller could not be connected. This 3892 could happen, for example, if a telephone user accidentally places 3893 a standard voice call to an LAC resulting in a handshake failure 3894 on the called modem. 3896 established 3897 The session is terminated either by receipt of a Call-Disconnect- 3898 Notify message from the LAC or by sending a Call-Disconnect- 3899 Notify. Clean up follows on both sides regardless of the 3900 initiator. 3902 7.5 Outgoing calls 3904 Outgoing calls are initiated by an LNS and instruct an LAC to place a 3905 call. There are three messages for outgoing calls: Outgoing-Call- 3906 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 3907 sends an Outgoing-Call-Request specifying the dialed party phone 3908 number and subaddress as well as speed and window parameters. The 3909 LAC MUST respond to the Outgoing-Call-Request message with an 3910 Outgoing-Call-Reply message once the LAC determines that the proper 3911 facilities exist to place the call and the call is administratively 3912 authorized. For example, is this LNS allowed to dial an 3913 international call? Once the outbound call is connected, the LAC 3914 sends an Outgoing-Call-Connected message to the LNS indicating the 3915 final result of the call attempt: 3917 7.5.1 LAC Outgoing Call States 3919 State Event Action New State 3920 ----- ----- ------ --------- 3921 idle Receive OCRQ, Send OCRP, wait-cs-answer 3922 acceptable Open bearer 3924 idle Receive OCRQ, Send CDN, idle 3925 not acceptable Clean up 3927 wait-cs-answer Bearer answer, Send OCCN established 3928 framing detected 3930 wait-cs-answer Bearer failure Send CDN, idle 3931 Clean up 3933 wait-cs-answer, 3934 established Receive CDN Hang up bearer, idle 3935 Clean up 3937 The states associated with the LAC for outgoing calls are: 3939 idle 3940 Received Outgoing-Call-Request. If this is received in error, 3941 respond with a Call-Disconnect-Notify. Otherwise, allocate a 3942 physical channel and send an Outgoing-Call-Reply. Place the 3943 outbound call and move to the wait-cs-answer state. 3945 wait-cs-answer 3946 If the call is not completed or a timer expires waiting for the 3947 call to complete, send a Call-Disconnect-Notify with the 3948 appropriate error condition set and go to idle state. If a 3949 circuit switched connection is established and framing is 3950 detected, send an Outgoing-Call-Connected indicating success and 3951 go to established state. 3953 established 3954 If a Call-Disconnect-Notify is received by the LAC, the telco call 3955 MUST be released via appropriate mechanisms and the session 3956 cleaned up. If the call is disconnected by the client or the 3957 called interface, a Call-Disconnect-Notify message MUST be sent to 3958 the LNS. The sender of the Call-Disconnect-Notify message returns 3959 to the idle state after sending of the message is complete. 3961 7.5.2 LNS Outgoing Call States 3963 State Event Action New State 3964 ----- ----- ------ --------- 3965 idle Local Initiate local wait-tunnel 3966 Open request tunnel-open 3968 wait-tunnel tunnel-open Send OCRQ wait-reply 3970 wait-reply Receive OCRP, none wait-connect 3971 acceptable 3973 wait-reply Receive OCRP, Send CDN idle 3974 not acceptable 3976 wait-connect Receive OCCN none established 3978 established, 3979 wait-connect Receive CDN Clean up idle 3981 wait-reply, 3982 wait-connect, 3983 established Local Send CDN idle 3984 Close request 3986 The states associated with the LNS for outgoing calls are: 3988 idle, wait-tunnel 3989 When an outgoing call is initiated, a tunnel is first created, 3990 much as the idle and wait-tunnel states for an LAC incoming call. 3991 Once a tunnel is established, an Outgoing-Call-Request message is 3992 sent to the LAC and the session moves into the wait-reply state. 3994 wait-reply 3995 If a Call-Disconnect-Notify is received, an error occurred, and 3996 the session is cleaned up and returns to idle. If an Outgoing- 3997 Call-Reply is received, the call is in progress and the session 3998 moves to the wait-connect state. 4000 wait-connect 4001 If a Call-Disconnect-Notify is received, the call failed; the 4002 session is cleaned up and returns to idle. If an Outgoing-Call- 4003 Connected is received, the call has succeeded and the session may 4004 now exchange data. 4006 established 4007 If a Call-Disconnect-Notify is received, the call has been 4008 terminated for the reason indicated in the Result and Cause Codes; 4009 the session moves back to the idle state. If the LNS chooses to 4010 terminate the session, it sends a Call-Disconnect-Notify to the 4011 LAC and then cleans up and idles its session. 4013 7.6 Tunnel Disconnection 4015 The disconnection of a tunnel consists of either peer issuing a 4016 Stop-Control-Connection-Notification. The sender of this 4017 Notification should wait a finite period of time for the 4018 acknowledgment of this message before releasing the control 4019 information associated with the tunnel. The recipient of this 4020 Notification should send an acknowledgment of the Notification and 4021 then release the associated control information. 4023 When to release a tunnel is an implementation issue and is not 4024 specified in this document. A particular implementation may use 4025 whatever policy is appropriate for determining when to release a 4026 control connection. Some implementations may leave a tunnel open for 4027 a period of time or perhaps indefinitely after the last user session 4028 for that tunnel is cleared. Others may choose to disconnect the 4029 tunnel immediately after the last user connection on the tunnel 4030 disconnects. 4032 8.0 L2TP Over Specific Media 4034 L2TP tries to be self-describing, operating at a level above the 4035 particular media over which it is carried. However, some details of 4036 its connection to media are required to permit interoperable 4037 implementations. The following sections describe details needed to 4038 permit interoperability over specific media. 4040 8.1 IP/UDP 4042 L2TP uses the registered UDP port 1701 [12]. The entire L2TP packet, 4043 including payload and L2TP header, is sent within a UDP datagram. 4044 The initiator of an L2TP tunnel picks an available source UDP port 4045 (which may or may not be 1701), and sends to the desired destination 4046 at port 1701. The recipient picks a free port on its own system 4047 (which may or may not be 1701), and sends its reply to the 4048 initiator's UDP port, setting its own UDP source port set to the free 4049 port it found. Once the source and destination ports are established, 4050 they MUST remain static for the life of the tunnel. 4052 IP fragmentation may occur as the L2TP packet travels over the IP 4053 substrate. L2TP makes no special efforts to optimize this. A LAC 4054 implementation MAY cause its LCP to negotiate for a specific MRU, 4055 which could optimize for LAC environments in which the MTU's of the 4056 path over which the L2TP packets are likely to travel have a 4057 consistent value. 4059 The default for any L2TP implementation is that UDP checksums MUST be 4060 enabled for both control and payload messages. An L2TP 4061 implementation MAY provide an option to disable UDP checksums for 4062 payload packets. It is recommended that UDP checksums always be 4063 enabled on control packets. 4065 Port 1701 is used for both L2F [2] and L2TP packets. The two types 4066 of packets may be detected by their headers; L2TP has a Vers field of 4067 2, L2F has a Vers field of 1. An L2TP implementation running on a 4068 system which does not support L2F MUST silently discard all packets 4069 whose Vers field is set to 1. 4071 To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP media 4072 has the characteristics of being able to reorder or silently drop 4073 packets. The former may break non-IP protocols being carried by PPP, 4074 especially LAN-centric ones such as bridging. The latter may break 4075 protocols which assume per-packet indication of error, such as TCP 4076 header compression. The former may be handled by using L2TP payload 4077 sequence numbers if any PPP protocol is used which cannot tolerate 4078 reordering. 4080 The latter characteristic of silently dropping packets is perhaps 4081 more problematic. If RFC 1663 reliable delivery [10] is enabled, no 4082 upper PPP protocol will encounter lost packets. If L2TP sequence 4083 numbers are enabled, L2TP can detect the packet loss. In the case of 4084 an LNS, the PPP and L2TP stacks are both present within the LNS, and 4085 packet loss signaling may occur precisely as if a packet was received 4086 with a CRC error. Where the LAC and PPP stack are co-resident, this 4087 technique also applies. Where the LAC and PPP client are physically 4088 distinct, the analogous signaling MAY be accomplished by sending a 4089 packet with a CRC error to the PPP client. Note that this would 4090 greatly increase the complexity of debugging client line problems, 4091 since the client statistics can not distinguish between true media 4092 errors and LAC-initiated ones. This technique is also not possible 4093 on all hardware. 4095 If neither RFC 1663 nor sequence numbers are enabled, each lost 4096 packet results in a 1 in 2**16 chance of a TCP segment being 4097 forwarded with incorrect contents [11]. Where the combination of the 4098 packet loss rate with this statistical exposure is unacceptable, TCP 4099 header compression SHOULD NOT be used in this configuration. 4101 In general, it is wise to remember that the L2TP/UDP/IP transport is 4102 an unreliable transport. As with any PPP media which is subject to 4103 loss, care should be taken when using protocols which are 4104 particularly sensitive this. Such protocols might include stateful 4105 compression or encryption protocols. 4107 8.2 IP 4109 When operating in IP environments, L2TP MUST offer the UDP 4110 encapsulation described in 8.1 as its default configuration for IP 4111 operation. Other configurations (perhaps corresponding to a 4112 compressed header format) may be defined, and made available as a 4113 configurable option. 4115 9.0 Security Considerations 4117 L2TP encounters several security issues in its operation. The 4118 general approach of L2TP to these issues is documented here. 4120 9.1 Tunnel Endpoint Security 4122 The tunnel endpoints may authenticate each other during tunnel 4123 establishment. This authentication has the same security 4124 attributes as CHAP, and has reasonable protection against replay 4125 and snooping during the tunnel establishment process. This 4126 mechanism is not designed to provide any authentication beyond 4127 tunnel establishment; it is fairly simple for a malicious user who 4128 can snoop and inject packets to hijack a tunnel once an 4129 authenticated tunnel establishment has been completed 4130 successfully. In environments where some L2TP peers will be 4131 authenticated, but others not, a mechanism should be provided to 4132 control when tunnel endpoint authentication will be active. 4134 The LAC and LNS MUST share a single secret for authentication of 4135 both ends of the tunnel. Each side uses this same secret when 4136 acting as authenticatee as well as authenticator. Since a single 4137 secret it used, the tunnel authentication AVPs include 4138 differentiating values in the CHAP ID fields for each message 4139 digest calculation to guard against replay attacks. 4141 For L2TP tunnels over IP, IPSEC [17] provides very strong 4142 protection of the tunnel. This requires no modification to the 4143 L2TP protocol, and leverages extensive IETF work in this area. 4145 For L2TP tunnels over Frame Relay or other switched networks, 4146 current practice indicates that these media are much less likely 4147 to experience attacks of in-transit data. If these attacks become 4148 prevalent, either the media or the L2TP packets would have to be 4149 encrypted or authenticated. 4151 Because the shared secret used for endpoint authentication is the 4152 same shared secret used to obscure AVP contents using the H 4153 (Hidden) bit, tunnel authentication must be used in all cases 4154 where the H bit will be used. Proxy authentication involving PAP 4155 may be usable without the H bit if PAP is only carrying one-time 4156 passwords; if clear text passwords are carried in the proxy 4157 authentication, the H bit (and, by implication, tunnel 4158 authentication) should be used. 4160 To protect against exhaustive attack during tunnel authentication, 4161 no tunnel authentication response should ever be accepted if it 4162 corresponds to a challenge more than one minute old. 4164 9.2 Client Security 4166 A more systematic method of protection in tunneled PPP 4167 environments may be achieved through client security. PPP layer 4168 encryption would provide end-to-end security for both direct 4169 dial-in clients as well as PPP clients carried within a tunnel. 4170 With this level of client security, sessions are protected against 4171 attacks against the carrying tunnel, as well as attacks on the LAC 4172 itself. Because both encryption and compression can occur at the 4173 PPP layer, the two can be coordinated, permitting compression to 4174 precede encryption. 4176 9.3 Proxy Authentication 4178 The optional proxy CHAP function of L2TP can permit an entirely 4179 transparent PPP tunnel, with a single LCP and CHAP sequence being 4180 seen by the client. For cases where the LAC and the entire path 4181 to the LNS are operated by a single entity, this function may 4182 provide acceptable security. For cases where LNS-initiated 4183 authentication is required, proxy CHAP still permits an initial 4184 access decision to be made before accepting the tunnel, permitting 4185 the LNS in most cases to reject tunnel initiations rather than 4186 accept them and later disconnect. 4188 The optional proxy PAP may result in the cleartext password 4189 traversing the tunnel. Where PAP is being used in conjunction 4190 with static passwords, this may pose a significant security issue. 4191 Where PAP is only used to transport one-time passwords, such 4192 issues may be greatly mitigated. The H bit of the carrying AVP 4193 may be used to protect against this. 4195 All implementations MUST accept proxy authentication AVP's, but 4196 are free to silently discard them and initiate an entirely new 4197 authentication with the PPP client. 4199 10.0 IANA Considerations 4201 This document contains many "magic" numbers to be maintained by the 4202 IANA. This section explains the criteria to be used by the IANA to 4203 assign additional numbers in each of these lists. Numbers may only 4204 be assigned if an appropriate IETF approved document exists that 4205 describes how the number is to be used in an interoperable fashion. 4206 All values not explicitly defined in previous sections are reserved 4207 to IANA. 4209 10.1 AVP Attribute Type Values 4211 The Attribute type values are 16 bit values. These values define 4212 the type and the usage of the data in the AVP. 4214 10.2 Message type values 4216 The Message type values are 16 bit values, used in the Message 4217 Type AVP to define the function of the control message. 4219 10.3 Result code values 4221 The Result code values are 16 bit values that define possible 4222 error conditions. 4224 10.4 Framing Capabilities & Bearer Capabilitities 4226 Framing Capabilities and Bearer Capabilitities are both 32 bit 4227 bitmasks. These bits should only be assigned to IETF Standards 4228 Track documents. 4230 10.5 Proxy Authen Type values 4232 The Proxy Authen Type values are 16 bit values that define the 4233 type of PPP authentication that is being sent as a proxy in the 4234 session. 4236 10.6 AVP Header bits 4238 There are four remaining reserved bits in the AVP header. These 4239 should only be assigned if absolutely necessary, and only to IETF 4240 Standards Track documents. 4242 10.7 Message (Payload and Control) Header bits 4244 The are seven remaining reserved bits in the message header. While 4245 the message and payload headers are distinguishable via the T-bit, 4246 they share the same bit field space. Thus, assigning a bit for the 4247 control or payload header reserves the same bit position in both 4248 headers. 4250 11.0 Acknowledgments 4252 The AVP construct comes from Glen Zorn, who thought up the framework 4253 for permitting multiple vendors to contribute to a common attribute 4254 space in a relatively orderly fashion. 4256 Dory Leifer of Ascend Communications made valuable refinements to the 4257 protocol definition of L2TP and contributed to the editing of this 4258 document. 4260 Steve Cobb and Evan Caves redesigned the state machine tables. 4262 Barney Wolff provided a great deal of design input on the endpoint 4263 authentication mechanism. 4265 12.0 Contacts 4267 Kory Hamzeh, Allan Rubens 4268 Ascend Communications 4269 1275 Harbor Bay Parkway 4270 Alameda, CA 94502 4271 kory@ascend.com 4272 acr@del.com 4274 Tim Kolar, Morgan Littlewood, Andrew J. Valencia 4275 Cisco Systems 4276 170 West Tasman Drive 4277 San Jose CA 95134-1706 4278 tkolar@cisco.com 4279 littlewo@cisco.com 4280 vandys@cisco.com 4281 W. Mark Townsley 4282 Cisco Systems 4283 7025 Kit Creek Road 4284 PO Box 14987 4285 Research Triangle Park, NC 27709 4286 townsley@cisco.com 4288 Gurdeep Singh Pall 4289 Microsoft Corporation 4290 Redmond, WA 4291 gurdeep@microsoft.com 4293 Bill Palter 4294 Network Alchemy, Inc 4295 1521.5 Pacific Ave 4296 Santa Cruz, CA 95060 4297 palter@zev.net 4299 Jeff Taarud 4300 Copper Mountain Networks, Inc. 4301 3931 Sorrento Valley Blvd. 4302 San Diego, CA 92121 4303 jtaarud@coppermountain.com 4305 William Verthein 4306 3COM Corporation 4307 william_verthein@3com.com 4309 13.0 References 4311 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 4312 07/21/1994 4314 [2] A. Valencia, M. Littlewood, T. Kolar, "Cisco Layer Two Forwarding 4315 (Protocol) L2F", RFC 2341, May 1998 4317 [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn, 4318 "Point-to-Point Tunneling Protocol (PPTP)",``work in progress'', 4319 October 1998 4321 [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034, 4322 November 1987 4324 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 4325 USC/Information Sciences Institute, October 1994. 4327 [6] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. 4328 Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, 4329 L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. 4330 Recommendations on Queue Management and Congestion Avoidance in 4331 the Internet. RFC 2309 April 1998. 4333 [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, 4334 October 1996 4336 [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens, "Remote 4337 Authentication Dial In User Service (RADIUS)." RFC 2058, 4338 January 1997. 4340 [9] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, RFC 1990, 4341 "The PPP Multilink Protocol (MP)", August 1996. 4343 [10] D. Rand, "PPP Reliable Transmission", RFC 1663, July, 1994 4345 [11] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links", 4346 RFC 1144, February, 1990 4348 [12] "SMI Network Management Private Enterprise Codes", 4349 ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers 4351 [13] G. Zorn, D. Leifer, A. Rubens, J. Shriver, "RADIUS Attributes for 4352 Tunnel Protocol Support," draft-ietf-radius-tunnel-auth-04.txt, 4353 November 1997 4355 [14] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, 07/1994 4357 [15] Bradner, S, "Key words for use in RFCs to Indicate Requirement 4358 Levels", RFC 2119, March 1997. 4360 [16] ITU-T Recommendation "Digital subscriber Signaling System No. 1 4361 (DSS 1) - ISDN user-network interface layer 3 specification for 4362 basic call control", Rec. Q.931(I.451), March 1993. 4364 [17] S. Kent, R. Atkinson, "Security Architecture for the Internet 4365 Protocol", ``work in progress'' draft-ietf-ipsec-arch-sec-04.txt, 4366 March 1998. 4368 [18] H. Alvestrand, "IETF Policy on Character Sets and Languages", 4369 RFC 2277, January 1998. 4371 Appendix A: Acknowledgment Timeouts 4373 L2TP uses sliding windows and timeouts to provide session and control 4374 flow-control across the underlying medium (which may be an 4375 internetwork) and to perform efficient data buffering to keep the 4376 LAC-LNS data channels full without causing receive buffer overflow. 4377 L2TP requires that a timeout be used to recover from dropped data or 4378 acknowledgment packets for both control and data messages. The only 4379 real difference between the flow-control mechanism used for the two 4380 message types is that control messages are retransmitted upon 4381 expiration of the acknowledgment timeout in order to assure reliable 4382 transport while payload messages are never retransmitted. Because 4383 payload messages are not retransmitted, the action taken upon 4384 expiration of the acknowledgment timeout for each message type also 4385 differs. 4387 When the timeout for a control session expires the previously 4388 transmitted control message with Ns value equal to the highest in- 4389 sequence value of Nr received from the peer is retransmitted. The 4390 receiving peer does not advance its value for the receive sequence 4391 number state, Sr, for either a control session or payload session 4392 until it receives a message with Ns equal to its current value of Sr 4393 (except for the simple receiver described in Appendix C and payload 4394 packets with the R bit set). This rule assures that all subsequent 4395 acknowledgments for this session will contain an Nr value equal to 4396 the Ns value of the first missing message until a message with the 4397 missing Ns value is received. This rule also assures that when a 4398 payload message is lost anywhere within the current transmit window, 4399 the payload session acknowledgment timeout will expire, allowing the 4400 transmitter to adjust transmission parameters such as those suggested 4401 in this appendix. 4403 According to the above rule for updating of the receiving peer's Sr 4404 value, the loss of a transmitted payload message (due to non- 4405 retransmission of payload messages) will cause Sr to remain at the 4406 value of the first lost payload message. In order to cause the 4407 receiving peer to advance its value of Sr beyond that of a lost 4408 message's Ns value, upon expiration of a payload session 4409 acknowledgment timeout, the sending peer MUST transmit a payload 4410 message with R bit set and Ns value greater than or equal to Ns of 4411 the lost message. Refer to Section 4 for more details on the use of 4412 the R bit. 4414 The exact implementation of the acknowledgment timeout is vendor- 4415 specific. It is suggested that an adaptive timeout be implemented 4416 with backoff for flow control. The timeout mechanism proposed here 4417 has the following properties: 4419 Independent timeouts for each session. A device (LAC or LNS) will 4420 have to maintain and calculate timeouts for every active session. 4422 An administrator-adjustable maximum timeout, MaxTimeOut, unique to 4423 each device. 4425 An adaptive timeout mechanism that compensates for changing 4426 throughput. To reduce packet processing overhead, vendors may 4427 choose not to recompute the adaptive timeout for every received 4428 acknowledgment. The result of this overhead reduction is that the 4429 timeout will not respond as quickly to rapid network changes. 4431 Timer backoff on timeout to reduce congestion. The backed-off 4432 timer value is limited by the configurable maximum timeout value. 4433 Timer backoff is done every time an acknowledgment timeout occurs. 4435 In general, this mechanism has the desirable behavior of quickly 4436 backing off upon a timeout and of slowly decreasing the timeout value 4437 as packets are delivered without timeouts. 4439 Some definitions: 4441 Packet Processing Delay, "PPD", is the amount of time required for 4442 each peer to process the maximum amount of data buffered in its 4443 offered receive packet window. The PPD is the value exchanged 4444 between the LAC and LNS when a call is established. For the LNS, 4445 this number should be small. For an LAC supporting modem 4446 connections, this number could be significant. 4448 "Sample" is the actual amount of time incurred receiving an 4449 acknowledgment for a packet. The Sample is measured, not 4450 calculated. 4452 Round-Trip Time, "RTT", is the estimated round-trip time for an 4453 Acknowledgment to be received for a given transmitted packet. 4454 When the network link is a local network, this delay will be 4455 minimal (if not zero). When the network link is the Internet, 4456 this delay could be substantial and vary widely. RTT is adaptive: 4457 it will adjust to include the PPD and whatever shifting network 4458 delays contribute to the time between a packet being transmitted 4459 and receiving its acknowledgment. 4461 Adaptive Timeout, "ATO", is the time that must elapse before an 4462 acknowledgment is considered lost. After a timeout, the sliding 4463 window is partially closed and the ATO is backed off. 4465 Packet Processing Delay (PPD) 4467 The PPD parameter is a 16-bit time value exchanged during the Call 4468 Control phase expressed in units of tenths of a second (64 means 6.4 4469 seconds). The protocol only specifies that the parameter is 4470 exchanged, it does not specify how it is calculated. The way values 4471 for ATO are calculated is implementation-dependent and need not be 4472 variable (static timeouts are allowed). If adaptive timeouts are to 4473 be used then the PPD should be exchanged in the call connect 4474 sequences. A possible way to calculate the PPD is: 4476 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 4477 + LACFudge (for an LAC) 4478 or 4479 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4480 + LNSFudge (for an LNS) 4482 Header is the total size of the L2TP and media dependent headers. 4483 MTU is the overall MTU for the link between the LAC and LNS. 4484 WindowSize represents the number of packets in the sliding window, 4485 and is implementation-dependent. The latency of the underlying 4486 connection path between the LAC and LNS could be used to pick a 4487 window size sufficient to keep the current session's pipe full. The 4488 constant 8 converts octets to bits (assuming ConnectRate is in bits 4489 per second). LACFudge and LNSFudge are not required but can be used 4490 to take overall processing overhead of the LAC or LNS into account. 4492 In the case of the computed PPD for an LNS, AvePathRate is the 4493 average bit rate of the path between the LNS and LAC. Given that 4494 this number is probably very large and WindowSize is relatively 4495 small, LNSFudge will be the dominant factor in the computation of 4496 PPD. It is recommended that the minimum value of PPD be on the order 4497 of 0.5 second. 4499 The value of PPD is used to seed the adaptive algorithm with the 4500 initial RTT[n-1] value. 4502 A.1 Calculating Adaptive Acknowledgment Timeout 4504 We still must decide how much time to allow for acknowledgments to 4505 return. If the timeout is set too high, we may wait an unnecessarily 4506 long time for dropped packets. If the timeout is too short, we may 4507 time out just before the acknowledgment arrives. The acknowledgment 4508 timeout should also be reasonable and responsive to changing network 4509 conditions. 4511 The suggested adaptive algorithm detailed below is based on the TCP 4512 1989 implementation and is explained in Richard Steven's book TCP/IP 4513 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 4514 calculation, and 'n-1' refers to values from the last calculation. 4516 DIFF[n] = SAMPLE[n] - RTT[n-1] 4517 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 4518 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 4519 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 4521 DIFF represents the error between the last estimated round-trip 4522 time and the measured time. DIFF is calculated on each iteration. 4524 DEV is the estimated mean deviation. This approximates the 4525 standard deviation. DEV is calculated on each iteration and 4526 stored for use in the next iteration. Initially, it is set to 0. 4528 RTT is the estimated round-trip time of an average packet. RTT is 4529 calculated on each iteration and stored for use in the next 4530 iteration. Initially, it is set to PPD. 4532 ATO is the adaptive timeout for the next transmitted packet. ATO 4533 is calculated on each iteration. Its value is limited, by the MIN 4534 function, to be a maximum of the configured MaxTimeOut value. 4536 Alpha is the gain for the round trip estimate error and is 4537 typically 1/8 (0.125). 4539 Beta is the gain for the deviation and is typically 1/4 (0.250). 4541 Chi is the gain for the timeout and is typically set to 4. 4543 To eliminate division operations for fractional gain elements, the 4544 entire set of equations can be scaled. With the suggested gain 4545 constants, they should be scaled by 8 to eliminate all division. To 4546 simplify calculations, all gain values are kept to powers of two so 4547 that shift operations can be used in place of multiplication or 4548 division. The above calculations are carried out each time an 4549 acknowledgment is received for a packet that was not retransmitted 4550 (no timeout occurs). 4552 A.2 Flow Control: Adjusting for Timeout 4554 This section describes how the calculation of ATO is modified in the 4555 case where a timeout does occur. When a timeout occurs, the timeout 4556 value should be adjusted rapidly upward. Although L2TP payload 4557 packets are not retransmitted when a timeout occurs, the timeout 4558 should be adjusted up toward a maximum limit. To compensate for 4559 shifting internetwork time delays, a strategy must be employed to 4560 increase the timeout when it expires. A simple formula called Karn's 4561 Algorithm is used in TCP implementations and may be used in 4562 implementing the backoff timers for the LNS or the LAC. Notice that 4563 in addition to increasing the timeout, we also shrink the size of the 4564 window as described in the next section. 4566 Karn's timer backoff algorithm, as used in TCP, is: 4568 NewTIMEOUT = delta * TIMEOUT 4570 Adapted to our timeout calculations, for an interval in which a 4571 timeout occurs, the new timeout interval ATO is calculated as: 4573 RTT[n] = delta * RTT[n-1] 4574 DEV[n] = DEV[n-1] 4575 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 4577 In this modified calculation of ATO, only the two values that 4578 contribute to ATO and that are stored for the next iteration are 4579 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 4580 not carried forward and is not used in this scenario. A value of 2 4581 for Delta, the timeout gain factor for RTT, is suggested. 4583 Appendix B: Acknowledgment Timeout and Window Adjustment 4585 B.1 Initial Window Size 4587 Although each side has indicated the maximum size of its receive 4588 window, it is recommended that a slow start method be used to begin 4589 transmitting data. The initial maximum window size on the 4590 transmitter is set to half the maximum size the receiver requested, 4591 with a minimum size of one packet. The transmitter stops sending 4592 packets when the number of packets awaiting acknowledgment is equal 4593 to the current maximum window size. As the receiver successfully 4594 digests each window, the maximum window size on the transmitter is 4595 bumped up by one packet until the maximum specified by the receiver 4596 is reached. This method prevents a system from flooding an already 4597 congested network because no history has been established. 4599 When for any reason an LAC or LNS receives more data than it can 4600 queue for the tunnel, a packet must be discarded. In this case, it 4601 is recommended that a "random early discard" algorithm [6] be used 4602 rather than the obvious "drop last" algorithm. 4604 B.2 Closing the Window 4606 When a timeout does occur on a packet, the sender adjusts the size of 4607 the transmit window down to one half its maximum value when it 4608 failed. Fractions are rounded up, and the minimum window size is 4609 one. 4611 B.3 Opening the Window 4613 With every successful transmission of a window's worth of packets 4614 without a timeout, the maximum transmit window size is increased by 4615 one packet until it reaches the maximum window size that was sent by 4616 its peer when the call was connected. As stated earlier, no 4617 retransmission is done on a timeout. After a timeout, transmission 4618 resumes with the maximum transmit window starting at one half the 4619 size of the maximum transmit window when the timeout occurred (with a 4620 minimum window size of 1) and adjusting upward by one each time the 4621 current maximum transmit window is filled with packets that are all 4622 acknowledged without timeouts. 4624 B.4 Window Overflow 4626 When a receiver's window overflows with too many incoming packets, 4627 excess packets are thrown away. This situation should not arise if 4628 the sliding window procedures are being properly followed by the 4629 transmitter and receiver. It is assumed that, on the transmit side, 4630 packets are buffered for transmission and are no longer accepted from 4631 the packet source when the transmit buffer fills. 4633 Appendix C: Handling of out-of-order packets 4635 When the Sequence Number and Acknowledgment Number fields are present 4636 in payload packets, they are used to manage packet rate. In 4637 addition, they may be used to handle out-of-order arrival of packets. 4638 A simple L2TP receiver may choose to skip the test for the Ns value 4639 of a received message being equal to Sr, simply updating Sr if Ns is 4640 greater than the current value of Sr. For example, if packets 1, 2, 4641 3 arrived as 1, 3, 2, this simple implementation would silently 4642 discard packet 2 without informing the sender in any way that packet 4643 2 was discarded. Even though packet 2 is dropped by the receiver, 4644 the transmitter will perceive all transmitted packets as being 4645 received without loss by its peer. 4647 Such behavior does not affect the L2TP protocol itself, but 4648 significantly improved throughput in such environments may be 4649 attained by queuing and reordering packets when they arrive out of 4650 order. The number of packets to be queued is a function of memory 4651 resources on the L2TP implementation, but should never be more than 4652 1/4 of the total sequence number space (i.e., 16384 packets), to 4653 avoid the possibility of sequence number aliasing. 4655 It is suggested that receiving peer implementations implement the Sr 4656 state variable for payload sessions and that they update Sr only when 4657 receiving the next in-sequence Ns value or when receiving a message 4658 with the R bit set. Doing so allows a mechanism for reporting of 4659 lost payload messages to the transmitter, which is necessary for the 4660 transmitter to implement algorithms such as those suggested in 4661 Appendix A and B. 4663 Note that while payload messages received out-of-order may either be 4664 queued, discarded, or delivered out-of-order, queuing is preferred. 4665 PPP does not expect to receive packets out-of-order so, if queuing is 4666 not provided by a receiver, it is preferable for it to discard out- 4667 of-order packets rather than deliver them to PPP. 4669 Appendix D: Transport Layer Adaptive Timeouts and Window Adjustment 4671 Appendixes A, B, and C deal primarily with operation of the payload 4672 packet sessions of L2TP. This Appendix explains how these three 4673 algorithms pertain to the transport layer for L2TP control sessions. 4674 Appendix B, Time-out Window Management, directly applies to the 4675 Transport Layer except in the case where a window size of 1 is being 4676 used. Appendix C, does not really apply because, for the Control 4677 Session, control messages MUST always be processed by the receiver in 4678 order. Also, there are no lost control packets because they are 4679 retransmitted by the L2TP Transport Layer. Thus, the main topic of 4680 this Appendix is how to adapt the example adaptive timeout algorithm 4681 of Appendix A to the Control Session Transport Layer. 4683 There are two main differences between the Control Session and 4684 payload sessions: 1) Unlike lost payload packets, lost control 4685 messages are retransmitted and 2) There is no Packet Processing Delay 4686 value provided in the control session setup messages. The latter 4687 affects the manner in which the initial value of the RTT estimate is 4688 determined. The former really doesn't affect the algorithm at all, 4689 except that upon a timeout, retransmission of unacknowledged control 4690 messages should be attempted, up to the number that fit in the 4691 sliding window with size computed as in Appendix B. 4693 Using the symbol definitions of Appendix A, the calculation of the 4694 value for the PPD of the remote peer can be estimated as: 4696 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4697 + Fudge 4699 This is simply the number of bits in a full control session window 4700 divided by the average speed of the path between the LAC and LNS with 4701 a fudge factor added on to make it work. In cases where the average 4702 rate of the connection between LAC and LNS isn't known, it is 4703 suggested that some value be configured that is associated with each 4704 possible peer. Because Control Session windows will most likely be 4705 small and the connection speed will be quite high, fudge will be the 4706 dominant factor in this calculation. For this reason, just 4707 configuring a single fixed initial PPD estimate to be used for all 4708 possible peers will probably provide adequate results. This fudge 4709 factor should be at least 0.5 second. 4711 Appendix E: Examples of L2TP sequence numbering 4713 Although sequence numbers serve distinct purposes for control and 4714 data messages, both types of messages use identical techniques for 4715 assigning sequence numbers. This appendix shows several common 4716 scenarios, and illustrates how sequence number state progresses and 4717 is interpreted. 4719 E.1: Lock-step tunnel establishment 4721 In this example, an LAC establishes a tunnel, with the exchange 4722 involving each side alternating in sending messages. This example 4723 is contrived, in that the final acknowledgment in the example is 4724 explicitly sent within a zero-length message, although most 4725 typically the acknowledgment would have been included in the 4726 processing of the Incoming-Call-Request which had prompted the LAC 4727 to initiate the tunnel in the first place. 4729 LAC LNS 4730 -> Start-Control-Connection-Request 4731 Nr: 0, Ns: 0 4733 Start-Control-Connection-Reply <- 4734 Nr: 1, Ns: 0 4736 -> Start-Control-Connection-Connected 4737 Nr: 1, Ns: 1 4739 (delay) 4741 (zero-length) <- 4742 Nr: 2, Ns: 1 4744 E.2: Multiple packets acknowledged 4746 This example shows a flow of payload packets from the LNS to the 4747 LAC, with the LAC having no traffic of its own. The LAC is 4748 waiting 1/4 of its timeout interval, and then acknowledging all 4749 packets seen since the last interval. 4751 (previous packet flow precedes this) 4753 LAC LNS 4754 -> (zero-length) 4755 Nr: 7000, Ns: 1000 4756 (payload) <- 4757 Nr: 1000, Ns: 7000 4758 (payload) <- 4759 Nr: 1000, Ns: 7001 4760 (payload) <- 4761 Nr: 1000, Ns: 7002 4763 (LAC's timer indicates it should acknowledge pending traffic) 4765 -> (zero-length) 4766 Nr: 7003, Ns: 1000 4768 E.3: Lost packet with retransmission 4770 An existing tunnel has a new session requested by the LAC. The 4771 Incoming-Call-Reply is lost and must be retransmitted by the LNS. 4772 This example continues from the sequence state reached at the end 4773 of example E.1. Note that loss of the -Reply has two impacts: not 4774 only does it keep the upper level state machine from progressing, 4775 but it also keeps the LAC from seeing a timely lower level 4776 acknowledgment of its -Request packet. 4778 LAC LNS 4779 -> Incoming-Call-Request 4780 Nr: 1, Ns: 2 4782 (packet lost) Incoming-Call-Reply <- 4783 Nr: 3, Ns: 1 4785 (pause; LAC's timer started first, so fires first) 4787 -> Incoming-Call-Request 4788 Nr: 1, Ns: 2 4790 (LNS realizes it has already seen this packet) 4791 (LNS might use this as a cue to retransmit, as in this example) 4793 Incoming-Call-Reply <- 4794 Nr: 3, Ns: 1 4795 -> Incoming-Call-Connected 4796 Nr: 2, Ns: 3 4798 (delay) 4800 (zero-length) <- 4801 Nr: 4, Ns: 2 4803 E.4: Lost payload packet with ZLB flow control 4805 In this example, a packet sent from Peer A to Peer B is lost. Peer 4806 B's receive window is 4, so after Peer A realizes that it has 4807 filled Peer B's window, it waits. After timing out, Peer A sends a 4808 ZLB with the R bit set to reset Peer B, telling it to give up on 4809 3001. If performing window adjustment, Peer A should now reduce 4810 its effective transmit window size until a full window is digested 4811 by Peer B. 4813 Peer A Peer B (RW=4) 4814 -> Payload Packet 4815 Nr: 7000, Ns: 3000 4816 Payload Packet <- 4817 Nr: 3001, Ns: 7000 4819 -> Payload packet (packet lost) 4820 Nr: 7001, Ns: 3001 4822 Payload Packet <- 4823 Nr: 3001, Ns: 7001 4825 -> Payload packet 4826 Nr: 7002, Ns: 3002 4827 -> Payload packet 4828 Nr: 7002, Ns: 3003 4829 -> Payload packet 4830 Nr: 7002, Ns: 3004 4832 (window full, waiting) 4834 -> Timeout, send ZLB w/R bit set 4835 Nr: 7002 Ns: 3005 4837 Payload Packet <- 4838 Nr: 3005 Ns: 7002 4840 Note that the ZLB sent with the R bit set could have been any 4841 value greater than that of the lost packet, 3001, and the current 4842 Ss value plus one. Thus, a ZLB with the R bit set to 3002, 3003 or 4843 3004 instead of 3005 would have had effectively the same result 4844 given that peer B received and queued the out of order packets. 4846 E.5: Lost payload packet with piggyback flow control 4848 In this example, two packets sent from Peer A to Peer B are lost. 4849 Peer B's receive window is 4, so after Peer A realizes that it has 4850 filled Peer B's window, it waits. After timing out, Peer A sends a 4851 payload packet with the R bit set to reset Peer B, telling it to 4852 give up on 3001 and 3002. If performing window adjustment, Peer A 4853 should now reduce its effective transmit window size until a full 4854 window is digested by Peer B. Note that in this scenario Peer A 4855 has no way of knowing that more than one packet was lost. 4857 Peer A Peer B (RW=4) 4858 -> Payload Packet 4859 Nr: 7000, Ns: 3000 4861 Payload Packet <- 4862 Nr: 3001, Ns: 7000 4864 -> Payload packet (packet lost) 4865 Nr: 7001, Ns: 3001 4866 -> Payload packet (packet lost) 4867 Nr: 7001, Ns: 3002 4869 Payload Packet <- 4870 Nr: 3001, Ns: 7001 4872 -> Payload packet 4873 Nr: 7002, Ns: 3003 4874 -> Payload packet 4875 Nr: 7002, Ns: 3004 4877 (window full, waiting) 4879 -> Timeout, send Payload w/R bit set 4880 Nr: 7002 Ns: 3005 4882 Payload Packet <- 4883 Nr: 3006 Ns: 7002 4885 Appendix F: Flow Control and Sequencing Negotiation 4887 This section provides a table of when sequence numbers are expected 4888 and when flow control is enabled on data packets. Note that this does 4889 not consider the case of dynamic disabling/enabling of sequencing by 4890 the LNS (see section 4.2). 4892 "Peer A" and "Peer B" columns contain the value of the Receive Window 4893 (RW) sent by the corresponding peer (e.g. if RW=0 appears in the 4894 "Peer A" column, then Peer A sent a RW of 0 to peer B). "RW>0" refers 4895 to all possible Receive Window values greater than 0, "no RW" means 4896 that the Receive Window AVP was not present in the message sent. 4898 Peer A Peer B Action 4900 no RW no RW Sequence numbers are absent, no flow control 4902 RW=0 RW=0 Sequence numbers are present, no flow control 4903 RW=0 no RW Sequence numbers are present, no flow control 4904 no RW RW=0 Sequence numbers are present, no flow control 4906 RW>0 RW=0 Sequence numbers are present, Peer B flow controls 4907 RW>0 no RW packets sent to Peer A 4909 RW=0 RW>0 Sequence numbers are present, Peer A flow controls 4910 no RW RW>0 packets sent to Peer B 4912 RW>0 RW>0 Sequence numbers are present, Peer A and B flow 4913 packets to respective Peer