idnits 2.17.1 draft-ietf-pppext-l2tp-03.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-24) 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 78 longer pages, the longest (page 71) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 79 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 62 instances of too long lines in the document, the longest one being 10 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 153: '... o MUST, SHALL, or MANDATORY --...' RFC 2119 keyword, line 156: '... o SHOULD or RECOMMEND -- This ...' RFC 2119 keyword, line 159: '... o MAY or OPTIONAL -- This item...' RFC 2119 keyword, line 598: '...e of 0 is thus special and MUST NOT be...' RFC 2119 keyword, line 645: '... implementations MUST implement flow c...' (108 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2677 has weird spacing: '...message encod...' == Line 3603 has weird spacing: '...or data est...' == Line 3610 has weird spacing: '...Request dis...' == 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: 'H' on line 334 -- Looks like a reference, but probably isn't: 'R' on line 336 -- Looks like a reference, but probably isn't: 'U' on line 337 -- Looks like a reference, but probably isn't: 'L' on line 335 -- Looks like a reference, but probably isn't: 'N' on line 338 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1340 (ref. '5') (Obsoleted by RFC 1700) -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-02) exists of draft-grant-tacacs-00 -- Possible downref: Normative reference to a draft: ref. '7' -- Unexpected draft version: The latest known version of draft-ietf-radius-radius is -04, but you're referring to -05. Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group Kory Hamzeh 2 INTERNET DRAFT Ascend Communications 3 Category: Internet Draft Tim Kolar 4 Title: draft-ietf-pppext-l2tp-03.txt Cisco Systems 5 Date: March 1997 Morgan Littlewood 6 Cisco Systems 7 Gurdeep Singh Pall 8 Microsoft Corporation 9 Jeff Taarud 10 Copper Mountain Networks 11 Andrew J. Valencia 12 Cisco Systems 13 William Verthein 14 U.S. Robotics 16 Layer Two Tunneling Protocol "L2TP" 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months. Internet-Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet- 28 Drafts as reference material or to cite them other than as a 29 ``working draft'' or ``work in progress.'' 31 To learn the current status of any Internet-Draft, please check the 32 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 33 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 34 munnari.oz.au. 36 Abstract 38 Virtual dial-up allows many separate and autonomous protocol domains 39 to share common access infrastructure including modems, Access 40 Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up 41 via PPP [1]. This document describes the Layer Two Tunneling 42 Protocol (L2TP) which permits the tunneling of the link layer (i.e., 43 HDLC, async HDLC) of PPP. Using such tunnels, it is possible to 44 divorce the location of the initial dial-up server from the location 45 at which the dial-up protocol connection is terminated and access to 46 the network provided. 48 Table of Contents 50 1.0 Introduction 51 1.1 Conventions 52 1.2 Terminology 53 2.0 Problem Space Overview 54 2.1 Initial Assumptions 55 2.2 Topology 56 2.3 Providing Virtual Dial-up Services--a walk-through 57 3.0 Service Model Issues 58 3.1 Security 59 3.2 Address Allocation 60 3.3 Authentication 61 3.4 Accounting 62 4.0 Protocol Overview 63 4.1 Control Message Overview 64 4.2 Payload Packet Overview 65 5.0 Message Format and Protocol Extensibility 66 5.1 AVP 67 5.2 Control Message Format 68 5.3 Payload Message Format 69 5.4 Control Message Types 70 5.5 AVP Summary 71 5.6 Result and Error Code Summary 72 5.7 Hiding of AVP values 73 6.0 Control Connection Protocol Specification 74 6.1 Start-Control-Connection-Request 75 6.2 Start-Control-Connection-Reply 76 6.3 Start-Control-Connection-Connected 77 6.4 Stop-Control-Connection-Request 78 6.5 Stop-Control-Connection-Reply 79 6.6 Hello 80 6.7 Outgoing-Call-Request 81 6.8 Outgoing-Call-Reply 82 6.9 Outgoing-Call-Connected 83 6.10 Incoming-Call-Request 84 6.11 Incoming-Call-Reply 85 6.12 Incoming-Call-Connected 86 6.13 Call-Clear-Request 87 6.14 Call-Disconnect-Notify 88 6.15 WAN-Error-Notify 89 6.16 Set-Link-Info 90 7.0 Control Connection State Machines 91 7.1 Control Connection Protocol Operation 92 7.2 Control Connection States 93 7.2.1 Control Connection Originator 94 7.2.2 Control connection Receiver 95 7.3 Timing considerations 96 7.4 Incoming Calls 97 7.4.1 LAC Incoming Call States 98 7.4.2 LNS Incoming Call States 99 7.5 Outgoing calls 100 7.5.1 LAC Outgoing Call States 101 7.5.2 LNS Outgoing Call States 102 8.0 L2TP Over Specific Media 103 8.1 IP/UDP 104 8.2 IP 105 9.0 Security Considerations 106 9.1 Tunnel Endpoint Security 107 9.2 Client Security 108 10.0 Acknowledgments 109 11.0 Contacts 110 12.0 References 111 Appendix A: Acknowledgment Time-Outs 112 Appendix B: Acknowledgment Time-Out and Window Adjustment 113 Appendix C: Handling of out-of-order packets 114 Appendix D: Transport Layer Adaptive Time-Outs and Window Adjustment 116 1.0 Introduction 118 The traditional dial-up network service on the Internet is for 119 registered IP addresses only. A new class of virtual dial-up 120 application which allows multiple protocols and unregistered IP 121 addresses is also desired on the Internet. Examples of this class of 122 network application are support for privately addressed IP, IPX, and 123 AppleTalk dial-up via PPP across existing Internet infrastructure. 125 The support of these multiprotocol virtual dial-up applications is of 126 significant benefit to end users, enterprises, and Internet Service 127 providers as it allows the sharing of very large investments in 128 access and core infrastructure and allows local calls to be used. It 129 also allows existing investments in non-IP protocol applications to 130 be supported in a secure manner while still leveraging the access 131 infrastructure of the Internet. 133 It is the purpose of this draft to identify the issues encountered in 134 integrating multiprotocol dial-up services into an existing Internet 135 Service Provider's Point of Presence (hereafter referred to as ISP 136 and POP, respectively), and to describe the L2TP protocol which 137 permits the leveraging of existing access protocols. 139 This protocol may also be used to solve the "multilink hunt-group 140 splitting" problem. Multilink PPP, often used to aggregate ISDN B 141 channels, requires that all channels composing a multilink bundle be 142 grouped at a single NAS. Because L2TP makes a PPP session appear at 143 a location other than the physical point at which the session was 144 physically received, it can be used to make all channels appear at a 145 single NAS, allowing multilink operation even when the physical calls 146 are spread across distinct physical NAS's. 148 1.1 Conventions 150 The following language conventions are used in the items of 151 specification in this document: 153 o MUST, SHALL, or MANDATORY -- This item is an absolute 154 requirement of the specification. 156 o SHOULD or RECOMMEND -- This item should generally be followed 157 for all but exceptional circumstances. 159 o MAY or OPTIONAL -- This item is truly optional and may be 160 followed or ignored according to the needs of the implementor. 162 1.2 Terminology 164 Analog Channel 166 A circuit-switched communication path which is intended to carry 167 3.1 Khz audio in each direction. 169 Digital Channel 171 A circuit-switched communication path which is intended to carry 172 digital information in each direction. 174 Call 176 A connection or attempted connection between two terminal 177 endpoints on a PSTN or ISDN--for example, a telephone call between 178 two modems. 180 CHAP 182 Challenge Authentication Protocol, a PPP cryptographic 183 challenge/response authentication protocol in which the cleartext 184 password is not passed in the clear over the line. 186 CLID 188 Calling Line ID, an indication to the receiver of a call as to the 189 phone number of the caller. 191 Control Messages 192 Control messages are exchanged between LAC, LNS pairs, and operate 193 in-band within the tunnel protocol. Control messages govern 194 aspects of the tunnel and sessions within the tunnel. 196 Dial User 198 An end-system or router attached to an on-demand PSTN or ISDN 199 which is either the initiator or recipient of a call. 201 DNIS 203 Dialed Number Information String, an indication to the receiver of 204 a call as to what phone number the caller used to reach it. 206 EAP 208 Extensible Authentication Protocol, a framework for a family of 209 PPP authentication protocols, including cleartext, 210 challenge/response, and arbitrary dialog sequences. 212 L2TP Access Concentrator (LAC) 214 A device attached to one or more PSTN or ISDN lines capable of PPP 215 operation and of handling the L2TP protocol. The LAC needs only 216 implement the media over which L2TP is to operate to pass traffic 217 to one or more LNS's. It may tunnel any protocol carried within 218 PPP. 220 L2TP Network Server (LNS) 222 An LNS operates on any platform capable of PPP termination. The 223 LNS handles the server side of the L2TP protocol. Since L2TP 224 relies only on the single media over which L2TP tunnels arrive, 225 the LNS may have only a single LAN or WAN interface, yet still be 226 able to terminate calls arriving at any LAC's full range of PPP 227 interfaces (async, synchronous ISDN, V.120, etc.). 229 Network Access Server (NAS) 231 A device providing temporary, on-demand network access to users. 232 This access is point-to-point using PSTN or ISDN lines. 234 PAP 236 Password Authentication Protocol, a simple PPP authentication 237 mechanism in which a cleartext username and password are 238 transmitted to prove identity. 240 Session 242 L2TP is connection-oriented. The LNS and LAC maintain state for 243 each user that is attached to an LAC. A session is created when 244 an end-to-end PPP connection is attempted between a dial user and 245 the LNS, or when a outbound call is initiated. The datagrams 246 related to a session are sent over the tunnel between the LAC and 247 LNS. 249 Quality of Service (QOS) 251 A given Quality of Service level is sometimes required for a given 252 user being tunneled between an LNS-LAC pair. For this scenario, a 253 unique L2TP tunnel is created (generally on top of a new SVC) and 254 encapsulated directly on top of the media providing the indicated 255 QOS. 257 Switched Virtual Circuit (SVC) 259 An L2TP-compatible media on top of which L2TP is directly 260 encapsulated. SVC's are dynamically created, permitting tunnel 261 media to be created dynamically in response to desired LNS-LAC 262 connectivity requirements. 264 Tunnel 266 A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP 267 datagrams between the LAC and the LNS; many sessions can be 268 multiplexed over a single tunnel. A control connection operating 269 in-band over the same tunnel controls the establishment, release, 270 and maintenance of sessions and of the tunnel itself. 272 2.0 Problem Space Overview 274 In this section we describe in high level terms the scope of the 275 problem that will be explored in more detail in later sections. 277 2.1 Initial Assumptions 279 We begin by assuming that Internet access is provided by an ISP and 280 that the ISP wishes to offer services other than traditional 281 registered IP address based services to dial-up users of the network. 283 We also assume that the user of such a service wants all of the 284 security facilities that are available to him in a dedicated dial-up 285 configuration. In particular, the end user requires: 287 + End System transparency: Neither the remote end system nor his 288 home site hosts should require any special software to use this 289 service in a secure manner. 291 + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or 292 through other dialogs, for instance, a textual exchange on V.120 293 before starting PPP. This will include TACACS+ [7] and RADIUS [8] 294 solutions as well as support for smart cards and one-time passwords. 295 The authentication should be manageable by the user independently of 296 the ISP. 298 + Addressing should be as manageable as dedicated dial-up solutions. 299 The address should be assigned by the home site and not the ISP. 301 + Authorization should be managed by the home site as it would in a 302 direct dial-up solution. 304 + Accounting should be performed both by the ISP (for billing 305 purposes) and by the user (for charge-back and auditing). 307 2.2 Topology 309 Shown below is a generic Internet with Public switched Telephone 310 Network (PSTN) access (i.e., async PPP via modems) and Integrated 311 Services Digital Network (ISDN) access (i.e., synchronous PPP 312 access). Remote users (either async or ISDN PPP) will access the 313 Home LAN as if they were dialed into the L2TP Network Server (LNS), 314 although their physical dial-up is via the ISP Network Access Server. 316 ...----[L]----+---[L]-----... 317 | 318 | 319 [H] 320 | 321 ________|________________________ 322 | | 323 ________|__ ______|________ 324 | | | | 325 | PSTN [R] [R] ISDN | 326 | Cloud | | Cloud [N]__[U] 327 | | Internet | | 328 | | [R] | 329 [N]______[R] |_____________| 330 | | | 331 | | | 332 [U] |________________________________| 334 [H] = LNS 335 [L] = Home LAN(s) 336 [R] = Router 337 [U] = Remote User 338 [N] = ISP Network Access Server 340 2.3 Providing Virtual dial-up Services--a walk-through 342 To motivate the following discussion, this section walks through an 343 example of what might happen when a Virtual dial-up client initiates 344 access. 346 The remote user initiates a PPP connection to an ISP via either the 347 PSTN or ISDN. The Network Access Server (NAS) accepts the connection 348 and the PPP link is established (L2TP also permits the NAS to check 349 with an LNS after call indication prior to accepting the call--this 350 is useful where DNIS or CLID information is available in the incoming 351 call notification). 353 The ISP may now undertake a partial authentication of the end 354 system/user. Only the username field would be interpreted to 355 determine whether the user requires a Virtual dial-up service. It is 356 expected--but not required--that usernames will be structured (e.g. 357 username@company.com). Alternatively, the ISP may maintain a 358 database mapping users to services. In the case of Virtual dial-up, 359 the mapping will name a specific endpoint, the LNS. 361 Alternatively, the ISP may have already determined the target LNS 362 from DNIS. If the LNS is willing to accept tunnel creation without 363 any authentication of the caller, the NAS may tunnel the PPP 364 connection without ever having communicated with the remote user. 366 If a virtual dial-up service is not required, standard access to the 367 Internet may be provided. 369 If no tunnel connection currently exists to the desired LNS, one is 370 initiated. L2TP is designed to be largely insulated from the details 371 of the media over which the tunnel is established; L2TP requires only 372 that the tunnel media provide packet oriented point-to-point 373 connectivity. Obvious examples of such media are UDP, Frame Relay 374 PVC's, or X.25 VC's. 376 Once the tunnel exists, an unused slot within the tunnel, a "Call 377 ID", is allocated, and a connect indication is sent to notify the LNS 378 of this new dial-up session. The LNS either accepts the connection, 379 or rejects it. Rejection may include a reason indication, which may 380 be displayed to the dial-up user, after which the call should be 381 disconnected. 383 The initial setup notification may include the authentication 384 information required to allow the LNS to authenticate the user and 385 decide to accept or decline the connection. In the case of CHAP, the 386 set-up packet includes the challenge, username and raw response. For 387 PAP or text dialog, it includes username and clear text password. 388 The LNS may choose to use this information to complete its 389 authentication, avoiding an additional cycle of authentication. 391 If the LAC negotiated PPP LCP before initiating the tunnel, the 392 initial setup notification may also include a copy of the LCP 393 CONFACKs sent in each direction which completed LCP negotiation. The 394 LNS may use this information to initialize its own PPP state (thus 395 avoiding an additional LCP negotiation), or it may choose to initiate 396 a new LCP CONFREQ exchange. 398 If the LNS accepts the connection, it creates a "virtual interface" 399 for PPP in a manner analogous to what it would use for a direct- 400 dialed connection. With this "virtual interface" in place, link 401 layer frames may now pass over this tunnel in both directions. 402 Frames from the remote user are received at the POP, stripped of any 403 link framing or transparency bytes, encapsulated in L2TP, and 404 forwarded over the appropriate tunnel. 406 The LNS accepts these frames, strips L2TP, and processes them as 407 normal incoming frames for the appropriate interface and protocol. 408 The "virtual interface" behaves very much like a hardware interface, 409 with the exception that the hardware in this case is physically 410 located at the ISP POP. The other direction behaves analogously, 411 with the LNS encapsulating the packet in L2TP, and the NAS stripping 412 L2TP before transmitting it out the physical interface to the remote 413 user. For the remainder of this document, a NAS operating as a peer 414 to an LNS will be referred to as an L2TP Access Concentrator, or 415 "LAC". 417 At this point, the connectivity is a point-to-point PPP session whose 418 endpoints are the remote user's networking application on one end and 419 the termination of this connectivity into the LNS's PPP support on 420 the other. Because the remote user has become simply another dial-up 421 client of the LNS, client connectivity can now be managed using 422 traditional mechanisms with respect to further authorization, 423 protocol access, and packet filtering. 425 Accounting can be performed at both the LAC as well as the LNS. This 426 document illustrates some Accounting techniques which are possible 427 using L2TP, but the policies surrounding such Accounting are outside 428 the scope of this specification. 430 L2TP offers optional facilities which maximize compatibility with 431 legacy client requirements; L2TP connect notifications for PPP 432 clients can contain sufficient information for an LNS to authenticate 433 and initialize its LCP state machine. With these facilities, the 434 remote user need not be queried a second time for PPP authentication, 435 nor undergo multiple rounds of LCP negotiation and convergence. 436 These techniques are intended to optimize connection setup, and are 437 not intended to deprecate any functions required by the PPP 438 specification. 440 3.0 Service Model Issues 442 There are several significant differences between the standard 443 Internet access service and the Virtual dial-up service with respect 444 to authentication, address allocation, authorization and accounting. 445 The details of the differences between these services and the 446 problems presented by these differences are described below. The 447 mechanisms used for Virtual Dial-up service are intended to coexist 448 with more traditional mechanisms; it is intended that an ISP's POP 449 can simultaneously service ISP clients as well as Virtual dial-up 450 clients. 452 3.1 Security 454 For the Virtual dial-up service, the ISP pursues authentication only 455 to the extent required to discover the user's apparent identity (and 456 by implication, their desired LNS). This may involve no more than 457 detecting DNIS information when a call arrives, or may involve full 458 LCP negotiation and initiation of PPP authentication. As soon as the 459 apparent identity is determined, a connection to the LNS is initiated 460 with any authentication information gathered by the ISP. The LNS 461 completes the authentication by either accepting the connection, or 462 rejecting it. 464 The LNS may need to protect against attempts by third parties to 465 establish tunnels to the LNS. Tunnel establishment can include 466 authentication to protect against such attacks. 468 3.2 Address Allocation 470 For an Internet service, the user accepts that the IP address may be 471 allocated dynamically from a pool of ISP addresses. This model often 472 means that the remote user has little or no access to their home 473 network's resources, due to firewalls and other security policies 474 applied by the home network to accesses from external IP addresses. 476 For the Virtual dial-up service, the LNS can exist behind the home 477 firewall, allocating addresses which are internal (and, in fact, can 478 be RFC1918 addresses, or non-IP addresses). Because L2TP tunnels 479 exclusively at the frame layer, the actual policies of such address 480 management are irrelevant to correct Virtual dial-up service; for all 481 purposes of PPP protocol handling, the dial-in user appears to have 482 connected at the LNS. 484 3.3 Authentication 486 The authentication of the user occurs in three phases; the first at 487 the ISP, and the second and optional third at the LNS. 489 The ISP uses DNIS, CLID, or username to determine that a Virtual 490 dial-up service is required and initiates the tunnel connection to 491 the appropriate LNS. Once a tunnel is established, The ISP NAS 492 allocates a new Call ID and initiates a session by forwarding the 493 gathered authentication information. 495 The LNS undertakes the second phase by deciding whether or not to 496 accept the connection. The connection indication may include CHAP, 497 PAP, EAP, or textual authentication information. Based on this 498 information, the LNS may accept the connection, or may reject it (for 499 instance, it was a PAP request and the username/password are found to 500 be incorrect). 502 Once the connection is accepted, the LNS is free to pursue a third 503 phase of authentication at the PPP layer. These activities are 504 outside the scope of this specification, but might include an 505 additional cycle of LCP authentication, proprietary PPP extensions, 506 or textual challenges carried via a TCP/IP telnet session. 508 3.4 Accounting 510 It is a requirement that both the LAC and the LNS be capable of 511 providing accounting data and hence both may count packets, octets 512 and connection start and stop times. 514 Since Virtual dial-up is an access service, accounting of connection 515 attempts (in particular, failed connection attempts) is of 516 significant interest. The LNS can reject new connections based on 517 the authentication information gathered by the LAC, with 518 corresponding logging. For cases where the LNS accepts the 519 connection and then continues with further authentication, the LNS 520 might subsequently disconnect the client. For such scenarios, the 521 disconnection indication back to the LAC may also include a reason. 523 Because the LNS can decline a connection based on the authentication 524 information collected by the LAC, accounting can easily draw a 525 distinction between a series of failed connection attempts and a 526 series of brief successful connections. Lacking this facility, the 527 LNS must always accept connection requests, and would need to 528 exchange a number of PPP packets with the remote system. Note that 529 the LNS could use this information to decide to accept the connection 530 (which protects against most invalid connection attempts) while still 531 insisting on running its own CHAP authentication (for instance, to 532 protect against CHAP replay attacks). 534 4.0 Protocol Overview 536 There are two parallel components of L2TP operating over a given 537 tunnel: control messages between each LAC-LNS pair, and payload 538 packets between the same LAC-LNS pair. The latter are used to 539 transport L2TP encapsulated PPP packets for user sessions between the 540 pair. 542 The Nr (Next Received) and Ns (Next Sent) fields are always present 543 in control messages, and are optionally present in payload messages. 544 Distinct sequence number state is maintained for control messages 545 related to the tunnel (Call ID is 0), and for each distinct user 546 session within the tunnel. Sequence number state is also distinct 547 for control and for payload messages within a particular session. 548 Each distinct state is initialized so the first packet is sent with 549 an Ns of 0. Nr is sent reflecting one more than the last in-order 550 received packet; if sent before any packet is received it would be 0, 551 indicating that it expects the next new Ns value received to be 0. 553 The sequence number state is maintained and updated as packets are 554 sent. A message (control or payload) with a zero-length body 555 indicates that the packet is only used to communicate Nr and Ns 556 fields. The Nr and Ns fields are filled in as above, but the 557 sequence number state remains the same. For non-zero-length body 558 messages, the sequence number state is incremented (modulo 2**16) 559 after it is copied to the packet's Ns field. 561 If a new Ns value has been received by the peer, and no packet has 562 been sent with an Nr value to indicate this reception within 1/4 of 563 the timeout interval, such a zero-length message is sent. 565 4.1 Control Message Overview 567 Before PPP tunneling can occur between an LAC and LNS, control 568 messages must be exchanged between them. Control messages are 569 exchanged over the same tunnel which will be used to forward 570 payload data once L2TP call control and management information 571 have been passed. The control messages are responsible for 572 establishment, management, and release of sessions carried through 573 the tunnel, as well as status on the tunnel itself. It is the 574 means by which an LNS is notified of an incoming call at an 575 associated LAC, as well as the means by which an LAC is instructed 576 to place an outgoing dial call. 578 A tunnel may be established by either an LAC (for incoming calls) 579 or an LNS (for outgoing calls). Following the establishment of 580 the tunnel, the LNS and LAC configure the tunnel by exchanging 581 Start-Control-Connection-Request and -Reply messages. These 582 messages are also used to exchange information about basic 583 operating capabilities of the LAC and LNS. Once the control 584 message exchange is complete, the LAC may initiate sessions by 585 indicating inbound requests, or the LNS by requesting outbound 586 calls. Control messages may indicate changes in operating 587 characteristics of an individual user session with a Set-Link-Info 588 message. Individual sessions may be released by either the LAC or 589 LNS, also through control messages. 591 Independent Call ID values are established for each end of a user 592 session. The sender of a packet associated with a particular 593 session places the Call ID established by its peer in the Call ID 594 header field of all outgoing packets. For the cases where a Call 595 ID has not yet been assigned from the peer (i.e., during call 596 establishment of a new session), the Call ID field is sent as 0, 597 and further fields within the message are used to identify the 598 session. The Call ID value of 0 is thus special and MUST NOT be 599 used as an Assigned Call ID. 601 Two mechanisms provide for detection of tunnel connectivity 602 problems, one by the reliable transport layer of L2TP and another 603 by the higher layer. The transport layer of L2TP performs control 604 message retransmission. If the number of retransmission attempts 605 for a given control message exceeds a configured maximum value, 606 the tunnel is reset. This retransmission mechanism exists in both 607 the LNS and LAC ends of the tunnel. In addition, keepalive 608 control echo messages are injected into the control stream by the 609 higher L2TP layer after a certain duration of inactivity on a 610 given tunnel is detected. A response to the sent keepalive is 611 expected within a configured time interval. If not received 612 within the allowed time interval, the tunnel is reset. These two 613 mechanisms ensure that a connectivity failure between the LNS and 614 the LAC can be detected at either end of a tunnel in a timely 615 manner. 617 It is intended that control messages will also carry management 618 related information in the future, such as a message allowing the 619 LNS to request the status of a given LAC; these message types are 620 not defined in this document. 622 4.2 Payload Packet Overview 624 Once a tunnel is established and control messages have completed 625 tunnel setup, the tunnel can be used to carry user session PPP 626 packets for sessions involving a given LNS-LAC pair. The "Call 627 ID" field in the L2TP header indicates to which session a 628 particular PPP packet belongs. In this manner, PPP packets are 629 multiplexed and demultiplexed over a single tunnel between a given 630 LNS-LAC pair. The "Call ID" field value is established during the 631 exchange of call setup control messages. 633 It is legal for multiple tunnels to exist between a given LNS-LAC 634 pair. This is useful where each tunnel is used for a single user 635 session, and the tunnel media (an SVC, for instance) has specific 636 QOS attributes dedicated to a given user. L2TP provides a tunnel 637 identifier so that individual tunnels can be identified, even when 638 arriving from a single source LAC or LNS. 640 The L2TP header also contains optional acknowledgment and 641 sequencing information that can be used to perform congestion 642 control over the tunnel. Control messages are used to determine 643 rate and buffering parameters that are used to regulate the flow 644 of PPP packets for a particular session over the tunnel. All 645 implementations MUST implement flow control, but may indicate that 646 flow control is not desired by omitting the Packet Window Size and 647 Packet Processing Delay AVP's during call setup. L2TP does not 648 specify the particular algorithms to use for congestion and flow 649 control. Suggested algorithms for the determination of adaptive 650 time-outs to recover from dropped data or acknowledgments on the 651 tunnel are included in Appendix A of this document. 653 L2TP does not include a "Receive-Not-Ready" function. It is 654 expected that the flow-control mechanism used will provide an 655 adequate "pacing" mechanism so that the sender does not overflow 656 the receiver's allotted receive window and receive buffers. It is 657 permissible for the receiving peer to withhold Acks if it is 658 unable to accept more data for a connection. Thus, unlike for the 659 Control Message session, the sending peer MUST NOT clear a session 660 (or the whole tunnel) as a result of not receiving timely 661 acknowledgments for transmitted packets. The job of detecting a 662 non-functioning tunnel lies solely with the Control Message 663 functions of L2TP. 665 5. Message Format and Protocol Extensibility 667 L2TP defines a set of control messages sent in packets over the 668 tunnel between an LNS and a given LAC. The exact technique for 669 initiating a tunnel between an LNS-LAC pair is specific to the tunnel 670 media, and specific media are described in section 8.0. 672 Once media-level connectivity is reached, L2TP message formats define 673 the protocol for an LAC and LNS to manage the tunnel and its 674 associated sessions. 676 In each case where a field is optional, if the field is not present, 677 its space does not exist in the packet. Existing fields are placed 678 back-to-back to form the packet. 680 5.1 AVP 682 To maximize extensibility while still permitting interoperability, 683 a uniform method for encoding message types and bodies is used 684 throughout L2TP. This encoding will be termed an AVP (Attribute- 685 Value Pair) in the remainder of this document. Each AVP is 686 encoded as: 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 |M|H|0|0|0|0| Overall Length | Vendor ID | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Attribute | Value... | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | [until Overall Length is reached]... | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 The first six bits are a bit mask, describing the general 699 attributes of the AVP. The M bit, known as the "mandatory" bit, 700 controls the behavior required of an implementation which receives 701 an AVP which it does not recognize. If M is set, any session 702 associated with this AVP MUST be terminated. If the AVP is 703 associated with the overall tunnel, the entire tunnel (and all 704 sessions within) MUST be terminated. If M is not set, an 705 unrecognized AVP should be ignored. 707 The H bit, known as the "hidden" bit, controls the hiding of the 708 data in the value field of an AVP. This capability can be used to 709 avoid the passing of sensitive data, such as user passwords, as 710 cleartext in an AVP. Section 5.6 describes the procedure for 711 performing AVP value hiding. 713 Overall Length encodes the number of octets (including the Overall 714 Length field itself) contained in this AVP. It is 10 bits, 715 permitting a maximum of 1024 bytes of data in a single AVP. 717 Vendor ID is the IANA assigned "SMI Network Management Private 718 Enterprise Codes" value, encoded in network byte order. The value 719 0, reserved in this table, corresponds to IETF adopted Attribute 720 values, defined within this document. Any vendor wishing to 721 implement L2TP extensions can use their own Vendor ID along with 722 private Attribute values, guaranteeing that they will not collide 723 with any other vendor's extensions, nor with future IETF 724 extensions. 726 Attribute is the actual attribute, a 16-bit value with a unique 727 interpretation across all AVP's defined under a given Vendor ID. 729 Value follows immediately after the Attribute field, and runs for 730 the remaining octets indicated in the Overall Length (i.e., 731 Overall Length minus six octets of header). 733 AVP's should be kept compact; the combined AVP's within a control 734 message MUST NOT ever cause a control message's total length to 735 exceed 1500 bytes in length. 737 5.2 Control Message Format 739 Each L2TP control message begins with a 24 octet (20 mandatory, 4 740 optional) header portion followed by zero or more AVP's. This 741 header is formatted: 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 |T|1|1|1|1|K|0| | Ver | Length | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Tunnel ID | Call ID | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Ns | Nr | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Key (opt) | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Message Type AVP... | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | ... (8 bytes) | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 The T bit MUST be 1, indicating a control message. The next four 760 bits MUST be set to 1, making the header more compatible in 761 encoding with the payload message (defined in the next section). 762 The K bit is optional, documented below. The bit following the K 763 bit MUST be 0. 765 Ver MUST be the value 002, indicating a version 1 L2TP message 766 (values 000 and 001 are reserved to permit detection of L2F [2] 767 and PPTP [3] packets if they arrive intermixed). 769 Length is the overall length of the message, including header, 770 message type AVP, plus any additional AVP's associated with a 771 given control message type. 773 Tunnel ID and Call ID identify the tunnel and user session within 774 the tunnel to which a control message applies. If a control 775 message does not apply to a single user session within the tunnel 776 (for instance, a Stop-Control-Connection-Request message), Call ID 777 MUST be set to 0. If an Assigned Tunnel ID has not yet been 778 received from the peer, Tunnel ID MUST be set to 0. 780 Nr and Ns reflect the currently transmitted packet and latest 781 received packet respectively. See section 4.0. 783 If the K bit is set, the Key field is present. The K bit MUST be 784 set if a Challenge value was received during tunnel setup, and the 785 Key reflects the challenge response of this authentication, with 786 the resulting MD5 hash value broken into successive 32-bit fields 787 which are XOR'ed together and this value put in the Key field. 789 5.3 Payload Message Format 791 PPP payload packets tunneled within L2TP have a smaller 792 encapsulation than the L2TP control message header, reducing 793 overhead of L2TP during the life of a tunneled PPP session. The 794 MTU for the user data packets encapsulated in L2TP is expected to 795 be 1500 octets, not including L2TP and media encapsulation. The 796 smallest L2TP encapsulation is 2 octets; the largest is 18 octets 797 (plus padding bytes, if present). See section 8.1 for further MTU 798 considerations. 800 0 1 2 3 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 |T|L|I|C|F|K|O| | Ver | Length (opt) | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Tunnel ID (opt) | Call ID (opt) | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Ns (opt) | Nr (opt) | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Key (opt) | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Offset Size (opt) | Offset pad... (opt) | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 The T bit MUST be 0, indicating payload. 816 Ver MUST be 002, indicating version 1 of the L2TP protocol. 818 If the L bit is set, the Length field is present, indicating the 819 total length of the received packet. 821 The I and C bits indicate the presence of Tunnel ID and Call ID, 822 respectively. The interpretation of these fields, if present, is 823 described in section 5.2. 825 If the F bit is set, both the Nr and Ns fields are present. Ns 826 indicates the sequence number of the packet being sent. The 827 current packet will be this sequence number if the payload size is 828 non-zero, otherwise this packet is only an acknowledgment 829 (sequence number does not advance). Nr indicates the next packet 830 sequence number to be received (if the last data packet had Ns set 831 to 1, the Nr sent back would be 2). Together, these fields can be 832 used to handle out-of-order packets, and to provide flow control 833 for the connection. 835 An L2TP peer setting the F bit, and placing Nr and Ns fields in 836 its messages, MUST have previously received a Receive Window Size 837 AVP from its peer during establishment of the session. 839 If the K bit is set, the Key field is present. Refer to the 840 description in 5.2. 842 The Offset Size field is present if the O bit is set in the header 843 flags. This field specifies the number of bytes past the L2TP 844 header at which the payload data is expected to start. It is 845 recommended that data thus skipped be initialized to 0's. If 846 Offset Size is 0, or the O bit is not set, the first byte 847 following the last byte of L2TP header is the first byte of 848 payload data. 850 5.4 Control Message Types 851 Control message and AVP types defined in this specification exist 852 under Vendor ID 0, indicating IETF defined behavior. The actual 853 message and AVP semantics are defined in the next section. This 854 section includes tables that summarize all currently defined 855 message and AVP types. 857 Each message type entry in the table below consists of 3 columns. 858 The "Num." column indicates the integer value assigned to this 859 message type. i The "(Abbrev)" column lists the abbreviation for 860 each message type used in the AVP table that follows. 862 The number in the "Value" column is placed in the Value field of 863 the Message Type AVP. This AVP MUST be the first AVP in a 864 message. The currently defined control message types, grouped by 865 function, are: 867 Control Connection Management 869 1 (SCCRQ) Start-Control-Connection-Request 870 2 (SCCRP) Start-Control-Connection-Reply 871 3 (SCCCN) Start-Control-Connection-Connected 872 4 (StopCCRQ) Stop-Control-Connection-Request 873 5 (StopCCRP) Stop-Control-Connection-Reply 874 6 Hello 876 Call Management 878 7 (OCRQ) Outgoing-Call-Request 879 8 (OCRP) Outgoing-Call-Reply 880 9 (OCCN) Outgoing-Call-Connected 881 10 (ICRQ) Incoming-Call-Request 882 11 (ICRP) Incoming-Call-Reply 883 12 (ICCN) Incoming-Call-Connected 884 13 (CCRQ) Call-Clear-Request 885 14 (CDN) Call-Disconnect-Notify 887 Error Reporting 889 15 (WEN) WAN-Error-Notify 891 PPP Session Control 893 16 (SLI) Set-Link-Info 895 5.5 AVP Summary 897 The following table lists all standard L2TP attributes currently 898 defined. The "Attr" column indicates the integer value assigned to 899 this attribute. The "M" column indicates the setting of the 900 "Mandatory" bit of the AVP header for each attribute. The "Len" 901 field indicates the size of the AVP including the AVP header. A 902 "+" in this column indicates that the length varies depending upon 903 the length of the actual contents of the value field. 905 Under the Name column, the parenthesized lists of message type 906 abbreviations indicate the message types that utilize each AVP 907 (See command table above). An abbreviation shown in mixed or 908 uppercase letters indicates that the corresponding AVP MUST be 909 present in this message type; All lowercase indicates that the AVP 910 may optionally appear in this message type. A "+" appended to a 911 message type abbreviation indicates that the AVP is only mandatory 912 in a "positive" (non-error) condition -- The AVP is optional in a 913 message indicating an error condition. 915 A brief summary of the type and contents of the value field for 916 each attribute is also given for each entry. Refer to the 917 individual message type descriptions that appear in Section 6 for 918 further details about the use of a particular AVP in a particular 919 message type. 921 Attr M Len Attribute Name (usage) 923 0 1 8 Message Type (ALL MESSAGES) 924 16 bit integer value indicating the message type, as defined in 925 table above. MUST be the first AVP in each message 927 1 1 10+ Result Code (CDN, ICRP, OCCN, OCRP, SCCRP, StopCCRP, 928 StopCCRQ) 929 16 bit Integer value indicating result of corresponding request 930 or reason for issuing a request, 16 bit integer General Error 931 code and an optional ASCII string error message. See Result 932 and General Error code tables below. 934 2 1 8 Protocol Version (SCCRP, SCCRQ) 935 8 bit L2TP Protocol and Revision numbers 937 3 1 10 Framing Capabilities (SCCRP, SCCRQ) 938 16 bit bitmask indicating supported framing types (e.g., 939 synchronous and asynchronous) 941 4 1 10 Bearer Capabilities (SCCRP, SCCRQ) 942 16 bit bitmask indicating supported bearer types (e.g., analog 943 and digital) 945 5 0 14 Tie Breaker (sccrq) 946 8 byte value used to break control connection establishment 947 collisions 949 6 0 8 Firmware Revision (sccrp, sccrq) 950 16 bit integer representing vendor's firmware revision 952 7 0 6+ Host Name (sccrp, sccrq) 953 ASCII string name (e.g., DNS name) of issuer 955 8 0 6+ Vendor Name (sccrp, sccrq) 956 ASCII string describing issuing device 958 9 1 8 Assigned Tunnel ID (SCCRP+, SCCRQ, StopCCRQ) 959 16 bit integer tunnel ID assigned by sender 961 10 1 8 Receive Window Size (iccn, icrp, occn, ocrq, sccrp, 962 sccrq) 963 16 bit integer receive window size offered by sender for a 964 given call or control session 966 11 1 6+ Challenge (sccrp, sccrq) 967 1 or more octet value issued by sender wishing to authenticate 968 control session peer 970 12 0 9+ Q.931 Cause Code (cdn, occn) 971 16 bit cause code, 1 octet cause message, and optional ASCII 972 advisory message 974 13 1 22 Challenge Response (scccn, sccrp) 975 16 octet CHAP type response to peer's Challenge 977 14 1 8 Assigned Call ID (CCRQ, CDN, ICRP+, ICRQ, OCRP+, OCRQ) 978 16 bit integer ID assigned to a call by sender 980 15 1 6+ Call Serial Number (ICRQ, OCRQ) 981 1 or more octet identifier assigned to a call 983 16 1 10 Minimum BPS (OCRQ) 984 16 bit integer indicating lowest acceptable line speed for call 986 17 1 10 Maximum BPS (OCRQ) 987 16 bit integer indicating highest acceptable line speed for 988 call 990 18 1 10 Bearer Type (ICRQ, OCRQ) 991 Indicates bearer type (i.e., analog or digital) for call 993 19 1 10 Framing Type (ICCN, OCCN+, OCRQ) 994 Indicates framing type (i.e., synchronous or asynchronous) for 995 call 997 20 1 8 Packet Processing Delay (iccn, icrp, occn, ocrq) 998 16 bit integer estimate of processing time of full window of 999 received packets by sender 1001 21 1 6+ Dialed Number (icrq, OCRQ) 1002 ASCII string phone number called or to be called 1004 22 1 6+ Dialing Number (icrq) 1005 ASCII string phone number of caller 1007 23 1 6+ Sub-Address (icrq, ocrq) 1008 ASCII string containing additional dialing information 1010 24 1 10 Connect Speed (ICCN, OCCN+, OCRP+) 1011 16 bit integer actual line speed of connection 1013 25 1 10 Physical Channel ID (icrq, ocrp) 1014 16 bit vendor specific physical device identifier used for call 1016 26 0 6+ Initial LCP Conf (iccn) 1017 Octet string containing initial CONFREQ received from client 1019 27 0 6+ Last Sent LCP Conf (iccn) 1020 Octet string containing final CONFREQ sent to client 1022 28 0 6+ Last Received LCP Conf (iccn) 1023 Octet string containing final CONFREQ received from client 1025 29 1 8 Proxy Authen Type (ICCN) 1026 16 bit integer code indicating client authentication type 1027 negotiated (e.g., PAP, CHAP) 1029 30 0 6+ Proxy Authen Name (iccn) 1030 ASCII string containing name returned by client in 1031 authentication response 1033 31 0 6+ Proxy Authen Challenge (iccn) 1034 Octet string Challenge presented by LAC to client 1036 32 0 8 Proxy Authen ID (iccn) 1037 16 bit integer of which low order octet is ID presented to 1038 client with Challenge. High order octet must be 0. 1040 33 1 6+ Proxy Authen Response (iccn) 1041 Octet string CHAP response or ASCII string password depending 1042 on authentication type used 1044 34 1 32 Call Errors (WEN) 1045 A reserved 16 bit word set to 0 followed by 6 32 bit integer 1046 connection error counters 1048 35 1 16 ACCM (SLI) 1049 A reserved 16 bit word set to 0 followed by 2 32 bit bitmasks 1050 containing Send and Receive ACCM values respectively 1052 36 1 6+ Random Vector (all messages) 1053 Variable length octet string containing a random sequence of 1054 values used to accomplish the optional "hiding" of other AVP 1055 values (See "H" bit description) 1057 5.6 Result and Error Code Summary 1059 In general, all Reply Message types contain a Result Code AVP which 1060 indicates the result of the requested operation. The Result Code can 1061 indicate that additional information pertaining to an error situation 1062 can be found in the Error Code field of the Result Code AVP. The 1063 meaning of the result code is tabulated under the specific type of 1064 message containing the result. Each 16-bit Result Code is 1065 immediately followed (in the same AVP) by a 16-bit General Error code 1066 value. 1068 General error codes pertain to types of errors which are not specific 1069 to any particular L2TP request, but rather to protocol or message 1070 format errors. If an L2TP reply indicates in its Result Code that a 1071 general error occurred, the General Error value should be examined to 1072 determine what the error was. The currently defined General Error 1073 codes and their meanings are: 1075 0 - No general error 1076 1 - No control connection exists yet for this LAC-LNS pair 1077 2 - Length is wrong 1078 3 - One of the field values was out of range or reserved field was 1079 non-zero 1080 4 - Insufficient resources to handle this operation now 1081 5 - The Call ID is invalid in this context 1082 6 - A generic vendor-specific error occurred in the LAC 1083 7 - Try another. If LAC is aware of other possible LNS 1084 destinations, it should try one of them. This can be used to 1085 guide an LAC based on LNS policy, for instance, the existence 1086 of multilink PPP bundles. 1088 If the length of the Result Code AVP specifies that the Value field 1089 is more than four octets in length, the remaining bytes after the 1090 General Error Code field are an arbitrary string providing further 1091 (possibly human readable) text associated with the condition. 1093 Generally, when a General Error Code of 6 is used, additional 1094 information about the error will be included in the Result Code AVP 1095 in the Optional Message field that follows the Error Code field. 1097 5.7 Hiding of AVP values 1099 The "Hidden" bit in the header of each AVP in a control message 1100 provides a mechanism to indicate to the receiving peer whether the 1101 contents of the AVP are hidden or present in cleartext. This feature 1102 can be used to hide sensitive control message data such as user 1103 passwords or user ID's. L2TP allows for the value of any AVP - except 1104 the Random Vector AVP itself - to be hidden. 1106 The H bit MUST only be set if tunnel authentication was used and, 1107 therefore, a shared secret exists between the peers on either end of 1108 the tunnel. If the H bit is set in any AVP(s) in a given command 1109 message, a Random Vector AVP must also be present in the message and 1110 MUST preceed the first AVP having an H-bit of 1. 1112 The following mechanism is applied to the contents of the value field 1113 of each AVP to which hiding is to be applied. An MD5 hash is 1114 performed on the concatenation of: 1116 - the 2 octet Attribute number of the AVP 1117 - the shared authentication secret 1118 - and an arbitrary length random vector 1120 The value of the random vector used in this hash is passed in the 1121 value field of a Random Vector AVP. This Random Vector AVP must be 1122 placed in the message by the sender before any hidden AVPs. The same 1123 random vector can be used for more than one hidden AVP in the same 1124 message. If a different random vector is used for the hiding of 1125 subsequent AVPs then a new Random Vector AVP must be placed in the 1126 command message before the first AVP to which it applies. 1128 After the MD5 hash value is computed, any variable length values to 1129 be hidden are padded at the end with nulls to a multiple of 16 octets 1130 in order to hide the length of the string too. The MD5 hash value is 1131 then XORed with the first 16 octet or less segment of the value and 1132 placed in the Value field of the AVP. 1134 If the value is longer than 16 octets, a second one-way MD5 hash is 1135 calculated over a stream of octets consisting of the shared secret 1136 followed by the result of the first XOR. That hash is XORed with the 1137 second 16 octet or less segment of the value and placed in the 1138 corresponding octets of the Value field of the AVP. 1140 If necessary, this operation is repeated, with each XOR result being 1141 used along with the shared secret to generate the next hash to XOR 1142 the next segment of the value with. 1144 On receipt, the random vector is taken from the last Random Vector 1145 AVP encountered in the message prior to the AVP to be unhidden. The 1146 above process is then reversed to yield the original value. For more 1147 details on this hiding method, consult the RADIUS [8] RFC. 1149 The Random Vector AVP has the following format: 1151 Random Vector 1153 0 1 2 3 1154 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 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 |1|0|0|0| 6 + String length | 0 | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | 36 | Random Octet String ... 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 The Random Vector AVP may be used in any message type. The Attribute 1162 value is 36 and it is marked mandatory. It is used to enable the 1163 hiding of the values of arbitrary AVPs. It MUST preceed any AVP 1164 containing an AVP with the H-bit set but it MUST NOT itself have the 1165 H-bit set. More than one Random Vector AVP may appear in a message, 1166 in which case the one most closely preceeding an AVP with the H-bit 1167 set pertains to that AVP. The Random Octet String is the random 1168 vector value to use in computing the MD5 hash to retrieve the 1169 original value of a hidden AVP. This string can be of arbitrary 1170 length, although a random vector of at least 16 octets is 1171 recommended. 1173 6.0 Control Connection Protocol Specification 1175 Control Connection messages are used to establish and clear user 1176 sessions. The first set of Control Connection messages are used to 1177 maintain the control connection itself. The control connection is 1178 initiated by an LAC or LNS after establishing the underlying tunnel- 1179 over-media connection. 1181 6.0.1 Control Connection Collision 1183 For the case where an LAC and LNS both initiate tunnels to each 1184 other concurrently, and where the LAC and LNS both determine that 1185 a single tunnel suffices (generally because of media 1186 characteristic considerations, for instance, whether individual 1187 tunnels are needed to gain QOS guarantees for each tunnel), a "tie 1188 breaker" may be undertaken. The details of breaking a tie are 1189 documented with the tunnel establishment messages. 1191 6.0.2 Reliable Delivery of Control Messages 1193 Since L2TP may run across media where packets may be lost, an L2TP 1194 peer sending a control message will retransmit the control message 1195 after deciding that its remote peer has not received it. The 1196 reliable transport mechanism built into L2TP is essentially a 1197 lower layer transport service; the Nr and Ns fields of the control 1198 message header belong to this transport layer. The higher layer 1199 functions of L2TP are not concerned with retransmission or 1200 ordering of control messages. 1202 Each tunnel maintains a queue of control messages to be 1203 transmitted to the peer. The message at the front of the queue is 1204 sent with a given Ns value, and is held until a control message 1205 arrives from the peer in which the Nr field indicates receipt of 1206 this message. After a fixed (recommended default is 1 second) or 1207 adaptive (see Appendix D) timeout interval expires without 1208 receiving such an acknowledgment, the control message packet is 1209 retransmitted. The retransmitted packet contains the same Ns 1210 value, but the Nr value MUST be updated to reflect any packets 1211 received in the interim. 1213 If no peer response is detected after several retransmissions (a 1214 recommended default is 5, but may be altered due to media 1215 considerations), the tunnel and all sessions within MUST be 1216 cleared. 1218 When a tunnel is being shut down for reasons other than loss of 1219 connectivity, the state and reliable delivery mechanisms MUST be 1220 maintained and operated for the full retransmission interval after 1221 the final message exchange has occurred. This permits reliable 1222 delivery of closing messages in environments where these closing 1223 messages might be dropped. 1225 Unlike payload traffic, a peer MUST NOT withhold acknowledgment of 1226 packets as a technique for flow controlling control messages. An 1227 L2TP implementation is expected to be able to keep up with 1228 incoming control messages, possible responding to some with errors 1229 reflecting an inability to honor the requested action. 1231 A sliding window mechanism is used, by default, for control 1232 message transmission. The default is to permit four control 1233 message to be outstanding on a given tunnel. If a peer specifies 1234 a control message window in the Start-Control-Connection-Request 1235 and -Reply packets, up to the indicated number of control messages 1236 may be sent and held outstanding. An implementation may only 1237 support a receive window of 1, but MUST accept at least a window 1238 of 4 from its peer. 1240 The transport layer at a receiving peer is responsible for making 1241 sure that control messages are delivered in order to the higher 1242 layer and that duplicate messages are not delivered to the higher 1243 layer. Messages arriving out of order may be queued for in-order 1244 delivery when the missing messages are received or they may be 1245 discarded, requiring a retransmission. 1247 6.0.3 Control Message Format 1249 The following Control Connection messages are all sent as packets 1250 on the established tunnel connection between a given LNS-LAC pair. 1251 All data is sent in network order (high order octets first). Any 1252 "reserved" or "empty" fields MUST be sent as 0 values to allow for 1253 protocol extensibility. 1255 Each control message has a header, specified in section 5.2, 1256 including an AVP indicating the type of control message, followed 1257 by zero or more AVP's appropriate for the given type of control 1258 message. Each control message is described first at a block 1259 level, and then with details of each AVP. 1261 6.1 Start-Control-Connection-Request 1263 The Start-Control-Connection-Request is an L2TP control message used 1264 to initialize the tunnel between an LNS and an LAC. The tunnel must 1265 be initialized through the exchange of these control messages before 1266 any other L2TP messages can be issued. The establishment of the 1267 control connection is started by the initiator of the underlying 1268 tunnel. 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | L2TP Control Message Header | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Start-Control-Connection-Request | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Protocol Version | 1276 | Framing Capabilities | 1277 | Bearer Capabilities | 1278 | Tie Breaker | 1279 | Firmware Revision | 1280 | Host Name | 1281 | Vendor Name | 1282 | Assigned Tunnel ID | 1283 | Receive Window Size | 1284 | Challenge | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+ 1287 Start-Control-Connection-Request 1289 0 1 2 3 1290 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 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 |1|0|0|0| 8 | 0 | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | 0 | 1 | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 The Message Type AVP contains a Value of 1, indicating Start- 1298 Control-Connection-Request. The Flags indicate a mandatory 1299 option. Details associated with this tunneled session follow in 1300 additional AVP's within the packet. 1302 Protocol Version 1304 0 1 2 3 1305 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 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 |1|0|0|0| 8 | 0 | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | 2 | 0x01 | 0x00 | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 The Protocol Version AVP within a Start-Control-Connection-Request 1313 packet indicates the L2TP protocol version available. The 1314 Attribute value is 2, indicating Protocol Version, and is marked 1315 mandatory. This AVP MUST be present. The Value field is a 16-bit 1316 hexadecimal value 0x100, indicating L2TP protocol version 1, 1317 revision 0. 1319 Framing Capabilities 1321 0 1 2 3 1322 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 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 |1|0|0|0| 10 | 0 | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | 3 | 0x00 | 0x00 | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | 0x00 |0|0|0|0|0|0|S|A| 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 The Framing Capabilities AVP within a Start-Control-Connection- 1332 Request indicates the type of framing that the sender of this 1333 message can provide. The Attribute value is 3, indicating Framing 1334 Capabilities, and is marked mandatory. This AVP MUST be present. 1335 The Value field is a 32-bit quantity, with two bits defined. If 1336 bit A is set, asynchronous framing is supported. If bit S is set, 1337 synchronous framing is supported. 1339 Bearer Capabilities 1341 0 1 2 3 1342 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 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 |1|0|0|0| 10 | 0 | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | 4 | 0x00 | 0x00 | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | 0x00 |0|0|0|0|0|0|D|A| 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 The Bearer Capabilities AVP within a Start-Control-Connection- 1352 Request indicates the bearer capabilities that the sender of this 1353 message can provide. The Attribute value is 4, indicating Bearer 1354 Capabilities, and is marked mandatory. This AVP MUST be present. 1355 The Value field is a 32-bit quantity with two bits defined. If 1356 bit A is set, analog access is supported. If bit D is set, 1357 digital access is supported. 1359 Tie Breaker 1361 0 1 2 3 1362 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 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 |0|0|0|0| 14 | 0 | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | 5 | Tie Break Value... | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Value... | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | ...(64 bits) | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 The Tie Breaker AVP within a Start-Control-Connection-Request 1374 contains a 64-bit Value used to break ties in tunnel establishment 1375 between an LAC-LNS pair. The Attribute value is 5, indicating Tie 1376 Breaker, and is marked optional. This AVP itself is optional. 1377 The 8 byte Value is used as a 64-bit tie breaker value. 1379 If present, it indicates the sender wishes a single tunnel to 1380 exist between the given LAC-LNS pair, and this value will be used 1381 to choose a single tunnel where both LAC and LNS initiate a tunnel 1382 concurrently. The recipient of a Start-Control-Connection-Request 1383 must check to see if a Start-Control-Connection-Request has been 1384 sent to the peer, and if so, must compare its Tie Breaker value 1385 with the received one. The lower value "wins", and the "loser" 1386 MUST initiate a tunnel disconnect for their outstanding tunnel. 1387 In the case where a tie breaker is present on both sides, and the 1388 value is equal, both sides MUST initiate tunnel disconnects. 1390 If a tie breaker is received, and the outstanding Start-Control- 1391 Connection-Request had no tie breaker value, the initiator which 1392 included the Tie Breaker AVP "wins". 1394 It is recommended that the Value be set to the MAC address of a 1395 LAN interface on the sender. If no MAC address is available, a 1396 64-bit random number should be used instead. 1398 Firmware Revision 1400 0 1 2 3 1401 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 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 |0|0|0|0| 8 | 0 | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | 6 | Firmware Revision | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 The Firmware Revision AVP within a Start-Control-Connection- 1409 Request indicates the firmware revision of the issuing device. 1410 The Attribute value is 6, indicating Firmware Revision, and is 1411 marked optional. This AVP itself is optional. The Value field is 1412 a 16-bit integer encoded in a vendor specific format. For devices 1413 which do not have a firmware revision (general purpose computers 1414 running L2TP software modules, for instance), the revision of the 1415 L2TP software module may be reported instead. 1417 Host Name 1419 0 1 2 3 1420 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 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 |0|0|0|0| 6 + Host name length | 0 | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | 7 | Host name... 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 The Host Name AVP within a Start-Control-Connection-Request 1428 indicates the name of the issuing LAC or LNS. The Attribute value 1429 is 7, indicating Host Name, and is marked optional. This AVP 1430 itself is optional. This name should be as broadly unique as 1431 possible; for hosts participating in DNS [4], a hostname with 1432 fully qualified domain would be appropriate. 1434 Vendor Name 1436 0 1 2 3 1437 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 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 |0|0|0|0|6 + vendor name length | 0 | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | 8 | Vendor name... 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 The Vendor Name AVP within a Start-Control-Connection-Request 1445 contains a vendor specific string describing the type of LAC or 1446 LNS being used. The Attribute value is 8, indicating Vendor Name, 1447 and is marked optional. This AVP itself is optional. The Value 1448 is the indicated number of bytes representing the vendor string. 1450 Assigned Tunnel ID 1452 0 1 2 3 1453 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 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 |1|0|0|0| 8 | 0 | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | 9 | Tunnel ID | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 The Assigned Tunnel ID AVP within a Start-Control-Connection- 1461 Request specifies the Tunnel ID which the receiving peer MUST use 1462 in the Tunnel ID field of all subsequent packets. The Attribute 1463 value is 9, indicating Assigned Tunnel ID, and is marked 1464 mandatory. This AVP MUST be present. Before the Assigned Tunnel 1465 ID AVP is received, packets MUST be sent with a Tunnel ID value of 1466 0. The Value is a 16-bit non-zero Tunnel ID value. 1468 Receive Window Size 1470 0 1 2 3 1471 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 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 |1|0|0|0| 8 | 0 | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | 10 | Size | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 The Receive Window Size AVP within a Start-Control-Connection- 1479 Request specifies the receive window size being offered to the 1480 remote peer. The Attribute value is 10, indicating Receive Window 1481 Size, and is mandatory. This AVP itself is optional. Value is a 1482 16-bit word indicating the offered window size. If absent, the 1483 peer must assume a value of 4 for its transmit window. The remote 1484 peer may send the specified number of control messages before it 1485 must wait for an acknowledgment. 1487 Challenge 1489 0 1 2 3 1490 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 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 |1|0|0|0| 6 + Challenge length | 0 | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | 11 | Challenge... 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 The Challenge AVP within a Start-Control-Connection-Request 1498 indicates that the issuing peer wishes to authenticate the tunnel 1499 endpoints. The Attribute value is 11, indicating Challenge, and 1500 is marked mandatory. This AVP is optional. The Value is one or 1501 more octets of challenge value. 1503 6.2 Start-Control-Connection-Reply 1505 The Start-Control-Connection-Reply is an L2TP control message sent in 1506 reply to a received Start-Control-Connection-Request message. This 1507 message contains a result code indicating the result of the control 1508 connection establishment attempt. 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | L2TP Control Message Header | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Start-Control-Connection-Reply | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Protocol Version | 1516 | Result Code | 1517 | Framing Capabilities | 1518 | Bearer Capabilities | 1519 | Firmware Revision | 1520 | Host Name | 1521 | Vendor Name | 1522 | Assigned Tunnel ID | 1523 | Receive Window Size | 1524 | Challenge | 1525 | Challenge Response | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+ 1528 Start-Control-Connection-Reply 1530 0 1 2 3 1531 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 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 |1|0|0|0| 8 | 0 | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | 0 | 2 | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 The Message Type AVP contains a Value of 2, indicating Start- 1539 Control-Connection-Reply. The Flags indicate a mandatory option. 1541 Protocol Version 1543 0 1 2 3 1544 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 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 |1|0|0|0| 8 | 0 | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | 2 | 0x01 | 0x00 | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 The Protocol Version AVP within a Start-Control-Connection-Reply 1552 packet indicates the L2TP protocol version available. The 1553 Attribute value is 2, indicating Protocol Version, and the Value 1554 field is a 16-bit hexadecimal value 0x100, indicating L2TP 1555 protocol version 1, revision 0. This AVP MUST be present. 1557 Framing Capabilities 1559 0 1 2 3 1560 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 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 |1|0|0|0| 10 | 0 | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | 3 | 0x00 | 0x00 | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | 0x00 |0|0|0|0|0|0|S|A| 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 The Framing Capabilities AVP within a Start-Control-Connection- 1570 Reply indicates the type of framing that the sender of this 1571 message can provide. The Attribute is 3, it is a mandatory AVP, 1572 the Value field is a 32-bit quantity, with two bits defined. If 1573 bit A is set, asynchronous framing is supported. If bit S is set, 1574 synchronous framing is supported. This AVP MUST be present. 1576 Bearer Capabilities 1578 0 1 2 3 1579 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 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 |1|0|0|0| 10 | 0 | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 | 4 | 0x00 | 0x00 | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | 0x00 |0|0|0|0|0|0|D|A| 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 The Bearer Capabilities AVP within a Start-Control-Connection- 1589 Reply indicates the bearer capabilities that the sender of this 1590 message can provide. The Attribute is 4, it is a mandatory AVP, 1591 the Value field is a 32-bit quantity with two bits defined. If 1592 bit A is set, analog access is supported. If bit D is set, 1593 digital access is supported. This AVP MUST be present. 1595 Firmware Revision 1597 0 1 2 3 1598 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 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 |0|0|0|0| 8 | 0 | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | 6 | Firmware Revision | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 The Firmware Revision AVP within a Start-Control-Connection-Reply 1606 indicates the firmware revision of the issuing device. The 1607 Attribute is 6, it is not a mandatory AVP, the Value field is a 1608 16-bit integer encoded in a vendor specific format. For devices 1609 which do not have a firmware revision (general purposes computers 1610 running L2TP software modules, for instance), the revision of the 1611 L2TP software module may be reported instead. This AVP is 1612 optional. 1614 Host Name 1616 0 1 2 3 1617 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 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 |0|0|0|0| 6 + Host name length | 0 | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | 7 | Host name... 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 The Host Name AVP within a Start-Control-Connection-Reply 1625 indicates the name of the issuing LAC or LNS. See the notes in 1626 section 6.1 concerning Host Name contents. It is encoded as the 1627 Attribute 7, not mandatory, with the indicated number of bytes 1628 representing the host name string. This AVP is optional. 1630 Vendor Name 1632 0 1 2 3 1633 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 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 |0|0|0|0|6 + Vendor name length | 0 | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | 8 |Vendor name... 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 The Vendor Name AVP within a Start-Control-Connection-Reply 1641 contains a vendor specific string describing the type of LAC or 1642 LNS being used. It is encoded as the Attribute 8, not mandatory, 1643 with the indicated number of bytes representing the vendor string. 1644 This AVP is optional. 1646 Assigned Tunnel ID 1648 0 1 2 3 1649 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 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 |1|0|0|0| 8 | 0 | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | 9 | Tunnel ID | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply 1657 specifies the Tunnel ID which the receiving peer MUST use in all 1658 subsequent packets. It is encoded as the Attribute 9, mandatory, 1659 with a 16-bit non-zero Tunnel ID value. This AVP MUST be present 1660 if the Result Code indicates "Successful channel establishment". 1662 Receive Window Size 1664 0 1 2 3 1665 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 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 |1|0|0|0| 8 | 0 | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | 10 | size | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 The Receive Window Size AVP within a Start-Control-Connection- 1673 Reply specifies the receive window size being offered to the 1674 remote peer. The Attribute value is 10, indicating Receive Window 1675 Size, and is mandatory. This AVP itself is optional. Value is a 1676 16-bit word indicating the offered window size. If absent, the 1677 peer must assume a value of 4 for its transmit window. The remote 1678 peer may send the specified number of control messages before it 1679 must wait for an acknowledgment. 1681 Result Code 1683 0 1 2 3 1684 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 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 |1|0|0|0| 10 + Message length | 0 | 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | 1 | Result Code | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | Error Code | Optional Message ... 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 The Result Code AVP within a Start-Control-Connection-Reply packet 1694 indicates the result of the control channel establishment attempt. 1695 It is encoded as Attribute 1, indicating a Result Code AVP. This 1696 AVP is mandatory and MUST be present. The Result Code is a 16-bit 1697 word. The 16-bit word following the Result Code field contains 1698 the Error Code value. The Result Code value indicates whether the 1699 Error Code value is meaningful or not. If it is not meaningful it 1700 MUST be set to a value of 0. An optional error message can follow 1701 the Error Code field. Its presence and length is indicated by the 1702 value of the AVP length field. 1704 Result code values are: 1705 1 - Successful channel establishment 1706 2 - General error--Error Code indicates the problem 1707 3 - Control channel already exists 1708 4 - Requester is not authorized to establish a control channel 1709 5 - The protocol version of the requester is not supported 1711 Challenge 1713 0 1 2 3 1714 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 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 |1|0|0|0| 6 + Challenge length | 0 | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | 11 | Challenge... 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 The Challenge AVP within a Start-Control-Connection-Reply 1723 indicates that the peer wishes to authenticate the tunnel 1724 initiator. It is encoded as the Attribute 11, mandatory, with at 1725 least one byte of challenge value embedded. If this AVP is not 1726 present, it indicates to the receiving peer that the sender does 1727 not wish to authenticate that peer. 1729 Challenge Response 1731 0 1 2 3 1732 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 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 |1|0|0|0| 22 | 0 | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | 13 | Response... | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | Response... (128 bits) | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 The Response AVP within a Start-Control-Connection-Reply packet 1742 provides a response to a challenge received. The Attribute value 1743 is 13, indicating Response, and the Value field is a 128-bit value 1744 reflecting the CHAP-style response to the challenge. This AVP 1745 marked mandatory, and MUST be present if a challenge was received 1746 and this Start-Control-Connection-Reply indicates success. For 1747 purposes of the ID value in the CHAP response calculation, the low 1748 order byte of the Sequence number of the challenge is used. 1750 6.3 Start-Control-Connection-Connected 1752 The Start-Control-Connection-Connected message is an L2TP control 1753 message sent in reply to a received Start-Control-Connection-Reply 1754 message. This message provides closure to the tunnel establishment 1755 process, and includes a challenge response if the peer sent a 1756 challenge in the Start-Control-Connection-Reply message. 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 | L2TP Control Message Header | 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 | Start-Control-Connection-Connected | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 | Challenge Response | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+ 1766 Start-Control-Connection-Connected 1768 0 1 2 3 1769 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 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 |1|0|0|0| 8 | 0 | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | 0 | 3 | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 The Message Type AVP contains a Value of 17, indicating Start- 1777 Control-Connection-Connected. The Flags indicate a mandatory 1778 option. 1780 Challenge Response 1782 0 1 2 3 1783 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 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 |1|0|0|0| 22 | 0 | 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 | 13 | Response... | 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | Response... (128 bits) | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 The Challenge Response AVP within a Start-Control-Connection- 1793 Connected packet provides a response to a challenge received. The 1794 Attribute value is 13, indicating Response, and the Value field is 1795 a 128-bit value reflecting the CHAP-style response to the 1796 challenge. This AVP is marked mandatory, and MUST be present if a 1797 challenge was received, otherwise MUST be omitted. For purposes 1798 of the ID value in the CHAP response calculation, the low order 1799 byte of the Sequence number of the challenge are used. 1801 6.4 Stop-Control-Connection-Request 1803 The Stop-Control-Connection-Request is an L2TP control message sent 1804 by one peer of an LAC-LNS control connection to inform the other peer 1805 that the control connection should be closed. In addition to closing 1806 the control connection, all active user calls are implicitly cleared. 1807 The reason for issuing this request is indicated in the Reason field. 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | L2TP Control Message Header | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | Stop-Control-Connection-Request | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Assigned Tunnel ID | 1815 | Result Code | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+ 1818 Stop-Control-Connection-Request AVP 1820 0 1 2 3 1821 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 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 |1|0|0|0| 8 | 0 | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | 0 | 4 | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 The Message Type AVP contains a Value of 3, indicating Stop- 1828 Control-Connection-Request. The Flags indicate a mandatory 1829 option. 1831 Assigned Tunnel ID 1833 0 1 2 3 1834 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 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 |1|0|0|0| 8 | 0 | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | 9 | Tunnel ID | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 The Attribute value is 9, indicating Assigned Tunnel ID, and is 1842 marked mandatory. This AVP MUST be present. The Value MUST be 1843 the same Assigned Tunnel ID first sent to the receiving peer. 1844 This AVP permits the peer to identify the appropriate tunnel even 1845 if Stop-Control-Connection-Request must be sent before an Assigned 1846 Tunnel ID is received. 1848 Result Code 1850 0 1 2 3 1851 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 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 |1|0|0|0| 10 + Message length | 0 | 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | 1 | Result Code | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Error Code | Optional Message ... 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 The Result Code AVP within a Stop-Control-Connection-Request 1861 packet indicates the reason for terminating the control channel. 1862 It is encoded as Attribute 1, indicating a Result Code AVP. This 1863 AVP is mandatory and MUST be present. The Result Code is a 16-bit 1864 word. The 16-bit word following the Result Code field contains 1865 the Error Code value, which for a Stop-Control-Connection-Request 1866 is always 0. An optional message can follow the Error Code field. 1867 Its presence and length is indicated by the value of the AVP 1868 length field. Defined Result Code values are: 1870 1 - General request to clear control connection 1871 2 - Can't support peer's version of the protocol 1872 3 - Requester is being shut down 1874 6.5 Stop-Control-Connection-Reply 1876 The Stop-Control-Connection-Reply is an L2TP control message sent by 1877 one peer of an LAC-LNS control connection upon receipt of a Stop- 1878 Control-Connection-Request from the other peer. 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | L2TP Control Message Header | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | Stop-Control-Connection-Reply | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | Result Code | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+ 1888 Stop-Control-Connection-Reply 1890 0 1 2 3 1891 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 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 |1|0|0|0| 8 | 0 | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | 0 | 5 | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 The Message Type AVP contains a Value of 4, indicating Stop- 1899 Control-Connection-Reply. The Flags indicate a mandatory option. 1901 Result Code 1903 0 1 2 3 1904 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 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 |1|0|0|0| 10 + Message length | 0 | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | 1 | Result Code | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | Error Code | Optional Message ... 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 The Result Code AVP within a Stop-Control-Connection-Reply packet 1914 indicates the result of the control channel close attempt. It is 1915 encoded as Attribute 1, indicating a Result Code AVP. This AVP is 1916 mandatory and MUST be present. The Result Code is a 16-bit word. 1917 The 16-bit word following the Result Code field contains the Error 1918 Code value. The Result Code value indicates whether the Error 1919 Code value is meaningful or not. If it is not meaningful it 1920 should be set to a value of 0. An optional error message can 1921 follow the Error Code field. Defined Values are: 1923 1 - Control connection closed 1924 2 - Control connection not closed for reason indicated in Error Code 1926 6.6 Hello 1928 The Hello message is an L2TP control message sent by either peer of a 1929 LAC-LNS control connection. This control message is used as a 1930 "keepalive" for the control connection. 1932 Keepalives should be implemented by sending a Hello once every 60 1933 seconds if 60 seconds have passed without sending a message to the 1934 peer. When a Hello is received, it MUST be silently discarded (after 1935 updating any effects of the indicated Nr/Ns values). 1937 Because a Hello is a control message, and control messages are 1938 reliably sent by the lower level transport, this keepalive function 1939 operates by causing the transport level to reliably deliver a 1940 message. If a media interruption has occurred, the reliable 1941 transport will be unable to deliver the Hello across, and will clean 1942 up the tunnel. 1944 Hello messages are global to the tunnel; the Call ID field of these 1945 control messages MUST be 0. 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | L2TP Control Message Header | 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 | Hello | 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 Hello 1955 0 1 2 3 1956 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 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 |1|0|0|0| 8 | 0 | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | 0 | 6 | 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 The Message Type AVP contains a Value of 5, indicating Hello The 1964 Flags indicate a mandatory option. 1966 6.7 Outgoing-Call-Request 1968 The Outgoing-Call-Request is an L2TP control message sent by the LNS 1969 to the LAC to indicate that an outbound call from the LNS is to be 1970 established. This request provides the LAC with information required 1971 to make the call. It also provides information to the LAC that is 1972 used to regulate the transmission of data to the LNS for this session 1973 once it is established. 1975 This message is the first in the "three-way handshake" used by L2TP 1976 for establishing outgoing calls. The first message requests the 1977 call; the second indicates that the call was successfully initiated. 1978 The third and final message indicates that the call was established. 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | L2TP Control Message Header | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | Outgoing-Call-Request | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | Assigned Call ID | 1986 | Call Serial Number | 1987 | Minimum BPS | 1988 | Maximum BPS | 1989 | Bearer Type | 1990 | Framing Type | 1991 | Receive Window Size | 1992 | Packet Processing Delay | 1993 | Dialed Number | 1994 | Sub-Address | 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 Outgoing-Call-Request 1999 0 1 2 3 2000 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 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 |1|0|0|0| 8 | 0 | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 | 0 | 7 | 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 The Message Type AVP contains a Value of 7, indicating Outgoing- 2008 Call-Request. The Outgoing-Call-Request encodes a request to an 2009 LAC to establish an outgoing call. The flags indicate a mandatory 2010 option. 2012 Assigned Call ID 2014 0 1 2 3 2015 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 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 |1|0|0|0| 8 | 0 | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | 14 | Call ID | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 The Assigned Call ID AVP encodes the ID being assigned to this 2023 call by the LNS. The Attribute value is 14, indicating Assigned 2024 Call ID, and is marked mandatory. This AVP MUST be present. The 2025 LAC places this value in the Call ID header field of all command 2026 and payload packets that it subsequently transmits over the tunnel 2027 that belong to this call. The Call ID value is an identifier 2028 assigned by the LNS to this session. It is used to multiplex and 2029 demultiplex data sent over that tunnel between the LNS and LAC. 2031 Call Serial Number 2033 0 1 2 3 2034 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 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 |1|0|0|0| 6 + Number length | 0 | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | 15 | Number... 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 Call Serial Number AVP encodes an identifier assigned by the LNS to 2042 this call. 2044 Attribute is 15, indicating Call Serial Number, and is marked mandatory. 2045 This AVP MUST be present. 2046 The Call Serial Number is intended 2047 to be an easy reference for administrators on both ends of a tunnel to use 2048 when investigating call failure problems. Call Serial Numbers should 2049 be set to progressively increasing values, which are likely to be unique for 2050 a significant period of time across all interconnected LNS and LACs. Other 2051 identification information may also be prepended. 2053 Minimum BPS 2055 0 1 2 3 2056 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 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 |1|0|0|0| 10 | 0 | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 | 16 | BPS (H) | 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | BPS (L) | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 Minimum BPS AVP encodes the lowest acceptable line speed for this 2066 call. Attribute is 16, Minimum BPS, and is marked mandatory. 2067 This AVP MUST be present. The BPS value indicates the speed in 2068 bits/second. 2070 Maximum BPS 2072 0 1 2 3 2073 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 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 |1|0|0|0| 10 | 0 | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | 17 | BPS (H) | 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 | BPS (L) | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 Maximum BPS AVP encodes the highest acceptable line speed for this 2083 call. Attribute is 17, indicating Maximum BPS, and is marked 2084 mandatory. This AVP MUST be present. The BPS value indicates the 2085 speed in bits/second. 2087 Bearer Type 2089 0 1 2 3 2090 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 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 |1|0|0|0| 10 | 0 | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 Bearer Type AVP encodes the bearer type for the requested call. 2099 The value bit field Attribute is 18, indicating Bearer Type, and 2100 is marked mandatory. This AVP MUST be present. The Value is a 2101 32-bit quantity indicating the bearer capability required for this 2102 outgoing call. If set, bit A indicates that the call should be on 2103 an analog channel. If set, bit D indicates that the call should 2104 be on a digital channel. Both may be set, indicating that the 2105 call can be of either type. 2107 Framing Type 2109 0 1 2 3 2110 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 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 |1|0|0|0| 10 | 0 | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 Framing Type AVP encodes the framing type for the requested call. 2120 Attribute is 19, indicating Framing Type, and is marked mandatory. 2121 This AVP MUST be present. The 32-bit field indicates the type of 2122 PPP framing to be used for the outgoing call. Bit A if set 2123 indicates that asynchronous framing should be used. Bit S is set 2124 indicates that synchronous framing should be used. 2126 Receive Window Size 2128 0 1 2 3 2129 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 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 |1|0|0|0| 8 | 0 | 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 | 10 | Size | 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 Receive Window Size AVP encodes the window size being advertised 2137 by the LNS for this call. Attribute is 10, indicating Receive 2138 Window Size, and is marked mandatory. This AVP is optional. The 2139 Size value indicates the number of received data packets the LNS 2140 will buffer for this call, which is also the maximum number of 2141 data packets the LAC should send before waiting for an 2142 acknowledgment. The absence of this AVP indicates that Sequence 2143 and Acknowledgment Numbers are not to be used in the payload 2144 session for this call. 2146 Packet Processing Delay 2148 0 1 2 3 2149 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 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 |1|0|0|0| 8 | 0 | 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 | 20 | Delay | 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 The Packet Processing Delay AVP encodes the delay LNS has for 2157 processing a window full of packets sent by the LAC. Attribute is 2158 20, indicating Packet Processing Delay, and is marked mandatory. 2159 This AVP is optional. The Delay value is specified in units of 2160 1/10 seconds. Refer to Appendix A for a description of how this 2161 value is determined and used. 2163 Dialed Number 2165 0 1 2 3 2166 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 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 |1|0|0|0|6 + Phone Number length| 0 | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | 21 | Phone Number.. 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 Phone Number AVP encodes the phone number to be called. Attribute 2174 is 21, indicating Phone Number, and is marked mandatory. This AVP 2175 MUST be present. The Phone Number value is an ASCII string. 2177 Sub-Address 2179 0 1 2 3 2180 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 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 |1|0|0|0|6 + Sub-Address length | 0 | 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 | 23 |Sub-Address ... 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 Sub-Address AVP encodes additional dialing information. Attribute 2188 is 23, indicating Sub-Address, and is marked mandatory. This AVP 2189 is optional. The Sub-Address value is an ASCII string. 2191 6.8 Outgoing-Call-Reply 2193 The Outgoing-Call-Reply is an L2TP control message sent by the LAC to 2194 the LNS in response to a received Outgoing-Call-Request message. The 2195 reply indicates whether or not the LAC is able to attempt the 2196 outbound call and also returns certain parameters regarding the call 2197 attempt. 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 | L2TP Control Message Header | 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 | Outgoing-Call-Reply | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | Assigned Call ID | 2205 | Result Code | 2206 | Connect Speed | 2207 | Physical Channel Id | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 Outgoing-Call-Reply 2212 0 1 2 3 2213 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 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 |1|0|0|0| 8 | 0 | 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 | 0 | 8 | 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 The Message Type AVP contains a Value of 8, indicating Outgoing- 2221 Call-Reply. The Outgoing-Call-Reply message encodes the immediate 2222 result of attempting an outgoing call request. The flags indicate a 2223 mandatory option. 2225 Assigned Call 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| 8 | 0 | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | 14 | Call ID | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 The Assigned Call ID AVP encodes the ID being assigned to this call 2236 by the LAC. Attribute is 14, indicating Assigned Call ID, and is 2237 marked mandatory. This AVP MUST be present if the Result Code 2238 indicates a call is in progress. Call ID value is an identifier, 2239 unique within the tunnel, assigned by the sender to this session. 2240 The remote peer MUST place this Call ID in the Call ID portion of all 2241 future packets it sends associated with this session. It is used to 2242 multiplex and demultiplex data sent over that tunnel between the LNS 2243 and LAC. 2245 Result Code 2247 0 1 2 3 2248 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 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 |1|0|0|0| 10 + Message length | 0 | 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 | 1 | Result Code | 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 | Error Code | Optional Message ... 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 The Result Code AVP within an Outgoing-Call-Request indicates the 2258 result of the outgoing call establishment attempt. It is encoded 2259 as Attribute 1, indicating a Result Code AVP. This AVP is 2260 mandatory and MUST be present. The Result Code is a 16-bit word. 2261 The 16-bit word following the Result Code field contains the Error 2262 Code value. The Result Code value indicates whether the Error 2263 Code value is meaningful or not. If it is not meaningful it 2264 should be set to a value of 0. An optional error message can 2265 follow the Error Code field. Its presence and length is indicated 2266 by the value of the AVP length field. Defined Result Code values 2267 are: 2269 1 - Call attempt in progress 2270 2 - Outgoing Call not attempted for the reason indicated in Error Code 2271 3 - No appropriate facilities are available (temporary condition) 2272 4 - No appropriate facilities are available (permanent condition) 2273 5 - Invalid destination 2274 6 - Outgoing Call administratively prohibited 2276 Connect Speed 2278 0 1 2 3 2279 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 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 |1|0|0|0| 10 | 0 | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | 24 | BPS (H) | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 | BPS (L) | 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 Connect Speed BPS AVP encodes the speed for the connection. The 2289 Attribute value is 24, indicating Connect Speed, and is marked 2290 mandatory. This AVP MUST be present if the Result indicates a 2291 call is in progress. The BPS is a 32-bit value indicating the 2292 speed in bits/second. 2294 Physical Channel ID 2296 0 1 2 3 2297 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 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 |1|0|0|0| 10 | 0 | 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 | 25 | ID (H) | 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 | ID (L) | 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 Physical Channel ID AVP encodes the vendor specific physical 2307 channel number used for the call. The Attribute value is 25, 2308 indicating Physical Channel ID, and is marked optional. This AVP 2309 itself is optional. ID is a 32-bit value in network byte order. 2310 The value is used for logging purposes only. 2312 6.9 Outgoing-Call-Connected 2313 Outgoing-Call-Connected is an L2TP control message sent by the LAC to 2314 the LNS to indicate the result of a requested outgoing call. The LAC 2315 MUST send the corresponding Outgoing-Call-Reply to the LNS before 2316 sending this message. This message provides information to the LNS 2317 about the particular parameters used for the call. It provides 2318 information to allow the LNS to regulate the transmission of data to 2319 the LAC for this session. 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 | L2TP Control Message Header | 2323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2324 | Outgoing-Call-Connected | 2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 | Result Code | 2327 | Q.931 Cause Code | 2328 | Connect Speed | 2329 | Framing Type | 2330 | Receive Window Size | 2331 | Packet Processing Delay | 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 Outgoing-Call-Connected 2336 0 1 2 3 2337 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 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2339 |1|0|0|0| 8 | 0 | 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 | 0 | 9 | 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 The Message Type AVP contains a Value of 16, indicating Outgoing- 2345 Call-Connected. The Outgoing-Call-Connected message encodes the 2346 final result of an outgoing call request. The flags indicate a 2347 mandatory option. 2349 Result Code 2351 0 1 2 3 2352 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 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 |1|0|0|0| 10 + Message length | 0 | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | 1 | Result Code | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | Error Code | Optional Message ... 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 The Result Code AVP within an Outgoing-Call-Connected message 2362 indicates the final result of the outgoing call establishment 2363 attempt. It is encoded as Attribute 1, indicating a Result Code 2364 AVP. This AVP is mandatory and MUST be present. The Result Code 2365 is a 16-bit word. The 16-bit word following the Result Code field 2366 contains the Error Code value. The Result Code value indicates 2367 whether the Error Code value is meaningful or not. If it is not 2368 meaningful it should be set to a value of 0. An optional error 2369 message can follow the Error Code field. Its presence and length 2370 is indicated by the value of the AVP length field. Defined Result 2371 Code values are: 2373 1 - Call established with no errors 2374 2 - Outgoing Call not established for the reason indicated in Error Code 2375 3 - Outgoing Call failed due to no carrier detected 2376 4 - Outgoing Call failed due to detection of a busy signal 2377 5 - Outgoing Call failed due to lack of a dial tone 2378 6 - Outgoing Call was not established within time allotted by LAC 2379 7 - Outgoing Call was connected but no appropriate framing was detected 2381 Q.931 Cause Code 2383 0 1 2 3 2384 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 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 |0|0|0|0|9 + Advisory Msg length| 0 | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | 12 | Cause Code | 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | Cause Msg |Advisory Msg... 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 The Q.931 Cause Code AVP is used to give additional information in 2394 cases of call failure. The Attribute value is 12, indicating 2395 Cause Code, and is marked mandatory. This AVP is optional. It is 2396 only relevant when the LAC uses Q.931/DSS1 for the outbound call 2397 attempt. Cause Code is the returned Q.931 Cause code and Cause 2398 Msg is the returned Q.931 message code (e.g., DISCONNECT) 2399 associated with the Cause Code. Both values are returned in their 2400 native ITU encodings. An additional ASCII text Advisory Message 2401 may also be included (presence indicated by the AVP length) to 2402 further explain the call failure. 2404 Connect Speed 2406 0 1 2 3 2407 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 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 |1|0|0|0| 10 | 0 | 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 | 24 | BPS (H) | 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 | BPS (L) | 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 Connect Speed BPS AVP encodes the final negotiated speed for the 2417 connection. The Attribute value is 24, indicating Connect Speed, 2418 and is marked mandatory. This AVP MUST be present if the call 2419 attempt is successful. The BPS value indicates the speed in 2420 bits/second. 2422 Framing Type 2424 0 1 2 3 2425 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 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 |1|0|0|0| 10 | 0 | 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 Framing Type AVP encodes the framing type for the call. The 2435 Attribute value is 19, indicating Framing Type, and is marked 2436 mandatory. This AVP MUST be present if the call attempt is 2437 successful. The value bit field indicates the type of PPP framing 2438 is used for the call. If set, bit A indicates that asynchronous 2439 framing is being used. If set, bit S indicates that synchronous 2440 framing is being used. 2442 Receive Window Size 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| 8 | 0 | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | 10 | Size | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 Receive Window Size AVP encodes the window size being offered by 2453 the LNS for this call. The Attribute value is 10, indicating 2454 Receive Window Size, and is marked mandatory. The Size is a 16- 2455 bit value indicating the number of received data packets the LAC 2456 will buffer for this call, which is also the maximum number of 2457 data packets the LNS should send before waiting for an 2458 acknowledgment. This AVP MUST be present if and only if Sequence 2459 and Acknowledgment Numbers are to be used in the payload session 2460 for this call. 2462 Packet Processing Delay 2464 0 1 2 3 2465 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 2466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2467 |1|0|0|0| 8 | 0 | 2468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 | 20 | Delay | 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 Packet Processing Delay AVP encodes the delay the LAC expects for 2473 processing a window full of packets sent by the LNS. The 2474 Attribute value is 20, indicating Packet Processing Delay, and is 2475 marked mandatory. This AVP is optional. The Delay value is 2476 specified in units of 1/10 seconds. Refer to Appendix A to see a 2477 description of how this value is determined and used. 2479 6.10 Incoming-Call-Request 2481 Incoming-Call-Request is an L2TP control message sent by the LAC to 2482 the LNS to indicate that an inbound call is to be established from 2483 the LAC. This request provides the LNS with parameter information 2484 for the incoming call. 2486 This message is the first in the "three-way handshake" used by L2TP 2487 for establishing incoming calls. The LAC may defer answering the 2488 call until it has received an Incoming-Call-Reply from the LNS 2489 indicating that the call should be established. This mechanism 2490 allows the LNS to obtain sufficient information about the call before 2491 it is answered to determine whether the call should be answered or 2492 not. Alternatively, the LAC may answer the call, negotiate LCP and 2493 PPP authentication, and use the information gained to choose the LNS. 2494 In this case, the call has already been answered by the time the 2495 Incoming-Call-Reply message is received; the LAC simply spoofs the 2496 "call indication/answer call" phase in this case. 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 | L2TP Control Message Header | 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2501 | Incoming-Call-Request | 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 | Assigned Call ID | 2504 | Call Serial Number | 2505 | Bearer Type | 2506 | Physical Channel ID | 2507 | Dialed Number | 2508 | Dialing Number | 2509 | Sub-Address | 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 Incoming-Call-Request 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| 8 | 0 | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 | 0 | 10 | 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 The Message Type AVP contains a Value of 9, indicating Incoming- 2523 Call-Request. The Incoming-Call-Request message encodes an incoming 2524 call being indicated by the LAC. The flags indicate a mandatory 2525 option. 2527 Assigned Call ID 2529 0 1 2 3 2530 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 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 |1|0|0|0| 8 | 0 | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 | 14 | Call ID | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 The Assigned Call ID AVP encodes the Call ID being assigned to call 2538 by the LAC. The Attribute value is 14, indicating Call ID, and is 2539 marked mandatory. This AVP MUST be present. The LNS places this 2540 value in the Call ID header field of all command and payload packets 2541 that it subsequently transmits over the tunnel that belong to this 2542 call. The Call ID value is an identifier assigned by the LAC to this 2543 session. It is used to multiplex and demultiplex data sent over that 2544 tunnel between the LNS and LAC. 2546 Call Serial Number 2548 0 1 2 3 2549 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 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 |1|0|0|0| 6 + Number length | 0 | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | 15 | Number... 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 Call Serial Number AVP encodes an identifier assigned by the LAC to 2557 this call. The Attribute value is 15, Call Serial Number, and is 2558 marked mandatory. This AVP MUST be present. Please refer to the 2559 description of this field from section 6.8. 2561 Bearer Type 2563 0 1 2 3 2564 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 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 |1|0|0|0| 10 | 0 | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 Bearer Type AVP encodes the bearer type for the incoming call. The 2574 Attribute value is 18, Bearer Type, and is marked mandatory. This 2575 AVP MUST be present. The Value is a 32-bit field indicating the 2576 bearer capability being used by the incoming call. If set, bit A 2577 indicates that the call is on an analog channel. If set, bit D 2578 indicates that the call is on a digital channel. 2580 Physical Channel ID 2582 0 1 2 3 2583 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 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 |1|0|0|0| 10 | 0 | 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 | 25 | ID (H) | 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2590 | ID (L) | 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 Physical Channel ID AVP encodes the vendor specific physical channel 2594 number used for the call. The Attribute value is 25, Physical 2595 Channel ID, and is marked mandatory. The presence of this AVP is 2596 optional. ID is a 32-bit value in network byte order. The value is 2597 used for logging purposes only. 2599 Dialed Number 2601 0 1 2 3 2602 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 2603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 |1|0|0|0|6 + Phone Number length| 0 | 2605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 | 21 | Phone Number.. 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 Dialed Number AVP encodes the dialed number for the incoming call, 2610 that is, DNIS. The Attribute value is 21, Dialed Number, and is 2611 marked mandatory. The presence of this AVP is optional. The value 2612 is an ASCII string. 2614 Dialing Number 2616 0 1 2 3 2617 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 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 |1|0|0|0|6 + Phone Number length| 0 | 2620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2621 | 22 |Phone Number... 2622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2624 Dialing Number AVP encodes the originating number for the incoming 2625 call, that is, CLID. The Attribute value is 22, Dialing Number, and 2626 is marked mandatory. The presence of this AVP is optional. The 2627 value is an ASCII string. 2629 Sub-Address 2631 0 1 2 3 2632 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 2633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 |1|0|0|0|6 + Sub-Address length | 0 | 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 | 23 |Sub-Address ... 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 Sub-Address AVP encodes additional dialing information. The 2639 Attribute value is 23, Sub-Address, and is marked mandatory. The 2640 presence of this AVP is optional. The Sub-Address value is an ASCII 2641 string. 2643 6.11 Incoming-Call-Reply 2645 The Incoming-Call-Reply is an L2TP control message sent by the LNS to 2646 the LAC in response to a received Incoming-Call-Request message. The 2647 reply indicates the result of the incoming call attempt. It also 2648 provides information to allow the LAC to regulate the transmission of 2649 data to the LNS for this session. 2651 This message is the second in the three-way handshake used by L2TP 2652 for establishing incoming calls. It indicates to the LAC whether the 2653 call should be answered or not. 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 | L2TP Control Message Header | 2657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2658 | Incoming-Call-Reply | 2659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2660 | Assigned Call ID | 2661 | Result Code | 2662 | Receive Window Size | 2663 | Packet Processing Delay | 2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2666 Incoming-Call-Reply 2668 0 1 2 3 2669 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 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 |1|0|0|0| 8 | 0 | 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 | 0 | 11 | 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 The Message Type AVP contains a Value of 10, indicating Incoming- 2677 Call-Reply. The Incoming-Call-Reply message encodes a response by 2678 the LNS to the incoming call indication given by the LAC. The flags 2679 indicate a mandatory option. 2681 Assigned Call ID 2683 0 1 2 3 2684 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 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 |1|0|0|0| 8 | 0 | 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 | 14 | Call ID | 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 The Assigned Call ID AVP encodes the ID being assigned to call by the 2692 LNS. The Attribute value is 14, Assigned Call ID, and is marked 2693 mandatory. This AVP MUST be present if the Result Code indicates the 2694 call was successful. The LAC places this value in the Call ID header 2695 field of all command and payload packets that it subsequently 2696 transmits over the tunnel that belong to this call. The Call ID 2697 value is an identifier assigned by the LNS to this session. It is 2698 used to multiplex and demultiplex data sent over that tunnel between 2699 the LNS and LAC. 2701 Result Code 2703 0 1 2 3 2704 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 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 |1|0|0|0| 10 + Message length | 0 | 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 | 1 | Result Code | 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 | Error Code | Optional Message ... 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 The Result Code AVP within an Incoming-Call-Reply message 2714 indicates the result of the incoming call establishment attempt. 2715 It is encoded as Attribute 1, indicating a Result Code AVP. This 2716 AVP is mandatory and MUST be present. The Result Code is a 16-bit 2717 word. The 16-bit word following the Result Code field contains 2718 the Error Code value. The Result Code value indicates whether the 2719 Error Code value is meaningful or not. If it is not meaningful it 2720 should be set to a value of 0. An optional error message can 2721 follow the Error Code field. Its presence and length is indicated 2722 by the value of the AVP length field. Defined Result Code values 2723 are: 2725 1 - The LAC should answer the incoming call 2726 2 - The Incoming Call should not be established due to the 2727 reason indicated in Error Code 2728 3 - The LAC should not accept the incoming call. It should 2729 hang up or issue a busy indication 2731 Receive Window Size 2733 0 1 2 3 2734 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 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 |1|0|0|0| 8 | 0 | 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 | 10 | Size | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 | Optional Message... | 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 Receive Window Size AVP encodes the receive window size being 2744 offered by the LNS for this call. The Attribute value is 10, 2745 Receive Window Size, and is marked mandatory. The Size value 2746 indicates the number of received data packets the LNS will buffer 2747 for this call, which is also the maximum number of data packets 2748 the LAC should send before waiting for an acknowledgment. This 2749 AVP is optional if Sequence and Acknowledgment Numbers are not to 2750 be used in the payload session for this call. 2752 Packet Processing Delay 2754 0 1 2 3 2755 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 2756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2757 |1|0|0|0| 8 | 0 | 2758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2759 | 20 | Delay | 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 Packet Processing Delay AVP encodes the delay the LNS expects for 2763 processing a window full of packets sent by the LAC. The 2764 Attribute value is 20, Packet Processing Delay AVP, and is marked 2765 mandatory. The presence of this AVP is optional. The Delay value 2766 is specified in units of 1/10 seconds. Refer to Appendix A to see 2767 a description of how this value is determined and used. 2769 6.12 Incoming-Call-Connected 2771 The Incoming-Call-Connected message is an L2TP control message sent 2772 by the LAC to the LNS in response to a received Incoming-Call-Reply. 2773 It provides information to the LNS about particular parameters used 2774 for the call. It also provides information to allow the LNS to 2775 regulate the transmission of data to the LAC for this session. 2777 This message is the third in the three-way handshake used by L2TP for 2778 establishing incoming calls. It provides a mechanism for providing 2779 the LNS with additional information about the call that cannot, in 2780 general, be obtained at the time the Incoming-Call-Request is issued 2781 by the LAC. 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 | L2TP Control Message Header | 2785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 | Incoming-Call-Connected | 2787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2788 | Connect Speed | 2789 | Framing Type | 2790 | Receive Window Size | 2791 | Packet Processing Delay | 2792 | Initial LCP Conf | 2793 | Last Sent LCP Conf | 2794 | Last Received LCP Conf | 2795 | Proxy authen type | 2796 | Proxy authen name | 2797 | Proxy authen challenge | 2798 | Proxy authen ID | 2799 | Proxy authen response | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 Incoming-Call-Connected 2804 0 1 2 3 2805 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 2806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 |1|0|0|0| 8 | 0 | 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 | 0 | 12 | 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 The Message Type AVP contains a Value of 11, indicating Incoming- 2813 Call-Connected. The Incoming-Call-Connected message encodes a 2814 response by the LAC to the Incoming-Call-Reply message sent by the 2815 LAC. The flags indicate a mandatory option. 2817 Connect Speed 2819 0 1 2 3 2820 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 2821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 |1|0|0|0| 10 | 0 | 2823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2824 | 24 | BPS (H) | 2825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2826 | BPS (L) | 2827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 Connect Speed BPS AVP encodes the speed for the connection. The 2830 Attribute value is 24, Connect Speed, and is marked mandatory. This 2831 AVP MUST be present. The value is a 32-bit quantity indicating the 2832 speed in bits/second. 2834 Framing Type 2836 0 1 2 3 2837 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 2838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2839 |1|0|0|0| 10 | 0 | 2840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2841 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 Framing Type AVP encodes the framing type for the call. The 2847 Attribute value is 19, Framing Type, and is marked mandatory. This 2848 AVP MUST be present. The value is a 32-bit bit field indicating the 2849 type of PPP framing used for the call. If set, bit A indicates that 2850 asynchronous framing is being used. If set, bit S indicates that 2851 synchronous framing is being used. 2853 Receive Window Size 2854 0 1 2 3 2855 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 2856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2857 |1|0|0|0| 8 | 0 | 2858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2859 | 10 | Size | 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 Receive Window Size AVP encodes the window size being offered by the 2863 LAC for this call. The Attribute value is 10, Receive Window Size, 2864 and is marked mandatory. This AVP is optional if Sequence and 2865 Acknowledgment Numbers are not to be used in the payload session for 2866 this call. The 16-bit Size value indicates the number of received 2867 data packets the LAC will buffer for this call, which is also the 2868 maximum number of data packets the LNS should send before waiting for 2869 an acknowledgment. 2871 Packet Processing Delay 2873 0 1 2 3 2874 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 2875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 |1|0|0|0| 8 | 0 | 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 | 20 | Delay | 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2881 Packet Processing Delay AVP encodes the delay the LAC expects for 2882 processing a window full of packets sent by the LNS. The Attribute 2883 value is 20, Packet Processing Delay, and is marked mandatory. The 2884 presence of this AVP is optional. The 16-bit Delay value is 2885 specified in units of 1/10 seconds. Refer to Appendix A to see a 2886 description of how this value is determined and used. 2888 Initial LCP Conf 2890 0 1 2 3 2891 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 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 |0|0|0|0|6 + LCP confreq length | 0 | 2894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2895 | 26 | LCP confreq... 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2898 The LAC may have answered the phone call and negotiated LCP with the 2899 dial-in client in order to establish the client's apparent identity. 2900 In this case, this option may be included to indicate the link 2901 properties the client requested in its initial LCP CONFREQ request. 2902 The Attribute value is 26, Initial LCP Conf, and is marked optional. 2903 The presence of this AVP is optional. The Value field is a copy of 2904 the body of the initial CONFREQ received, starting at the first 2905 option within this packet's body. 2907 Last Sent LCP Conf 2908 0 1 2 3 2909 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 2910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2911 |0|0|0|0|6 + LCP confreq length | 0 | 2912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2913 | 27 | LCP confreq... 2914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2916 See Initial LCP Conf above for rationale. The Attribute value is 27, 2917 Last Sent LCP Conf, and is marked optional. The presence of this AVP 2918 is optional. The Value field is a copy of the body of the final 2919 CONFREQ sent to the client to complete LCP negotiation, starting at 2920 the first option within this packet's body. 2922 Last Received LCP Conf 2924 0 1 2 3 2925 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 2926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2927 |0|0|0|0|6 + LCP confreq length | 0 | 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 | 28 | LCP confreq... 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2932 See Initial LCP Conf above for rationale. The Attribute value is 28, 2933 Last Received LCP Conf, and is marked optional. The presence of this 2934 AVP is optional. The Value field is a copy of the body of the final 2935 CONFREQ received from the client to complete LCP negotiation, 2936 starting at the first option within this packet's body. 2938 Proxy Authen Type 2940 0 1 2 3 2941 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 2942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2943 |1|0|0|0| 8 | 0 | 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 | 29 | Type | 2946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2948 The Attribute value is 29, Proxy Authen Type, and is marked 2949 mandatory. This AVP MUST be present. The value Type is a 16-bit 2950 word, holding a value: 2952 1 - Textual username/password exchange 2953 2 - PPP CHAP 2954 3 - PPP PAP 2955 4 - None 2957 Associated AVP's for each type of authentication follow. 2959 Proxy Authen Name 2961 0 1 2 3 2962 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 2963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2964 |0|0|0|0| 6 + Name length | 0 | 2965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2966 | 30 | Name... 2967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 The Attribute value is 30, Proxy Authen Name, and is marked 2970 mandatory. This AVP MUST be present for Proxy Authen Type values 1, 2971 2, and 3. The Name field contains the name specified in the client's 2972 authentication response. Note that the AVP H bit may be desirable 2973 for obscuring the cleartext name. 2975 Proxy Authen Challenge 2977 0 1 2 3 2978 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 2979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2980 |0|0|0|0| 6 + Challenge length | 0 | 2981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2982 | 31 | Challenge... 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2985 The Attribute value is 31, Proxy Authen Challenge, and is marked 2986 mandatory. The AVP itself MUST be present for Proxy authen type 2. 2987 The Challenge field contains the value presented to the client by the 2988 LAC. 2990 Proxy Authen ID 2992 0 1 2 3 2993 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 2994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2995 |0|0|0|0| 8 | 0 | 2996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2997 | 32 | ID | 2998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3000 The Attribute value is 32, Proxy Authen ID, and is marked mandatory. 3001 The AVP itself MUST be present for Proxy authen type 2. The ID field 3002 contains the byte ID value presented to the client by the LAC in its 3003 associated CHAP challenge. The most significant 8 bits of ID MUST be 3004 0, and are reserved. 3006 Proxy Authen Response 3008 0 1 2 3 3009 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 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3011 |1|0|0|0| 6 + Response length | 0 | 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 | 33 | Response... 3014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 The Attribute value is 33, Proxy Authen Response, and is marked 3016 mandatory. The AVP itself MUST be present for Proxy authen types 1, 3017 2, and 3. The Response field contains the client's response to the 3018 challenge. For Proxy authen type 2, this field contains the response 3019 value received by the LAC. For types 1 or 3, it contains the clear 3020 text password received from the client by the LAC. In the case of 3021 cleartext passwords, use of the AVP H bit is recommended. 3023 6.13 Call-Clear-Request 3025 The Call-Clear-Request is an L2TP control message sent by the LNS to 3026 the LAC indicating that a particular call is to be disconnected. The 3027 call being cleared can be either an incoming or outgoing call, in any 3028 state. The LAC responds to this message with a Call-Disconnect- 3029 Notify message. 3031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3032 | L2TP Control Message Header | 3033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3034 | Call-Clear-Request | 3035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 | Assigned Call ID | 3037 +-+-+-+-+-+-+-+-+-+-+-+-+ 3039 Call-Clear-Request 3041 0 1 2 3 3042 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 3043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3044 |1|0|0|0| 8 | 0 | 3045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3046 | 0 | 13 | 3047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3049 The Message Type AVP contains a Value of 12, indicating Call-Clear- 3050 Request. The Call-Clear-Request message encodes a request by the LNS 3051 to the LAC to disconnect the call. The flags indicate a mandatory 3052 option. 3054 Assigned Call ID 3056 0 1 2 3 3057 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 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 |1|0|0|0| 8 | 0 | 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3061 | 14 | Call ID | 3062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3064 This attribute is used to provide the LAC with the Call ID assigned 3065 by the LNS for the call to be cleared in the case where the LNS has 3066 not yet learned the LAC's Call ID for the call. The Attribute value 3067 is 14, Assigned Call ID, and is marked mandatory. This AVP MUST be 3068 present. The value Call ID MUST be the same value sent from the LNS 3069 to the LAC in the initial call setup exchange. 3071 6.14 Call-Disconnect-Notify 3073 The Call-Disconnect-Notify message is an L2TP control message sent by 3074 the LAC to the LNS. It is issued whenever a call is disconnected, 3075 due to the receipt by the LAC of a Call-Clear-Request or for any 3076 other reason. Its purpose is to inform the LNS of the disconnection 3077 and the reason why the disconnection occurred. 3079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3080 | L2TP Control Message Header | 3081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3082 | Call-Disconnect-Notify | 3083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3084 | Result Code | 3085 | Q.931 Cause Code | 3086 | Assigned Call ID | 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3089 Call-Disconnect-Notify 3091 0 1 2 3 3092 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 3093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3094 |1|0|0|0| 8 | 0 | 3095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3096 | 0 | 14 | 3097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3099 The Message Type AVP contains a Value of 13, indicating Call- 3100 Disconnect-Notify. The Call-Disconnect-Notify message encodes a 3101 disconnect indication from the LAC to the LNS. The flags indicate a 3102 mandatory option. 3104 Result Code 3106 0 1 2 3 3107 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 3108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3109 |1|0|0|0| 10 + Message length | 0 | 3110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3111 | 1 | Result Code | 3112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3113 | Error Code | Optional Message ... 3114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3116 The Result Code AVP within a Call-Disconnect-Notify message 3117 indicates the reason for the call disconnect. It is encoded as 3118 Attribute 1, indicating a Result Code AVP. This AVP is mandatory 3119 and MUST be present. The Result Code is a 16-bit word. The 16- 3120 bit word following the Result Code field contains the Error Code 3121 value. The Result Code value indicates whether the Error Code 3122 value is meaningful or not. If it is not meaningful it should be 3123 set to a value of 0. An optional error message can follow the 3124 Error Code field. Its presence and length is indicated by the 3125 value of the AVP length field. Defined Result Code values are: 3127 1 (Lost Carrier) - Call disconnected due to loss of carrier 3128 2 (General Error) - Call disconnected for the reason indicated 3129 in Error Code. 3130 3 (Admin Shutdown) - Call disconnected for administrative 3131 reasons 3132 4 (Request) - Call disconnected due to received Call-Clear- 3133 Request 3135 Q.931 Cause Code 3137 0 1 2 3 3138 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 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3140 |0|0|0|0|9 + Advisory Msg length| 0 | 3141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3142 | 12 | Cause Code | 3143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3144 | Cause Msg |Advisory Msg... 3145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 The Q.931 Cause Code AVP is used to give additional information in 3148 case of unsolicited call disconnection. The Attribute value is 3149 12, Cause Code, and is marked mandatory. The presence of this AVP 3150 is optional. The Cause Code AVP is used to give additional 3151 information about the reason for disconnecting. It is only 3152 relevant when the LAC is using Q.931/DSS1 for the call. This AVP 3153 is optional. Cause Code is the returned Q.931 Cause code and 3154 Cause Msg is the returned Q.931 message code (e.g., DISCONNECT) 3155 associated with the Cause Code. Both values are returned in their 3156 native ITU encodings. An additional Ascii text Advisory Message 3157 may also be included (presence indicated by the AVP length) to 3158 further explain the reason for disconnecting. 3160 Assigned Call ID 3162 0 1 2 3 3163 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 3164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3165 |1|0|0|0| 8 | 0 | 3166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3167 | 14 | Call ID | 3168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 The Assigned Call ID which was provided to the LNS from this LAC 3171 is included in the Call-Disconnect-Notify message. This permits a 3172 connection to be terminated even before the LNS has provided its 3173 own Assigned Call ID to this LAC (the Call ID field in the control 3174 message header is 0). The Attribute value is 14, Assigned Call 3175 ID, and is marked mandatory. This AVP MUST be present. 3177 6.15 WAN-Error-Notify 3179 The WAN-Error-Notify message is an L2TP control message sent by the 3180 LAC to the LNS to indicate WAN error conditions (conditions that 3181 occur on the interface supporting PPP). The counters in this message 3182 are cumulative. This message should only be sent when an error 3183 occurs, and not more than once every 60 seconds. The counters are 3184 reset when a new call is established. 3186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3187 | L2TP Control Message Header | 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 | WAN-Error-Notify | 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3191 | Call Errors | 3192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3194 WAN-Error-Notify 3196 0 1 2 3 3197 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 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3199 |1|0|0|0| 8 | 0 | 3200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3201 | 0 | 15 | 3202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3204 The Message Type AVP contains a Value of 14, indicating WAN-Error- 3205 Notify. The WAN-Error-Notify message encodes information about line 3206 and other errors detected on the LAC's physical interface to the 3207 client. This message is sent by the LAC to the LNS. The flags 3208 indicate a mandatory option. 3210 Call Errors 3212 0 1 2 3 3213 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 3214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3215 |1|0|0|0| 32 | 0 | 3216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3217 | 34 | Reserved | 3218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 | CRC Errors | 3220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3221 | Framing Errors | 3222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3223 | Hardware Overruns | 3224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3225 | Buffer Overruns | 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 | Time-out Errors | 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 | Alignment Errors | 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3231 The Call Errors AVP is used by the LAC to send error information to 3232 the LNS. The Attribute value is 34, WAN-Error-Notify, and is marked 3233 mandatory. This AVP MUST be present. The value contains the 3234 following fields: 3236 Reserved - Not used, MUST be 0 3237 CRC Errors - Number of PPP frames received with CRC errors since 3238 session was established 3239 Framing Errors - Number of improperly framed PPP packets received 3240 Hardware Overruns - Number of receive buffer over-runs since 3241 session was established 3242 Buffer Overruns - Number of buffer over-runs detected since 3243 session was established 3244 Time-out Errors - Number of time-outs since call was established 3245 Alignment Errors - Number of alignment errors since call was 3246 established 3248 6.16 Set-Link-Info 3250 The Set-Link-Info message is an L2TP control message sent by the LNS 3251 to the LAC to set PPP-negotiated options. Because these options can 3252 change at any time during the life of the call, the LAC MUST be able 3253 to update its internal call information dynamically and update its 3254 behavior on an active PPP session. 3256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3257 | L2TP Control Message Header | 3258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3259 | Set-Link-Info | 3260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3261 | ACCM | 3262 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3264 Set-Link-Info 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 |1|0|0|0| 8 | 0 | 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3271 | 0 | 16 | 3272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3274 The Message Type AVP contains a Value of 15, indicating Set-Link- 3275 Info. The Set-Link-Info message encodes ACCM information sent from 3276 the LNS to the LAC after it is negotiated in LCP. The flags indicate 3277 a mandatory option. 3279 ACCM 3281 0 1 2 3 3282 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 3283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3284 |1|0|0|0| 32 | 0 | 3285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 | 35 | Reserved | 3287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3288 | Send ACCM | 3289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3290 | Receive ACCM | 3291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3293 The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. 3294 The Attribute value is 35, ACCM, and is marked mandatory. This 3295 attribute MUST be present. The value contains Send ACCM and Receive 3296 ACCM fields. The send ACCM value should be used by the LAC to 3297 process packets it is sends on the connection. The receive ACCM 3298 value should be used by the LAC to process incoming packets on the 3299 connection. The default values used by the LAC for both these fields 3300 are 0xFFFFFFFF. The LAC should honor these fields unless it has 3301 specific configuration information to indicate that the requested 3302 mask must be modified to permit operation. 3304 7.0 Control Connection State Machines 3306 The control messages defined in section 6 are exchanged by way of state 3307 tables defined in this section. Tables are defined for incoming call 3308 placement, outgoing call placement, as well as for initiation of the 3309 tunnel itself. The state tables do not encode timeout and 3310 retransmission behavior, as this is handled in the underlying semantics 3311 defined in 6.0.2. 3313 7.1 Control Connection Protocol Operation 3315 This section describes the operation of various L2TP control 3316 connection functions and the Control Connection messages which are 3317 used to support them. 3319 Receipt of an invalid or malformed Control Connection message should 3320 be logged appropriately, and the control connection should be closed 3321 and restarted to ensure recovery into a known state. 3323 7.2 Control Connection States 3325 Control messages are carried over the same media as the payload 3326 messages which are carried following successful connection 3327 establishment. The L2TP control connection protocol is not 3328 distinguishable between the LNS and LAC, but is distinguishable 3329 between the originator and receiver. The originating peer is the one 3330 which first establishes the tunnel. Since either LAC or LNS can be 3331 the originator, a collision can occur. See Section 6.0.1 for a 3332 description of this and its resolution situation. 3334 7.2.1 Control Connection Originator 3336 State Event Action New State 3337 ----- ----- ------ --------- 3338 idle Open request Send wait-ctl-reply 3339 Start-Control- 3340 Connection-Request 3342 wait-ctl-reply Collision If terminating, idle 3343 clean-up. 3345 wait-ctl-reply Collision If not terminating, wait-stop-reply 3346 Send Stop-Control- 3347 Connection-Request 3349 wait-ctl-reply Receive If version OK established 3350 Start-Control- Send Start-Control- 3351 Connection-Reply Connection-Connected 3353 wait-ctl-reply Receive If version not OK wait-stop-reply 3354 Start-Control- or bad auth, Send 3355 Connection-Reply Stop-Control- 3356 Connection-Request 3358 established Local terminate Send wait-stop-reply 3359 Stop-Control- 3360 Connection-Request 3362 established Receive Send idle 3363 Stop-Control- Stop-Control- 3364 Connection- Connection-Reply 3365 Request and clean-up 3367 wait-stop-reply Receive Clean-up idle 3368 Stop-Control- 3369 Connection-Reply 3371 idle 3372 The control connection originator attempts to open a connection to 3373 the peer during idle state. When the connection is open, the 3374 originator transmits a send Start-Control-Connection-Request and 3375 then enters the wait-ctl-reply state. 3377 wait-ctl-reply 3378 The originator checks to see if another connection has been 3379 requested from the same peer, and if so, handles the collision 3380 situation described in Section 6.0.1. 3382 When a Start-Control-Connection-Reply is received, it is examined 3383 for a compatible version. If the version of the reply is lower 3384 than the version sent in the request, the older (lower) version 3385 should be used provided it is supported. If the version in the 3386 reply is earlier and supported, the originator moves to the 3387 established state. If the version is earlier and not supported, a 3388 Stop-Control-Connection-Request SHOULD be sent to the peer and the 3389 originator moves into the wait-stop-reply state. 3391 established 3392 An established connection may be terminated by either a local 3393 condition or the receipt of a Stop-Control-Connection-Request. In 3394 the event of a local termination, the originator MUST send a 3395 Stop-Control-Connection-Request and enter the wait-stop-reply 3396 state. 3398 If the originator receives a Stop-Control-Connection-Request it 3399 SHOULD send a Stop-Control-Connection-Reply and close the 3400 connection. 3402 wait-stop-reply 3403 If a Stop-Control-Connection-Reply is received, the connection 3404 SHOULD be closed and the control connection becomes idle. 3406 7.2.2 Control connection Receiver 3408 State Event Action New State 3409 ----- ----- ------ --------- 3410 idle Receive If version not OK idle 3411 Start-Control- send 3412 Connection-Request Start-Control- 3413 Connection-Reply 3414 with error 3416 idle Receive Version OK, send wait-ctl-reply 3417 Start-Control- Start-Control- 3418 Connection-Request Connection-Reply 3420 wait-ctl-reply Receive Clean-up, send idle 3421 Stop-Control- Stop-Control- 3422 Connection-Request Connection-Reply 3424 wait-ctl-reply Receive If auth OK established 3425 Start-Control- 3426 Connection-Connected 3428 wait-ctl-reply Receive If auth not OK wait-stop-reply 3429 Start-Control- Send Stop-Control- 3430 Connection- Connection-Request 3431 Connected 3433 established Receive Clean-up, send idle 3434 Stop-Control- Stop-Control- 3435 Connection-Request Connection-Reply 3437 established Local terminate Send wait-stop-reply 3438 Stop-Control- 3439 Connection-Request 3441 wait-stop-reply Receive Clean-up idle 3442 Stop-Control- 3443 Connection-Reply 3445 idle 3446 The control connection receiver waits for an incoming connection 3447 attempt. When notified of a new connection, it should prepare to 3448 receive L2TP messages. When a Start-Control-Connection-Request is 3449 received its version field MUST be examined. If the version is 3450 earlier than the receiver's version and the earlier version can be 3451 supported by the receiver, the receiver SHOULD send a 3452 Start-Control-Connection-Reply. 3454 If the version is earlier than the receiver's 3455 version and the version cannot be supported, the receiver SHOULD send 3456 a Start-Connection-Reply message indicating this error and remain in 3457 the idle state. If the receiver's version is the same as 3458 or earlier than the peer's, the receiver SHOULD send a 3459 Start-Control-Connection-Reply with the receiver's version and enter the 3460 wait-ctl-reply state. 3462 wait-ctl-reply 3464 The peer waits in this state after sending a Start-Control-Connection-Reply. 3465 If it receives a Start-Control-Connection-Reply, it checks to see if the 3466 message is properly authenticated and, if so, it enters the established 3467 state. 3468 If authentication fails, a Stop-Control-Connection-Request with the reason 3469 code set appropriately is sent and wait-stop-reply state is entered. 3470 if a Stop-Control-Connection-Request is received, a 3471 Stop-Control-Connection-Reply. is issued and idle state is entered. 3473 established 3474 An established connection may be terminated by either a local 3475 condition or the reception of a Stop-Control-Connection-Request. In 3476 the event of a local termination, the originator MUST send a 3477 Stop-Control-Connection-Request 3478 and enter the wait-stop-reply state. 3480 If the originator receives a Stop-Control-Connection-Request it 3481 SHOULD send a Stop-Control-Connection-Reply and close the 3482 connection. 3484 wait-stop-reply 3485 If a Stop-Control-Connection-Reply is received, the connection 3486 SHOULD be closed and the control connection becomes idle. 3488 7.3 Timing considerations 3490 Because of the real-time nature of telephone signaling, both the LNS 3491 and LAC should be implemented with multi-threaded architectures such 3492 that messages related to multiple calls are not serialized and 3493 blocked. 3494 The call and connection state figures do not specify 3495 exceptions caused by timers. These are addressed in Section 6.0.2. 3497 7.4 Incoming calls 3499 An Incoming-Call-Request message is generated by the LAC when an 3500 associated telephone line rings. The LAC selects a Call ID and serial 3501 number and indicates the call bearer type. Modems should always 3502 indicate analog call type. ISDN calls should indicate digital when 3503 unrestricted digital service or rate adaption is used and analog if 3504 digital modems are involved. CLID, DNIS, and 3505 subaddress may be included in the message if they are available from 3506 the telephone network. 3508 Once the LAC sends the Incoming-Call-Request, it waits for a response 3509 from the LNS but it does not necessarily answer the call from the 3510 telephone network yet. The LNS may choose not to accept the call if: 3512 - No resources are available to handle more sessions 3513 - The dialed, dialing, or subaddress fields are not indicative of 3514 an authorized user 3515 - The bearer service is not authorized or supported 3517 If the LNS chooses to accept the call, it responds with an 3518 Incoming-Call-Reply 3519 which also indicates window sizes (see Appendix B). When 3520 the LAC receives the Incoming-Call-Reply, it attempts to connect the 3521 call, assuming the calling party has not hung up. A final call 3522 connected message from the LAC to the LNS indicates that the call 3523 states for both the LAC and the LNS should enter the established 3524 state. 3526 When the dialed-in client hangs up, the call is cleared normally and 3527 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 3528 clear a call, it sends a Call-Clear-Request message and then waits 3529 for a Call-Disconnect-Notify. 3531 7.4.1 LAC Incoming Call States 3533 State Event Action New State 3534 ----- ----- ------ --------- 3535 idle Ring OR Send wait-reply 3536 Ready to indicate Incoming-Call-Request 3537 incoming conn. 3539 wait-reply Receive Clean-up idle 3540 Incoming-Call-Reply 3541 Not Accepting 3543 wait-reply Receive Answer call established 3544 Incoming-Call-Reply Send 3545 Accepting Incoming-Call-Connected 3547 wait-reply Abort Clean-up idle 3548 Send Call-Disconnect- 3549 Notify 3551 established Receive Hang-up and send idle 3552 Call-Clear-Request Call-Disconnect-Notify 3554 established telco line drop Send idle 3555 Call-Disconnect-Notify 3557 established local disconnect Send idle 3558 Call-Disconnect-Notify 3560 The states associated with the LAC for incoming calls are: 3562 idle 3564 The LAC detects an incoming call on one of its telco interfaces. 3565 Typically this means an analog line is ringing or an ISDN TE has 3566 detected an incoming Q.931 SETUP message. The LAC sends an 3567 Incoming-Call-Request message and moves to the wait-reply state. 3569 wait-reply 3571 The LAC receives an Incoming-Call-Reply message indicating non- 3572 willingness to accept the call (general error or don't accept) and 3573 moves back into the idle state. If the reply message indicates that 3574 the call is accepted, the LAC sends an Incoming-Call-Connected 3575 message and enters the established state. 3577 established 3579 Data is exchanged over the tunnel. The call may be cleared 3580 following: 3581 An event on the telco connection. The LAC sends a Call- 3582 Disconnect-Notify message 3583 Receipt of a Call-Clear-Request. The LAC sends a Call- 3584 Disconnect-Notify message 3585 A local reason. The LAC sends a Call-Disconnect-Notify message. 3587 7.4.2 LNS Incoming Call States 3589 State Event Action New State 3590 ----- ----- ------ --------- 3591 idle Receive If not accepting idle 3592 Incoming-Call-Request Send 3593 Incoming-Call-Reply 3594 with Error 3596 idle Receive If accepting wait-connect 3597 Incoming-Call-Request Send 3598 Incoming-Call-Reply 3600 wait-connect Receive Clean-up idle 3601 Call-Disconnect-Notify 3603 wait-connect Receive Get ready for data established 3604 Incoming-Call-Connect 3606 established Receive Clean-up idle 3607 Call-Disconnect-Notify 3609 established Local terminate Send wait- 3610 Call-Clear-Request disconnect 3612 wait- Receive Clean-up idle 3613 disconnect Call-Disconnect-Notify 3615 The states associated with the LNS for incoming calls are: 3617 idle 3619 An Incoming-Call-Request message is received. If the request is 3620 not acceptable, an Incoming-Call-Reply is sent back to the LAC and 3621 the LNS remains in the idle state. If the Incoming-Call-Request 3622 message is acceptable, an Incoming-Call-Reply is sent indicating 3623 accept in the result code. The session moves to the wait-connect 3624 state. 3626 wait-connect 3628 If the session is still connected on the LAC, the LAC sends an 3629 incoming call connect message to the LNS which then moves into 3630 established state. The LAC may send a Call-Disconnect-Notify to 3631 indicate that the incoming caller could not be connected. This 3632 could happen, for example, if a telephone user accidentally places 3633 a standard voice call to an LAC resulting in a handshake failure 3634 on the called modem. 3636 established 3638 The session is terminated either by receipt of a Call-Disconnect- 3639 Notify message from the LAC or by sending a Call-Clear-Request. 3640 Once a Call-Clear-Request has been sent, the session enters the 3641 wait-disconnect state. 3643 wait-disconnect 3645 Once a Call-Disconnect-Notify is received the session moves back 3646 to the idle state. 3648 7.5 Outgoing calls 3650 Outgoing calls are initiated by an LNS and instruct an LAC to place a 3651 call on a telco interface. There are three messages for outgoing calls: 3652 Outgoing-Call-Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. 3653 The LNS sends an Outgoing-Call-Request specifying the dialed party phone 3654 number and subaddress as well as speed and window parameters. The LAC 3655 MUST respond to the Outgoing-Call-Request message with an Outgoing- 3656 Call-Reply message once the LAC determines that the proper facilities 3657 exist to place the call and the call is administratively authorized. 3658 For example, is this LNS allowed to dial an international call? Once 3659 the outbound call is connected the LAC sends an Outgoing-Call-Connected 3660 message to the LNS indicating the final result of the call attempt: 3662 7.5.1 LAC Outgoing Call States 3664 State Event Action New State 3665 ----- ----- ------ --------- 3666 idle Receive If cannot service, idle 3667 Outgoing-Call- send Outgoing-Call-Reply 3668 Request with Error 3670 idle Receive If can service, wait-cs-ans 3671 Outgoing-Call- send 3672 Request Outgoing-Call-Reply 3674 wait-cs-ans Telco answer Send established 3675 and framing Outgoing-Call-Connected 3676 detected 3678 wait-cs-ans Call failure Send 3679 Outgoing-Call-Connected idle 3680 with Error 3682 wait-cs-ans Receive Hang-up, send idle 3683 Call-Clear-Request Call-Disconnect-Notify 3685 established Receive Hang-up, send idle 3686 Call-Clear-Request Call-Disconnect-Notify 3687 or detect call 3688 disconnected 3690 The states associated with the LAC for outgoing calls are: 3692 idle 3694 Received Outgoing-Call-Request. If this is received in error, 3695 respond with an Outgoing-Call-Reply with error condition set. 3696 Otherwise, allocate physical channel to dial on and send an 3697 Outgoing-Call-Reply. Place the outbound call and move to the 3698 wait-cs-ans state. 3700 wait-cs-ans 3702 If the call is not completed or a timer expires waiting for the 3703 call to complete, send an Outgoing-Call-Connected with the 3704 appropriate error condition set and go to idle state. If a 3705 circuit switched connection is established and framing is 3706 detected, send an Outgoing-Call-Reply indicating success and go to 3707 established state. 3709 established 3711 If a Call-Clear-Request is received, the telco call SHOULD be 3712 released via appropriate mechanisms and a Call-Disconnect-Notify 3713 message SHOULD BE sent to the LNS. If the call is disconnected by 3714 the client or by the telco interface, a Call-Disconnect-Notify 3715 message MUST be sent to the LNS. Return to idle state after 3716 sending the Call-Disconnect-Notify. 3718 7.5.2 LNS Outgoing Call States 3720 State Event Action New State 3721 ----- ----- ------ --------- 3722 idle Open request Send wait-reply 3723 Outgoing-Call-Request 3725 wait-reply Receive Clean-up idle 3726 Outgoing-Call-Reply 3727 with Error 3729 wait-reply Receive Null wait-connect 3730 Outgoing-Call-Reply 3732 wait-reply Abort request Send wait-disconnect 3733 Call-Clear-Request 3735 wait-connect Abort request Send 3736 Call-Clear-Request wait-disconnect 3738 wait-connect Receive Get ready for data established 3739 Outgoing-Call-Connected 3740 no Error 3742 wait-connect Receive Clean-up idle 3743 Outgoing-Call-Connected 3744 with Error 3746 established Receive Clean-up idle 3747 Call-Disconnect-Notify 3749 established Local terminate Send wait-disconnect 3750 Call-Clear-Request 3752 wait-disconnect Receive Clean-up idle 3753 Call-Disconnect- 3754 Notify 3756 The states associated with the LNS for outgoing calls are: 3758 idle 3759 An Outgoing-Call-Request message is sent to the LAC and the 3760 session moves into the wait-reply state. 3762 wait-reply 3763 An Outgoing-Call-Reply is received which indicates an error. The 3764 session returns to idle state. If the Outgoing-Call-Reply does 3765 not indicate an error, the telco call is connected and the session 3766 moves to the established state. 3768 wait-connect 3769 An Outgoing-Call-Connected is received which indicates an error. 3771 The session returns to idle state. No telco call is active. If 3772 the Outgoing-Call-Connected does not indicate an error, the telco 3773 call is 3775 established 3776 If a Call-Disconnect-Notify is received, the telco call has been 3777 terminated for the reason indicated in the Result and Cause Codes. 3778 The session moves back to the idle state. If the LNS chooses to 3779 terminate the session, it sends a Call-Clear-Request to the LAC 3780 and then enters the wait-disconnect state. 3782 wait-disconnect 3783 A session disconnection is waiting to be confirmed by the LAC. 3784 Once the LNS receives the Call-Disconnect-Notify message, the 3785 session enters idle state. 3787 8.0 L2TP Over Specific Media 3789 L2TP tries to be self-describing, operating at a level above the 3790 particular media over which it is carried. However, some details of 3791 its connection to media are required to permit interoperable 3792 implementations. The following sections describe details needed to 3793 permit interoperability over specific media. 3795 8.1 IP/UDP 3797 L2TP uses the well-known UDP port 1701 [3]. The entire L2TP packet, 3798 including payload and L2TP header, is sent within a UDP datagram. 3799 The initiator of an L2TP tunnel picks an available source UDP port, 3800 and sends to the desired destination at port 1701. The recipient 3801 picks a free port on its own system, and sends its reply to the 3802 initiator's UDP port, setting its own UDP source port set to the free 3803 port it found. All subsequent packets exchanged will use these UDP 3804 ports. It is legal for a peer's IP address used for a given tunnel 3805 to change over the life of a connection; this may correspond to a 3806 peer with multiple IP interfaces responding to a network topology 3807 change. Responses should reflect the last source IP address for that 3808 Tunnel ID. 3810 IP fragmentation may occur as the L2TP packet travels over the IP 3811 substrate. L2TP makes no special efforts to optimize this. A LAC 3812 implementation MAY cause its LCP to negotiate for a specific MRU, 3813 which could optimize for LAC environments in which the MTUs of the 3814 path over which the L2TP packets are likely to travel have a 3815 consistent value. 3817 When operating over UDP, both the I and C bits MUST be present, and 3818 are used to permit correct demultiplexing and tunnel identification. 3820 The default for any L2TP implementation is that UDP checksums MUST be 3821 enabled for both control and payload messages. An L2TP 3822 implementation MAY provide an option to disable UDP checksums for 3823 payload packets. It is recommended that UDP checksums always be 3824 enabled on control packets. 3826 Port 1701 is used for both L2F [5] and L2TP packets. The two types 3827 of packets may be detected by their headers; L2TP has a Vers field of 3828 2, L2F has a 1 in this field instead. An L2TP implementation running 3829 on a system which does not support L2F MUST silently discard all 3830 packets whose Vers field is set to 1. 3832 8.2 IP 3834 When operating in IP environments, L2TP MUST use the UDP 3835 encapsulation described in 8.1. 3837 9.0 Security Considerations 3839 L2TP encounters several security issues in its operation. The 3840 general approach of L2TP to these issues is documented here. 3842 9.1 Tunnel Endpoint Security 3844 The tunnel endpoints may authenticate each other during tunnel 3845 establishment. This authentication has the same security 3846 attributes as CHAP, and has reasonable protection against reply 3847 and snooping. 3849 Once the tunnel endpoints have authenticated, a derived Key may be 3850 carried in subsequent packets, which provides mild protection 3851 against brief or "accidental" attacks. There is no cryptographic 3852 strength to these Keys, and any attacker which can snoop packets 3853 can take control of the tunnel. 3855 For L2TP tunnels over IP, IP-level packet security provides very 3856 strong protection of the tunnel. This requires no modification to 3857 the L2TP protocol, and leverages extensive IETF work in this area. 3859 For L2TP tunnels over Frame Relay or other switched networks, 3860 current practice indicates that these media are much less likely 3861 to experience attacks of in-transit data. If these attacks became 3862 prevalent, either the media or the L2TP packets would have to be 3863 encrypted. 3865 9.2 Client Security 3867 A more systematic method of protection in tunneled PPP 3868 environments may be achieved through client security. PPP layer 3869 encryption would provide end-to-end security for both direct 3870 dial-in clients as well as PPP clients carried within a tunnel. 3871 With this level of client security, sessions are protected against 3872 attacks against the carrying tunnel, as well as attacks on the LAC 3873 itself. Because both encryption and compression can occur at the 3874 PPP layer, the two can be coordinated, permitting compression to 3875 precede encryption. 3877 9.3 Proxy Authentication 3879 The optional proxy CHAP function of L2TP can permit an entirely 3880 transparent PPP tunnel, with a single LCP and CHAP sequence being 3881 seen by the client. For cases where the LAC and the entire path 3882 to the LNS are operated by a single entity, this function may 3883 provide acceptable security. For cases where LNS-initiated 3884 authentication is required, proxy CHAP still permits an initial 3885 access decision to be made before accepting the tunnel, permitting 3886 the LNS in most cases to reject tunnel initiations rather than 3887 accept them and later disconnect. 3889 The optional proxy PAP may result in the cleartext password 3890 traversing the tunnel. Where PAP is being used in conjunction 3891 with static passwords, this may pose a significant security issue. 3892 Where PAP is only used to transport one-time passwords, such 3893 issues may be greatly mitigated. The H bit of the carrying AVP 3894 may be used to protect against this. 3896 10.0 Acknowledgments 3898 The AVP construct comes from Glen Zorn, who thought up the framework 3899 for permitting multiple vendors to contribute to a common attribute 3900 space in a relatively orderly fashion. 3902 Dory Leifer and Allan Rubens of Ascend Communications made valuable 3903 refinements to the protocol definition of L2TP and contributed to the 3904 editing of this document. 3906 11.0 Contacts 3908 Kory Hamzeh 3909 Ascend Communications 3910 1275 Harbor Bay Parkway 3911 Alameda, CA 94502 3912 kory@ascend.com 3914 Tim Kolar, Morgan Littlewood, Andrew J. Valencia 3915 Cisco Systems 3916 170 West Tasman Drive 3917 San Jose CA 95134-1706 3918 tkolar@cisco.com 3919 littlewo@cisco.com 3920 vandys@cisco.com 3922 Gurdeep Singh Pall 3923 Microsoft Corporation 3924 Redmond, WA 3925 gurdeep@microsoft.com 3927 Jeff Taarud 3928 Copper Mountain Networks 3929 jtaarud@coppermountain.com 3931 William Verthein 3932 U.S. Robotics 3934 12.0 References 3936 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 3937 07/21/1994 3939 [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet 3940 draft, April 1996 3942 [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point 3943 Tunneling Protocol", Internet draft, June 1996 3945 [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC1034, 3946 November 1987 3948 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, 3949 USC/Information Sciences Institute, July 1992. 3951 [6] Sally Floyd, Van Jacobson, "Random Early Detection Gateways for 3952 Congestion Avoidance", IEEE/ACM Transactions on Networking, 3953 August 1993 3955 [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, 3956 October 1996 3958 [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authentication 3959 Dial In User Service (RADIUS)." draft-ietf-radius-radius-05.txt, 3960 Livingston, Merit, Daydreamer, July 1996. 3962 Appendix A: Acknowledgment Time-Outs 3964 L2TP uses sliding windows and time-outs to provide both user session 3965 flow-control across the underlying medium (which may be an 3966 internetwork) and to perform efficient data buffering to keep the 3967 LAC-LNS data channels full without causing receive buffer overflow. 3968 L2TP requires that a time-out be used to recover from dropped data or 3969 acknowledgment packets. The exact implementation of the time-out is 3970 vendor-specific. It is suggested that an adaptive time-out be 3971 implemented with backoff for congestion control. The time-out 3972 mechanism proposed here has the following properties: 3974 Independent time-outs for each session. A device (LAC or LNS) 3975 will have to maintain and calculate time-outs for every active 3976 session. 3978 An administrator-adjustable maximum time-out, MaxTimeOut, unique 3979 to each device. 3981 An adaptive time-out mechanism that compensates for changing 3982 throughput. To reduce packet processing overhead, vendors may 3983 choose not to recompute the adaptive time-out for every received 3984 acknowledgment. The result of this overhead reduction is that the 3985 time-out will not respond as quickly to rapid network changes. 3987 Timer backoff on time-out to reduce congestion. The backed-off 3988 timer value is limited by the configurable maximum time-out value. 3989 Timer backoff is done every time an acknowledgment time-out 3990 occurs. 3992 In general, this mechanism has the desirable behavior of quickly 3993 backing off upon a time-out and of slowly decreasing the time-out 3994 value as packets are delivered without time-outs. 3996 Some definitions: 3998 Packet Processing Delay, "PPD", is the amount of time required for 3999 each peer to process the maximum amount of data buffered in their 4000 offered receive packet window. The PPD is the value exchanged 4001 between the LAC and LNS when a call is established. For the LNS, 4002 this number should be small. For an LAC supporting modem 4003 connections, this number could be significant. 4005 "Sample" is the actual amount of time incurred receiving an 4006 acknowledgment for a packet. The Sample is measured, not 4007 calculated. 4009 Round-Trip Time, "RTT", is the estimated round-trip time for an 4010 Acknowledgment to be received for a given transmitted packet. 4011 When the network link is a local network, this delay will be 4012 minimal (if not zero). When the network link is the Internet, 4013 this delay could be substantial and vary widely. RTT is adaptive: 4014 it will adjust to include the PPD and whatever shifting network 4015 delays contribute to the time between a packet being transmitted 4016 and receiving its acknowledgment. 4018 Adaptive Time-Out, "ATO", is the time that must elapse before an 4019 acknowledgment is considered lost. After a time-out, the sliding 4020 window is partially closed and the ATO is backed off. 4022 Packet Processing Delay (PPD) 4024 The PPD parameter is a 16-bit time value exchanged during the Call 4025 Control phase expressed in units of tenths of a second (64 means 6.4 4026 seconds). The protocol only specifies that the parameter is 4027 exchanged, it does not specify how it is calculated. The way values 4028 for ATO are calculated is implementation-dependent and need not be 4029 variable (static time-outs are allowed). IF adaptive time-outs are 4030 to be used then the PPD should be exchanged in the call connect 4031 sequences. A possible way to calculate the PPD is: 4033 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 4034 + LACFudge (for an LAC) 4035 or 4036 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4037 + LNSFudge (for an LNS) 4039 Header is the total size of the L2TP and media dependent headers. 4040 MTU is the overall MTU for the link between the LAC and LNS. 4042 WindowSize represents the number of packets in the sliding window, 4043 and is implementation-dependent. The latency of the underlying 4044 connection path between the LAC and LNS could be used to pick a 4045 window size sufficient to keep the current session's pipe full. The 4046 constant 8 converts octets to bits (assuming ConnectRate is in bits 4047 per second). If ConnectRate is in bytes per second, omit the 8. 4048 LACFudge and LNSFudge are not required but can be used to take 4049 overall processing overhead of the LAC or LNS into account. 4051 In the case of the computed PPD for an LNS, AvePathRate is the 4052 average bit rate of the path between the LNS and LAC. Given that 4053 this number is probably very large and WindowSize is relatively 4054 small, LNSFudge will be the dominant factor in the computation of 4055 PPD. It is recommended that the minimum value of PPD be on the order 4056 of 0.5 second. 4058 The value of PPD is used to seed the adaptive algorithm with the 4059 initial RTT[n-1] value. 4061 A.1 Calculating Adaptive Acknowledgment Time-Out 4063 We still must decide how much time to allow for acknowledgments to 4064 return. If the time-out is set too high, we may wait an 4065 unnecessarily long time for dropped packets. If the time-out is too 4066 short, we may time out just before the acknowledgment arrives. The 4067 acknowledgment time-out should also be reasonable and responsive to 4068 changing network conditions. 4070 The suggested adaptive algorithm detailed below is based on the TCP 4071 1989 implementation and is explained in Richard Steven's book TCP/IP 4072 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 4073 calculation, and 'n-1' refers to values from the last calculation. 4075 DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta * 4076 (|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 4077 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 4079 DIFF represents the error between the last estimated round-trip 4080 time and the measured time. DIFF is calculated on each iteration. 4082 DEV is the estimated mean deviation. This approximates the 4083 standard deviation. DEV is calculated on each iteration and 4084 stored for use in the next iteration. Initially, it is set to 0. 4086 RTT is the estimated round-trip time of an average packet. RTT is 4087 calculated on each iteration and stored for use in the next 4088 iteration. Initially, it is set to PPD. 4090 ATO is the adaptive time-out for the next transmitted packet. ATO 4091 is calculated on each iteration. Its value is limited, by the MIN 4092 function, to be a maximum of the configured MaxTimeOut value. 4094 Alpha is the gain for the average and is typically 1/8 (0.125). 4096 Beta is the gain for the deviation and is typically 1/4 (0.250). 4098 Chi is the gain for the time-out and is typically set to 4. 4100 To eliminate division operations for fractional gain elements, the 4101 entire set of equations can be scaled. With the suggested gain 4102 constants, they should be scaled by 8 to eliminate all division. To 4103 simplify calculations, all gain values are kept to powers of two so 4104 that shift operations can be used in place of multiplication or 4105 division. The above calculations are carried out each time an 4106 acknowledgment is received for a packet that was not retransmitted 4107 (no time-out occurs). 4109 A.2 Congestion Control: Adjusting for Time-Out 4111 This section describes how the calculation of ATO is modified in the 4112 case where a time-out does occur. When a time-out occurs, the time- 4113 out value should be adjusted rapidly upward. Although L2TP payload 4114 packets are not retransmitted when a time-out occurs, the time-out 4115 should be adjusted up toward a maximum limit. To compensate for 4116 shifting internetwork time delays, a strategy must be employed to 4117 increase the time-out when it expires. A simple formula called 4118 Karn's Algorithm is used in TCP implementations and may be used in 4119 implementing the backoff timers for the LNS or the LAC. Notice that 4120 in addition to increasing the time-out, we also shrink the size of 4121 the window as described in the next section. 4123 Karn's timer backoff algorithm, as used in TCP, is: 4125 NewTIMEOUT = delta * TIMEOUT 4127 Adapted to our time-out calculations, for an interval in which a 4128 time-out occurs, the new time-out interval ATO is calculated as: 4130 RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MIN (RTT[n] + 4131 (chi * DEV[n]), MaxTimeOut) 4133 In this modified calculation of ATO, only the two values that 4134 contribute to ATO and that are stored for the next iteration are 4135 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 4136 not carried forward and is not used in this scenario. A value of 2 4137 for Delta, the time-out gain factor for RTT, is suggested. 4139 Appendix B: Acknowledgment Time-Out and Window Adjustment 4141 B.1 Initial Window Size 4143 Although each side has indicated the maximum size of its receive 4144 window, it is recommended that a slow start method be used to begin 4145 transmitting data. The initial window size on the transmitter is set 4146 to half the maximum size the receiver requested, with a minimum size 4147 of one packet. The transmitter stops sending packets when the number 4148 of packets awaiting acknowledgment is equal to the current window 4149 size. As the receiver successfully digests each window, the window 4150 size on the transmitter is bumped up by one packet until the maximum 4151 is reached. This method prevents a system from flooding an already 4152 congested network because no history has been established. 4154 When for any reason an LAC or LNS receives more data than it can 4155 queue for the tunnel, a packet must be discarded. In this case, it 4156 is recommended that a "random early discard" algorithm [6] be used 4157 rather than the obvious "drop last" algorithm. 4159 B.2 Closing the Window 4161 When a time-out does occur on a packet, the sender adjusts the size 4162 of the transmit window down to one half its value when it failed. 4163 Fractions are rounded up, and the minimum window size is one. 4165 B.3 Opening the Window 4167 With every successful transmission of a window's worth of packets 4168 without a time-out, the transmit window size is increased by one 4169 packet until it reaches the maximum window size that was sent by the 4170 other side when the call was connected. As stated earlier, no 4171 retransmission is done on a time-out. After a time-out, the 4172 transmission resumes with the window starting at one half the size of 4173 the transmit window when the time-out occurred and adjusting upward 4174 by one each time the transmit window is filled with packets that are 4175 all acknowledged without time-outs. 4177 B.4 Window Overflow 4179 When a receiver's window overflows with too many incoming packets, 4180 excess packets are thrown away. This situation should not arise if 4181 the sliding window procedures are being properly followed by the 4182 transmitter and receiver. It is assumed that, on the transmit side, 4183 packets are buffered for transmission and are no longer accepted from 4184 the packet source when the transmit buffer fills. 4186 Appendix C: Handling of out-of-order packets 4188 When the Sequence Number and Acknowledgment Number fields are present 4189 in payload packets, they are used to manage packet rate. In 4190 addition, they may be used to handle out-of-order arrival of packets. 4191 A simple L2TP client would simply discard any packet other than a 4192 packet with a sequence greater than that last received; if packets 1, 4193 2, 3 arrived as 1, 3, 2, this would result in packet 2 being 4194 discarded. 4196 Such behavior does not affect the L2TP protocol itself, but 4197 significantly improved throughput in such environments may be 4198 attained by queueing and reordering packets when they arrive out of 4199 order. The number of packets to be queued is a function of memory 4200 resources on the L2TP implementation, but should never be more than 4201 1/4 of the total sequence number space (i.e., 16384 packets), to 4202 avoid aliasing. 4204 An implementation which queues packets in this way must also employ 4205 an algorithm for deciding that a given sequence number corresponds to 4206 a packet which is lost, rather than one which is out of order but 4207 still in transit. Such a decision would likely be based upon timing, 4208 buffering conditions, and packet arrival characteristics. The 4209 details of such a tradeoff are outside the scope of this 4210 specification, but it is recommended a packet should be afforded an 4211 interval at least twice the estimated RTT from the L2TP peer. 4213 Appendix D: Transport Layer Adaptive Time-outs and Window Adjustment 4215 Appendixes A, B, and C dealt with operation of the payload packet 4216 sessions of L2TP. This Appendix explains how these three algorithms 4217 pertain to the transport layer for L2TP control sessions. Appendix B, 4218 Time-out Window Management, directly applies to the Transport Layer 4219 except in the case where a window size of 1 is being used. Appendix 4220 C, does not really apply because, for the Control Session, control 4221 messages MUST always be processed by the receiver in order. Also, 4222 there are no lost control packets because they are retransmitted by 4223 the L2TP Transport Layer. Thus, the main topic of this Appendix is 4224 how to adapt the example adaptive time-out algorithm of Appendix A to 4225 the Control Session Transport Layer. 4227 There are two main differences between the Control Session and 4228 payload sessions: 1) Unlike lost payload packets, lost control 4229 messages are retransmitted and 2) There is no Packet Processing Delay 4230 value provided in the control session setup messages. The latter 4231 affects the manner in which the initial value of the RTT estimate is 4232 determined. The former really doesn't affect the algorithm at all, 4233 except that upon a time-out, retransmission of unacknowledged control 4234 messages should be attempted, up to the number that fit in the 4235 sliding window with size computed as in Appendix B. 4237 Using the symbol definitions of Appendix A, the calculation of the 4238 value for the PPD of the remote peer can be estimated as: 4240 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4241 + Fudge 4243 This is simply the number of bits in a full control session window 4244 divided by the average speed of the path between the LAC and LNS with 4245 a fudge factor added on to make it work. In cases where the average 4246 rate of the connection between LAC and LNS isn't known, it is 4247 suggested that some value be configured that is associated with each 4248 possible peer. Because Control Session windows will most likely be 4249 small and the connection speed will be quite high, fudge will be the 4250 dominant factor in this calculation. For this reason, just 4251 configuring a single fixed initial PPD estimate to be used for all 4252 possible peers will probably provide adequate results. This fudge 4253 factor should probably be at least 0.5 second.