idnits 2.17.1 draft-ietf-pppext-l2tp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 66 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 67 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 41 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 139: '... o must, SHALL, or MANDATORY --...' RFC 2119 keyword, line 142: '... o SHOULD or RECOMMEND -- This ...' RFC 2119 keyword, line 145: '... o MAY or OPTIONAL -- This item...' RFC 2119 keyword, line 2897: '...nection- Request SHOULD be sent to the...' RFC 2119 keyword, line 2903: '...tion, the originator MUST send a Stop-...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3097 has weird spacing: '...or data est...' == Line 3104 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) -- Missing reference section? '1' on line 41 looks like a reference -- Missing reference section? 'H' on line 288 looks like a reference -- Missing reference section? 'R' on line 290 looks like a reference -- Missing reference section? 'U' on line 291 looks like a reference -- Missing reference section? 'L' on line 289 looks like a reference -- Missing reference section? 'N' on line 292 looks like a reference -- Missing reference section? 'Value' on line 577 looks like a reference -- Missing reference section? 'XXX' on line 3536 looks like a reference -- Missing reference section? '3' on line 3542 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group Kory Hamzeh 2 Request for Comments: DRAFT Ascend Communications 3 Category: Internet Draft Tim Kolar 4 Title: draft-ietf-pppext-l2tp-00.txt Cisco Systems 5 Date: August 1996 Morgan Littlewood 6 Cisco Systems 7 Gurdeep Singh Pall 8 Microsoft Corporation 9 Jeff Taarud 10 formerly of 3COM Corporation 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 doc- 21 uments of the Internet Engineering Task Force (IETF), its areas, and 22 its working groups. Note that other groups may also distribute work- 23 ing 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 ``work- 29 ing 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 Proto- 42 col (L2TP) which permits the tunneling of the link layer (i.e., HDLC, 43 async HDLC) of PPP. Using such tunnels, it is possible to divorce 44 the location of the initial dial-up server from the location at which 45 the dial-up protocol connection is terminated and access to the net- 46 work 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 General Error Codes 71 6.0 Control Connection Protocol Specification 72 6.1 Start-Control-Connection-Request 73 6.2 Start-Control-Connection-Reply 74 6.3 Start-Control-Connection-Connected 75 6.4 Stop-Control-Connection-Request 76 6.5 Stop-Control-Connection-Reply 77 6.6 Echo-Request 78 6.7 Echo-Reply 79 6.8 Outgoing-Call-Request 80 6.9 Outgoing-Call-Reply 81 6.10 Incoming-Call-Request 82 6.11 Incoming-Call-Reply 83 6.12 Incoming-Call-Connected 84 6.13 Call-Clear-Request 85 6.14 Call-Disconnect-Notify 86 6.15 WAN-Error-Notify 87 6.16 Set-Link-Info 88 6.17 No-op 89 7.0 Control Connection State Machines 90 7.1 Control Connection Protocol Operation 91 7.2 Control Connection States 92 7.2.1 Control Connection Originator (may be LAC or LNS) 93 7.2.2 Control connection Receiver (may be LAC or LNS) 94 7.3 Timing considerations 95 7.4 Incoming Calls 96 7.5 LNS Incoming Call States 97 7.6 Outgoing calls 98 7.7 LNS Outgoing Call States 99 8.0 L2TP Over Specific Media 100 8.1 IP/UDP 101 8.2 IP 102 9.0 Security Considerations 103 9.1 Tunnel Endpoint Security 104 9.2 Client Security 105 10.0 Acknowledgments 106 11.0 Contacts 107 12.0 References 108 Appendix A: Acknowledgment Time-Outs 109 Appendix B: Acknowledgment Time-Out and Window Adjustment 111 1.0 Introduction 113 The traditional dial-up network service on the Internet is for regis- 114 tered IP addresses only. A new class of virtual dial-up application 115 which allows multiple protocols and unregistered IP addresses is also 116 desired on the Internet. Examples of this class of network applica- 117 tion are support for privately addressed IP, IPX, and AppleTalk dial- 118 up via PPP across existing Internet infrastructure. 120 The support of these multiprotocol virtual dial-up applications is of 121 significant benefit to end users, enterprises, and Internet Service 122 providers as it allows the sharing of very large investments in 123 access and core infrastructure and allows local calls to be used. It 124 also allows existing investments in non-IP protocol applications to 125 be supported in a secure manner while still leveraging the access 126 infrastructure of the Internet. 128 It is the purpose of this draft to identify the issues encountered in 129 integrating multiprotocol dial-up services into an existing Internet 130 Service Provider's Point of Presence (hereafter referred to as ISP 131 and POP, respectively), and to describe the L2TP protocol which per- 132 mits the leveraging of existing access protocols. 134 1.1 Conventions 136 The following language conventions are used in the items of specifi- 137 cation in this document: 139 o must, SHALL, or MANDATORY -- This item is an absolute 140 requirement of the specification. 142 o SHOULD or RECOMMEND -- This item should generally be followed 143 for all but exceptional circumstances. 145 o MAY or OPTIONAL -- This item is truly optional and may be 146 followed or ignored according to the needs of the implementor. 148 1.2 Terminology 150 Analog Channel 152 A circuit-switched communication path which is intended to carry 153 3.1 Khz audio in each direction. 155 Digital Channel 157 A circuit-switched communication path which is intended to carry 158 digital information in each direction. 160 Call 161 A connection or attempted connection between two terminal end- 162 points on a PSTN or ISDN--for example, a telephone call between 163 two modems. 165 Control Messages 166 Control messages are exchanged between LAC, LNS pairs, and operate 167 in-band within the tunnel protocol. Control messages govern 168 aspects of the tunnel and sessions within the tunnel. 170 Dial User 172 An end-system or router attached to an on-demand PSTN or ISDN 173 which is either the initiator or recipient of a call. 175 L2TP Access Concentrator (LAC) 177 A device attached to one or more PSTN or ISDN lines capable of PPP 178 operation and of handling the L2TP protocol. The LAC needs only 179 implement the media over which L2TP is to operate to pass traffic 180 to one or more LNS's. It may tunnel any protocol carried within 181 PPP. 183 L2TP Network Server (LNS) 185 An LNS operates on any platform capable of PPP termination. The 186 LNS handles the server side of the L2TP protocol. Since L2TP 187 relies only on the single media over which L2TP tunnels arrive, 188 the LNS may have only a single LAN or WAN interface, yet still be 189 able to terminate calls arriving at any LAC's full range of PPP 190 interfaces (async, synchronous ISDN, V.120, etc.). 192 Network Access Server (NAS) 194 A device providing temporary, on-demand network access to users. 195 This access is point-to-point using PSTN or ISDN lines. 197 Session 199 L2TP is connection-oriented. The LNS and LAC maintain state for 200 each user that is attached to a LAC. A session is created when 201 end-to-end PPP connection is attempted between a dial user and the 202 LNS, or when a outbound call is initiated. The datagrams related 203 to a session are sent over the tunnel between the LAC and LNS. 205 Quality of Service (QOS) 207 A given Quality of Service level is sometimes required for a given 208 user being tunneled between a LNS-LAC pair. For this scenario, a 209 unique L2TP tunnel is created (generally on top of a new SVC) and 210 encapsulated directly on top of the media providing the indicated 211 QOS. 213 Switched Virtual Circuit (SVC) 214 An L2TP-compatible media on top of which L2TP is directly encapsu- 215 lated. SVC's are dynamically created, permitting tunnel media to 216 be created dynamically in response to desired LNS-LAC connectivity 217 requirements. 219 Tunnel 221 A tunnel is defined by a LNS-LAC pair. The tunnel carries PPP 222 datagrams between the LAC and the LNS; many sessions can be multi- 223 plexed over a single tunnel. A control connection operating in- 224 band over the same tunnel controls the establishment, release, and 225 maintenance of sessions and of the tunnel itself. 227 2.0 Problem Space Overview 229 In this section we describe in high level terms the scope of the 230 problem that will be explored in more detail in later sections. 232 2.1 Initial Assumptions 234 We begin by assuming that Internet access is provided by an ISP and 235 that the ISP wishes to offer services other than traditional regis- 236 tered IP address based services to dial-up users of the network. 238 We also assume that the user of such a service wants all of the secu- 239 rity facilities that are available to him in a dedicated dial-up con- 240 figuration. In particular, the end user requires: 242 + End System transparency: Neither the remote end system nor his home 243 site hosts should require any special software to use this service in 244 a secure manner. 246 + Authentication as provided via dial-up PPP CHAP or PAP, or through 247 other dialogs, for instance, a textual exchange on V.120 before 248 starting PPP. This will include TACACS+ and RADIUS solutions as well 249 as support for smart cards and one-time passwords. The authentica- 250 tion should be manageable by the user independently of the ISP. 252 + Addressing should be as manageable as dedicated dial-up solutions. 253 The address should be assigned by the home site and not the ISP. 255 + Authorization should be managed by the home site as it would in a 256 direct dial-up solution. 258 + Accounting should be performed both by the ISP (for billing pur- 259 poses) and by the user (for charge-back and auditing). 261 2.2 Topology 263 Shown below is a generic Internet with Public switched Telephone Net- 264 work (PSTN) access (i.e., async PPP via modems) and Integrated Ser- 265 vices Digital Network (ISDN) access (i.e., synchronous PPP access). 266 Remote users (either async or ISDN PPP) will access the Home LAN as 267 if they were dialed into the L2TP Network Server (LNS), although 268 their physical dial-up is via the ISP Network Access Server. 270 ...----[L]----+---[L]-----... 271 | 272 | 273 [H] 274 | 275 ________|________________________ 276 | | 277 ________|__ ______|________ 278 | | | | 279 | PSTN [R] [R] ISDN | 280 | Cloud | | Cloud [N]__[U] 281 | | Internet | | 282 | | [R] | 283 [N]______[R] |_____________| 284 | | | 285 | | | 286 [U] |________________________________| 288 [H] = LNS 289 [L] = Home LAN(s) 290 [R] = Router 291 [U] = Remote User 292 [N] = ISP Network Access Server 294 2.3 Providing Virtual dial-up Services--a walk-through 296 To motivate the following discussion, this section walks through an 297 example of what might happen when a Virtual dial-up client initiates 298 access. 300 The Remote User initiates a PPP connection to an ISP via either the 301 PSTN or ISDN. The Network Access Server (NAS) accepts the connection 302 and the PPP link is established. 304 The ISP undertakes a partial authentication of the end system/user 305 via CHAP or PAP. Only the username field is interpreted to determine 306 whether the user requires a Virtual dial-up service. It is 307 expected--but not required--that usernames will be structured (e.g. 308 jawadk@microsoft.com). Alternatively, the ISP may maintain a 309 database mapping users to services. In the case of Virtual dial-up, 310 the mapping will name a specific endpoint, the LNS. 312 If a virtual dial-up service is not required, standard access to the 313 Internet may be provided. 315 If no tunnel connection currently exists to the desired LNS, one is 316 initiated. L2TP is designed to be largely insulated from the details 317 of the media over which the tunnel is established; L2TP requires only 318 that the tunnel media provide packet oriented point-to-point 319 connectivity. Obvious examples of such media are UDP, Frame Relay 320 PVC's, or X.25 VC's. 322 Once the tunnel exists, an unused slot within the tunnel, a "Call 323 ID", is allocated, and a connect indication is sent to notify the LNS 324 of this new dial-up session. The LNS either accepts the connection, 325 or rejects. Rejection may include a reason indication, which may be 326 displayed to the dial-up user, after which the call should be discon- 327 nected. 329 The initial setup notification may include the authentication infor- 330 mation required to allow the LNS to authenticate the user and decide 331 to accept or decline the connection. In the case of CHAP, the set-up 332 packet includes the challenge, username and raw response. For PAP or 333 text dialog, it includes username and clear text password. The LNS 334 may choose to use this information to complete its authentication, 335 avoiding an additional cycle of authentication. 337 The initial setup notification may also include a copy of the the LCP 338 CONFACKs sent in each direction which completed LCP negotiation. The 339 LNS may use this information to initialize its own PPP state (thus 340 avoiding an additional LCP negotiation), or it may choose to initiate 341 a new LCP CONFREQ exchange. 343 If the LNS accepts the connection, it creates a "virtual interface" 344 for PPP in a manner analogous to what it would use for a direct- 345 dialed connection. With this "virtual interface" in place, link 346 layer frames may now pass over this tunnel in both directions. 347 Frames from the remote user are received at the POP, stripped of any 348 link framing or transparency bytes, encapsulated in L2TP, and for- 349 warded over the appropriate tunnel. 351 The LNS accepts these frames, strips L2TP, and processes them as nor- 352 mal incoming frames for the appropriate interface and protocol. The 353 "virtual interface" behaves very much like a hardware interface, with 354 the exception that the hardware in this case is physically located at 355 the ISP POP. The other direction behaves analogously, with the LNS 356 encapsulating the packet in L2TP, and the NAS stripping L2TP before 357 transmitting it out the physical interface to the remote user. For 358 the remainder of this document, a NAS operating as a peer to an LNS 359 will be referred to as an L2TP Access Concentrator, or "LAC". 361 At this point, the connectivity is a point-to-point PPP session whose 362 endpoints are the remote user's networking application on one end and 363 the termination of this connectivity into the LNS's PPP support on 364 the other. Because the remote user has become simply another dial-up 365 client of the LNS, client connectivity can now be managed using tra- 366 ditional mechanisms with respect to further authorization, protocol 367 access, and filtering. 369 Accounting can be performed at both the LAC as well as the LNS. This 370 document illustrates some Accounting techniques which are possible 371 using L2TP, but the policies surrounding such Accounting are outside 372 the scope of this specification. 374 L2TP offers optional facilities which maximize compatibility with 375 legacy client requirements, L2TP connect notifications for PPP 376 clients can contain sufficient information for a LNS to authenticate 377 and initialize its LCP state machine. With these facilities, the the 378 remote user need not be queried a second time for CHAP authentica- 379 tion, nor undergo multiple rounds of LCP negotiation and convergence. 380 These techniques are intended to optimize connection setup, and are 381 not intended to deprecate any functions required by the PPP specifi- 382 cation. 384 3.0 Service Model Issues 386 There are several significant differences between the standard Inter- 387 net access service and the Virtual dial-up service with respect to 388 authentication, address allocation, authorization and accounting. 389 The details of the differences between these services and the prob- 390 lems presented by these differences are described below. The mecha- 391 nisms used for Virtual Dial-up service are intended to coexist with 392 more traditional mechanisms; it is intended that an ISP's POP can 393 simultaneously service ISP clients as well as Virtual dial-up 394 clients. 396 3.1 Security 398 For the Virtual dial-up service, the ISP pursues authentication only 399 to the extent required to discover the user's apparent identity (and 400 by implication, their desired LNS). This may involve no more than 401 detecting DNIS information when a call arrives, or may involve full 402 LCP negotation and initiation of CHAP. As soon as the apparent iden- 403 tity is determined, a connection to the LNS is initiated with any 404 authentication information gathered by the ISP. The LNS completes 405 the authentication by either accepting the connection, or rejecting 406 it. 408 The LNS may need to protect against attempts by third parties to 409 establish tunnels to the LNS. Tunnel establishment can include 410 authentication to protect against such attacks. 412 3.2 Address Allocation 414 For an Internet service, the user accepts that the IP address may be 415 allocated dynamically from a pool of ISP addresses. This model often 416 means that the remote user has little or no access to their home net- 417 work's resources, due to firewalls and other security policies 418 applied by the home network to accesses from external IP addresses. 420 For the Virtual dial-up service, the LNS can exist behind the home 421 firewall, allocating addresses which are internal (and, in fact, can 422 be RFC1597 addresses, or non-IP addresses). Because L2TP tunnels 423 exclusively at the frame layer, the actual policies of such address 424 management are irrelevant to correct Virtual dial-up service; for all 425 purposes of PPP protocol handling, the dial-in user appears to have 426 connected at the LNS. 428 3.3 Authentication 430 The authentication of the user occurs in three phases; the first at 431 the ISP, and the second and optional third at the LNS. 433 The ISP uses the username to determine that a Virtual dial-up service 434 is required and initiate the tunnel connection to the appropriate 435 LNS. Once a tunnel is established, a new Call ID is allocated and a 436 session initiated by forwarding the gathered authentication informa- 437 tion. 439 The LNS undertakes the second phase by deciding whether or not to 440 accept the connection. The connection indication may include CHAP, 441 PAP, or textual authentication information. Based on this informa- 442 tion, the LNS may accept the connection, or may reject it (for 443 instance, it was a PAP request and the username/password are found to 444 be incorrect). 446 Once the connection is accepted, the LNS is free to pursue a third 447 phase of authentication at the PPP layer. These activities are out- 448 side the scope of this specification, but might include an additional 449 cycle of LCP authentication, proprietary PPP extensions, or textual 450 challenges carried via a TCP/IP telnet session. 452 3.4 Accounting 454 It is a requirement that both the LAC and the LNS can provide 455 accounting data and hence both may count packets, octets and connec- 456 tion start and stop times. 458 Since Virtual dial-up is an access service, accounting of connection 459 attempts (in particular, failed connection attempts) is of signifi- 460 cant interest. The LNS can reject new connections based on the 461 authentication information gathered by the LAC, with corresponding 462 logging. For cases where the LNS accepts the connection and then 463 continues with further authentication, the LNS might subsequently 464 disconnect the client. For such scenarios, the disconnection indica- 465 tion back to the LAC may also include a reason. 467 Because the LNS can decline a connection based on the authentication 468 information collected by the LAC, accounting can easily draw a dis- 469 tinction between a series of failed connection attempts and a series 470 of brief successful connections. Lacking this facility, the LNS must 471 always accept connection requests, and would need to exchange a num- 472 ber of PPP packets with the remote system. Note that the LNS could 473 use this information to decide to accept the connection (which pro- 474 tects against most third-party connection attempts) while still 475 insisting on running its own CHAP authentication (to protect against 476 CHAP replay attacks). 478 4.0 Protocol Overview 480 There are two parallel components of L2TP operating over a given tun- 481 nel: 1) control messages between each LAC-LNS pair, and 2) payload 482 packets between the same LAC-LNS pair which are used to transport 483 L2TP encapsulated PPP packets for user sessions between the pair. 485 4.1 Control Message Overview 487 Before PPP tunneling can occur between a LAC and LNS, control mes- 488 sages must be exchanged between them. Control messages are 489 exchanged over the same tunnel which will be used to forward pay- 490 load data once L2TP call control and management information have 491 been passed. The control messages are responsible for establish- 492 ment, management, and release of sessions carried through the tun- 493 nel, as well as status on the tunnel itself. It is the means by 494 which a LNS is notified of an incoming call at an associated LAC, 495 as well as the means by which a LAC is instructed to place an out- 496 going dial call. 498 A tunnel may be established by either a LAC (for incoming calls) 499 or an LNS (for outgoing calls). Following the establishment of 500 the tunnel, the LNS and LAC configure the tunnel by exchanging 501 Start-Control-Connection-Request and -Reply messages. These mes- 502 sages are also used to exchange information about basic operating 503 capabilities of the LAC and LNS. Once the control message 504 exchange is complete, the LAC may initiate sessions by indicating 505 inbound requests, or the LNS by requesting outbound calls. Con- 506 trol messages may indicate changes in operating characteristics of 507 an individual user session with a Set- Link-Info message. Indi- 508 vidual sessions may be released by either the LAC or LNS, also 509 through control messages. 511 The tunnel itself is maintained by exchanging keepalive control 512 echo messages. This ensures that a connectivity failure between 513 the LNS and the LAC can be detected in a timely manner. Other 514 failures can be reported via the Wan-Error-Notify control message. 516 It is intended that control messages will also carry management 517 related information in the future, such as a message allowing the 518 LNS to request the status of a given LAC; these message types have 519 not yet been defined. 521 4.2 Payload Packet Overview 523 Once a tunnel is established and control messages have completed 524 tunnel setup, the tunnel can be used to carry user session PPP 525 packets for sessions involving a given LNS-LAC pair. A key in the 526 tunnel header indicates to which session a particular PPP packet 527 belongs. In this manner, PPP packets are multiplexed and demulti- 528 plexed over a single tunnel between a given LNS-LAC pair. The key 529 field value is established by the call establishment control mes- 530 sages. 532 It is legal for multiple tunnels to exist between a given LNS-LAC 533 pair. This is useful where each tunnel is used for a single user, 534 and the tunnel media (an SVC, for instance) has specific QOS 535 attributes dedicated to a given user. L2TP provides a tunnel 536 identifier so that individual tunnels can be identified, even when 537 arriving from a single source LAC or LNS. 539 The L2TP header also contains optional acknowledgment and sequenc- 540 ing information that can be used to perform congestion control 541 over the tunnel. Control messages are used to determine rate and 542 buffering parameters that are used to regulate the flow of PPP 543 packets for a particular session over the tunnel. L2TP does not 544 specify the particular algorithms to use for congestion and flow 545 control. Suggested algorithms for the determination of adaptive 546 time-outs to recover from dropped data or acknowledgments on the 547 tunnel are included in Appendix A of this document. 549 5. Message Format and Protocol Extensibility 551 L2TP defines a set of control messages sent in packets over the tun- 552 nel between a LNS and a given LAC. The exact technique for initiat- 553 ing a tunnel between a LNS-LAC pair is specific to the tunnel media, 554 and supported media are described in section 8.0. 556 Once media-level connectivity is reached, L2TP message formats define 557 the protocol for a LAC and LNS to manage the tunnel and its associ- 558 ated sessions. 560 In each case where a field is optional, if the field is not present, 561 its space does not exist in the packet. Existing fields are placed 562 back-to-back to form the packet. 564 5.1 AVP 566 To maximize extensibility while still permitting interoperability, 567 a uniform method for encoding message types and bodies is used 568 throughout L2TP. This encoding will be termed an AVP (Attribute- 569 Value Pair) in the remainder of this document. Each AVP is 570 encoded as: 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Overall Length | Vendor ID | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Attribute |0|0|0|0|0|0|0|M| [Value]... | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | [until Overall length reached]... | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Overall Length encodes the number of octets (including the Overall 583 Length field itself) contained in this AVP. 585 Vendor ID is the IANA assigned "SMI Network Management Private 586 Enterprise Codes" value, encoded in network byte order. The value 587 0, reserved in this table, corresponds to IETF adopted Attribute 588 values, defined within this document. Any vendor wishing to 589 implement L2TP extensions can use their own Vendor ID along with 590 private Attribute values, guaranteeing that they will not collide 591 with any other vendor's extensions, nor with future IETF exten- 592 sions. 594 Attribute is the actual attribute, a 16-bit value with a unique 595 interpretation under a given Vendor ID. 597 The next octet is a bit mask, describing the general attributes of 598 the AVP. Only one bit value, M, is defined. This bit, known as 599 the "mandatory" bit, controls the behavior required of an imple- 600 mentation which receives an AVP which it does not recognize. If M 601 is set, any session associated with this AVP must be terminated. 602 If the AVP is associated with the overall tunnel, the entire tun- 603 nel (and all sessions within) must be terminated. If M is not 604 set, an unrecognized AVP should be ignored. 606 Value follows immediately after the Flags field, and runs for the 607 remaining octets indicated in the Overall Length (i.e., Overall 608 Length minus seven octets of header). If desired, a given AVP can 609 define the first octet of the Value to be a pad, permitting actual 610 data to be aligned on a 32-bit boundary. 612 AVP's should be kept compact; in no case should AVP's ever cause a 613 control message's total length to exceed 1532 bytes in length. 615 5.2 Control Message Format 617 Each L2TP control message begins with a 20 octet fixed header por- 618 tion and at least one AVP indicating message type. This fixed 619 header is formatted: 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 |T|1|1|1|1|K| | Ver | Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Magic Cookie | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Tunnel ID | Call ID | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Sequence Number | Acknowledgment Number | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Key (opt) | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Message Type AVP | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 The T bit must be 1, indicating a control message. The next four 638 bits must be set to 1, making the header more compatible in encod- 639 ing with the payload message (defined in the next section). The K 640 bit is optional, documented below. 642 Ver must be the value 002, indicating a version 1 L2TP message 643 (values 000 and 001 are reserved to permit detection of L2F [XXX], 644 GRE [XXX], and PPTP [XXX] packets if they arrive intermixed). 646 Length is the overall length of the message, including header, 647 message type AVP, plus any additional AVP's associated with a 648 given control message type. 650 Magic Cookie is always present, and has the value 0x1A2B3C4E. Its 651 purpose is to allow the receiver to ensure that it is synchronized 652 with the data stream. It should not be used as a means for resyn- 653 chronizing the data stream in the event that a transmitter issues 654 an improperly formatted message. Loss of synchronization must 655 result in immediate closing of the session. 657 Tunnel ID and Call ID identify the tunnel and caller within the 658 tunnel to which a control message applies. If a control message 659 does not apply to a single caller within the tunnel (for instance, 660 a Stop-Control-Connection-Request message), Call ID should be set 661 to 0. 663 Sequence Number and Acknowledgment Number reflect the currently 664 transmitted packet and latest received packet respectively. 666 If the K bit is set, the Key field is present. The K bit must be 667 set if a Challenge value was received during tunnel setup, and the 668 Key reflects the challenge response of this authentication, with 669 the resulting MD5 hash value broken into successive 32-bit fields 670 which are XOR'ed together and this value put in the Key field. 672 The body of a control message is an AVP indicating the type of 673 control message. Depending on the particular control message, 674 further AVPs may follow. 676 5.3 Payload Message Format 678 PPP payload packets tunneled within L2TP have a smaller encapsula- 679 tion, reducing overhead of L2TP during the life of a tunneled PPP 680 session. The MTU for the user data packets encapsulated in L2TP 681 is 1532 octets, not including L2TP and media encapsulation. The 682 smallest L2TP encapsulation is 2 octets; the largest is 12 octets. 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 |T|L|I|C|F|K| | Ver | Length (opt) | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Tunnel ID (opt) | Call ID (opt) | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Sequence Number (opt) | Acknowledgment Number (opt) | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Key (opt) | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 The T bit must be 0, indicating payload. 698 Ver must be 002, indicating version 1 of the L2TP protocol. 700 If the L bit is set, the Length field is present, indicating the 701 total length of the received packet. 703 If the I bit is set, the Tunnel ID field is present. This is used 704 to demultiplex multiple tunnels over a single media, where the 705 media may not provide sufficient or efficient demultiplexing con- 706 text. 708 If the C bit is set, the Call ID field is present. This is used 709 to multiplex multiple clients within one tunnel. 711 If the F bit is set, both Sequence Number and Acknowledgment Num- 712 ber are present. Sequence Number indicates the sequence number of 713 the next packet to be sent. The current packet will be this 714 sequence number if the payload size is non-zero, otherwise this 715 packet is only an acknowledgement (sequence number does not 716 advance). Acknowledgment Number indicates the latest packet 717 sequence number last received. Together, these fields can be used 718 to handle out-of-order packets, and to provide flow control for 719 the connection. 721 If the K bit is set, the Key field is present. Refer to the 722 description in 5.2. 724 5.4 Control Message Types 726 Control message types defined in this specification exist under 727 Vendor ID 0, indicating IETF defined behavior. The actual message 728 semantics are defined in the next section. The currently defined 729 control messages types, grouped by function, are: 731 Control Message Message Code 733 (Control Connection Management) 735 Start-Control-Connection-Request 1 736 Start-Control-Connection-Reply 2 737 Start-Control-Connection-Connected 17 738 Stop-Control-Connection-Request 3 739 Stop-Control-Connection-Reply 4 740 Echo-Request 5 741 Echo-Reply 6 743 (Call Management) 745 Outgoing-Call-Request 7 746 Outgoing-Call-Reply 8 747 Incoming-Call-Request 9 748 Incoming-Call-Reply 10 749 Incoming-Call-Connected 11 750 Call-Clear-Request 12 751 Call-Disconnect-Notify 13 752 No-op 16 754 (Error Reporting) 756 WAN-Error-Notify 14 758 (PPP Session Control) 759 Set-Link-Info 15 761 5.5 General Error Codes 763 General error codes pertain to types of errors which are not spe- 764 cific to any particular L2TP request, but rather to protocol or 765 message format errors. If a L2TP reply indicates in its Result 766 Code that a general error occurred, the General Error value should 767 be examined to determined what the error was. The currently 768 defined General Error codes and their meanings are: 770 0 - No general error 771 1 - No control connection exists yet for this LAC-LNS pair 772 2 - Length is wrong or Magic Cookie value is incorrect 773 3 - One of the field values was out of range or 774 reserved field was non-zero 775 4 - Insufficient resources to handle this command now 776 5 - The Call ID is invalid in this contex 777 6 - A generic vendor-specific error occurred in the LAC 779 6.0 Control Connection Protocol Specification 781 Control Connection messages are used to establish and clear user ses- 782 sions. The first set of Control Connection messages are used to 783 maintain the control connection itself. The control connection is 784 initiated by a LAC or LNS after establishing the underlying tunnel- 785 over-media connection. 787 6.0.1 Control Connection Collision 789 For the case where an LAC and LNS both initiate tunnels to each 790 other concurrently, and where the LAC and LNS both determine that 791 a single tunnel suffices (generally because of media characteris- 792 tic considerations, for instance, whether individual tunnels are 793 needed to gain QOS guarantees for each tunnel), a "tie breaker" 794 may be undertaken. The details of breaking a tie are documented 795 with the tunnel establishment messages. 797 6.0.2 Reliable Delivery of Control Messages 799 Since L2TP may run across media where packets may be lost, L2TP 800 may need to retransmit a control message after detecting that the 801 peer never received it. Each tunnel maintains Sequence and 802 Acknowledgment values for the control channel, which are global 803 across the tunnel. When a control message is sent, it is assigned 804 the current Sequence number, and the Sequence counter is 805 incremented (wrapping from its maximum 16-bit value to 0). The 806 Acknowledgment field of a control message always reflects the 807 highest in-order Sequence number received from the peer. 809 Each tunnel maintains a queue of control messages to be transmit- 810 ted to the peer. The message at the front of the queue is sent 811 with a given sequence number, and is held until a control message 812 arrives from the peer in which the Acknowledgment field indicates 813 receipt of this message. After a timeout interval (a recommended 814 default is one second, but this may be altered based on media con- 815 siderations), the packet is retransmitted. The retransmitted 816 packet holds the same Sequence number, but the Acknowledgment 817 value should be updated to reflect any packet received in the 818 interim. 820 If no peer response is detected after several retransmissions (a 821 recommended default is 5, but again may be altered due to media 822 considerations), the tunnel and all sessions within should be 823 cleared. 825 The default is to have a single control message outstanding on a 826 given. If a peer specifies a control message window in the Start- 827 Control-Connection-Request and -Reply packets, up to the indicated 828 number of control messages may be sent and held outstanding. 830 6.0.3 Control Message Format 832 The following Control Connection messages are all sent as packets 833 on the established tunnel connection between a given LNS-LAC pair. 834 All data is sent in network order (high order octets first). Any 835 "reserved" or "empty" fields must be sent as 0 values to allow for 836 protocol extensibility. 838 Each control message has a header, specified in section 5.2, 839 including an AVP indicating the type of control message, followed 840 by zero or more AVP's appropriate for the given type of control 841 message. Each control message is described first at a block 842 level, and then with details of each AVP. 844 6.1 Start-Control-Connection-Request 846 The Start-Control-Connection-Request is a L2TP control message used 847 to initialize the tunnel between a LNS and a LAC. The tunnel must be 848 initialized through the exchange of these control messages before any 849 other L2TP messages can be issued. The establishment of the control 850 connection is started by the initiator of the underlying tunnel. The 851 message is structured as: 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | L2TP Control Message Header | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Start-Control-Connection-Request | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Protocol Version | 859 | Framing Capabilities | 860 | Bearer Capabilities | 861 | Tie Breaker | 862 | Firmware Revision | 863 | Host Name | 864 | Vendor Name | 865 | Assigned Tunnel ID | 866 | Control Message Window| 867 | Challenge | 868 +-+-+-+-+-+-+-+-+-+-+-+-+ 870 Start-Control-Connection-Request AVP 872 0 1 2 3 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | 7 | 0 | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | 1 |0 0 0 0 0 0 0 1| 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 The Start-Control-Connection-Request AVP encodes a request to an 881 LNS to receive a tunneled PPP session from an LAC. The Attribute 882 field is 1, indicating Start-Control-Connection-Request. The 883 Flags indicate a mandatory option. Details associated with this 884 tunneled session follow in additional AVP's within the packet. 886 Protocol Version 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | 9 | 0 | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | 1 |0 0 0 0 0 0 0 1| 0x01 | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | 0x00 | 896 +-+-+-+-+-+-+-+-+ 898 The Protocol Version AVP within a Start-Control-Connection-Request 899 packet indicates the L2TP protocol version available. The 900 Attribute value is 1, indicating Protocol Version, and the Value 901 field is a 16-bit hexadecimal value 0x100, indicating L2TP proto- 902 col version 1, revision 0. This AVP must be present. 904 Framing Capabilities 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | 11 | 0 | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | 2 |0 0 0 0 0 0 0 1| 0x00 | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | 0x00 | 0x00 |0|0|0|0|0|0|S|A| 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 The Framing Capabilities AVP within a Start-Control-Connection- 917 Request indicates the type of framing that the sender of this mes- 918 sage can provide. The Attribute is 2, it is a mandatory AVP, the 919 Value field is a 32-bit quantity, with two bits defined. If bit A 920 is set, asynchronous framing is supported. If bit S is set, syn- 921 chronous framing is supported. This AVP must be present. 923 Bearer Capabilities 925 0 1 2 3 926 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 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | 11 | 0 | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | 3 |0 0 0 0 0 0 0 1| 0x00 | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | 0x00 | 0x00 |0|0|0|0|0|0|D|A| 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 The Bearer Capabilities AVP within a Start-Control-Connection- 936 Request indicates the bearer capabilities that the sender of this 937 message can provide. The Attribute is 3, it is a mandatory AVP, 938 the Value field is a 32-bit quantity with two bits defined. If 939 bit A is set, analog access is supported. If bit D is set, digi- 940 tal access is supported. This AVP must be present. 942 Tie Breaker 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | 15 | 0 | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | 4 |0 0 0 0 0 0 0 0| Tie Break... | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Value... | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | ...(64 bits) | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 The Tie Breaker AVP within a Start-Control-Connection-Request con- 957 tains a 64-bit Value used to break ties in tunnel establishment 958 between a LAC-LNS pair. It is encoded as the Attribute 4, not 959 mandatory, with the indicated number of bytes representing the 960 vendor string. This AVP is optional. 962 If present, it indicates the sender wishes a single tunnel to 963 exist betweeen the given LAC-LNS pair, and this value will be used 964 decide on a single tunnel where both LAC and LNS initiate a tunnel 965 concurrently. The recipient of a Start-Control-Connection-Request 966 must check to see if a Start-Control-Connection-Request has been 967 sent to the peer, and if so, must compare its Tie Breaker value 968 with the received one. The lower value "wins", and the "loser" 969 must initiate a tunnel disconnect for their outstanding tunnel. 971 If a tie breaker is received, and the outstanding Start-Control- 972 Connection-Request had no tie breaker value, the initiator which 973 included the Tie Breaker AVP "wins". 975 It is recommended that the Value be set to the MAC address of a 976 LAN interface on the sender. If no MAC address is available, a 977 64-bit random number should be used instead. 979 Firmware Revision 981 0 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | 9 | 0 | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | 5 |0 0 0 0 0 0 0 0| Max (H) | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Max (L) | 989 +-+-+-+-+-+-+-+-+ 991 The Firmware Revision AVP within a Start-Control-Connection- 992 Request indicates the firmware revision of the issuing device. 993 The Attribute is 5, it is not a mandatory AVP, the Value field is 994 a 16-bit integer encoded in a vendor specific format. For devices 995 which do not have a firmware revision (general purpose computers 996 running L2TP software modules, for instance), the revision of the 997 L2TP software module may be reported instead. This AVP is 998 optional. 1000 Host Name 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | 7 + length of host name | 0 | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | 6 |0 0 0 0 0 0 0 0|Host name... | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 The Host Name AVP within a Start-Control-Connection-Request indi- 1011 cates the DNS name of the issuing LAC or LNS. It is encoded as 1012 the Attribute 6, not mandatory, with the indicated number of bytes 1013 representing the host name string. This AVP is optional. 1015 Vendor Name 1017 0 1 2 3 1018 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 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | (7 + vendor length) | 0 | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | 7 |0 0 0 0 0 0 0 0|Vendor name... | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 The Vendor Name AVP within a Start-Control-Connection-Request con- 1026 tains a vendor specific string describing the type of LAC or LNS 1027 being used. It is encoded as the Attribute 7, not mandatory, with 1028 the indicated number of bytes representing the vendor string. 1029 This AVP is optional. 1031 Assigned Tunnel ID 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | 9 | 0 | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | 8 |0 0 0 0 0 0 0 1| ID (H) | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | ID (L) | 1041 +-+-+-+-+-+-+-+-+ 1043 The Assigned Tunnel ID AVP within a Start-Control-Connection- 1044 Request specifies the Tunnel ID which the peer should use in all 1045 subsequent packets. Before the Assigned Tunnel ID is received, 1046 packets should be sent with a Tunnel ID value of 0. It is encoded 1047 as the Attribute 8, mandatory, with the two bytes encoded as a 1048 16-bit non-zero Tunnel ID value. This AVP must be present. 1050 Control Message Window 1052 0 1 2 3 1053 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 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | 8 | 0 | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | 9 |0 0 0 0 0 0 0 0| Window | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 The Control Message Window AVP within a Start-Control-Connection- 1061 Request specifies the number of control messages which may be 1062 received without waiting for an acknowledgment. It is encoded as 1063 the Attribute 9, not mandatory, with a single octet indicating the 1064 number of such messages. If absent, the peer must use a value of 1065 1 for the Window. 1067 Challenge 1069 0 1 2 3 1070 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 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | 7 + length of challenge | 0 | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | 10 |0 0 0 0 0 0 0 1| Challenge... | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 |Challenge... | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 The Challenge AVP within a Start-Control-Connection-Request indi- 1080 cates that the peer wishes to authenticate the tunnel endpoints. 1081 It is encoded as the Attribute 10, mandatory, with at least one 1082 byte of challenge value embedded. 1084 6.2 Start-Control-Connection-Reply 1086 The Start-Control-Connection-Reply is an L2TP control message sent in 1087 reply to a received Start-Control-Connection-Request message. This 1088 message contains a result code indicating the result of the control 1089 connection establishment attempt. The message is structured as: 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | L2TP Control Message Header | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Start-Control-Connection-Reply | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Protocol Version | 1097 | Result Code | 1098 | Error Code | 1099 | Framing Capabilities | 1100 | Bearer Capabilities | 1101 | Firmware Revision | 1102 | Host Name | 1103 | Vendor Name | 1104 | Assigned Tunnel ID | 1105 | Control Message Window| 1106 | Challenge | 1107 | Response | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+ 1110 Start-Control-Connection-Reply AVP 1112 0 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | 7 | 0 | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | 2 |0 0 0 0 0 0 0 1| 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 The Attribute field is 2, indicating Start-Control-Connection- 1121 Reply. The Flags indicate a mandatory option. 1123 Protocol Version 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | 9 | 0 | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | 1 |0 0 0 0 0 0 0 1| 0x01 | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | 0x00 | 1133 +-+-+-+-+-+-+-+-+ 1135 The Protocol Version AVP within a Start-Control-Connection-Reply 1136 packet indicates the L2TP protocol version available. The 1137 Attribute value is 1, indicating Protocol Version, and the Value 1138 field is a 16-bit hexadecimal value 0x100, indicating L2TP proto- 1139 col version 1, revision 0. This AVP must be present. 1141 Framing Capabilities 1143 0 1 2 3 1144 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 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | 9 | 0 | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | 2 |0 0 0 0 0 0 0 1| 0x00 | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | 0x00 | 0x00 | 0x00 |S|A| 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 The Framing Capabilities AVP within a Start-Control-Connection- 1154 Reply indicates the type of framing that the sender of this mes- 1155 sage can provide. The Attribute is 2, it is a mandatory AVP, the 1156 Value field is a 32-bit quantity, with two bits defined. If bit A 1157 is set, asynchronous framing is supported. If bit S is set, syn- 1158 chronous framing is supported. This AVP must be present. 1160 Bearer Capabilities 1162 0 1 2 3 1163 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 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | 9 | 0 | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | 3 |0 0 0 0 0 0 0 1| 0x00 | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | 0x00 | 0x00 | |D|A| 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 The Bearer Capabilities AVP within a Start-Control-Connection- 1173 Reply indicates the bearer capabilities that the sender of this 1174 message can provide. The Attribute is 3, it is a mandatory AVP, 1175 the Value field is a 32-bit quantity with two bits defined. If 1176 bit A is set, analog access is supported. If bit D is set, digi- 1177 tal access is supported. This AVP must be present. 1179 Firmware Revision 1181 0 1 2 3 1182 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 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | 9 | 0 | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | 4 |0 0 0 0 0 0 0 0| Max (H) | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | Max (L) | 1190 +-+-+-+-+-+-+-+-+ 1192 The Firmware Revision AVP within a Start-Control-Connection-Reply 1193 indicates the firmware revision of the issuing device. The 1194 Attribute is 4, it is not a mandatory AVP, the Value field is a 1195 16-bit integer encoded in a vendor specific format. For devices 1196 which do not have a firmware revision (general purposes computers 1197 running L2TP software modules, for instance), the revision of the 1198 L2TP software module may be reported instead. This AVP is 1199 optional. 1201 Host Name 1203 0 1 2 3 1204 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 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | 7 + length of host name | 0 | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | 5 |0 0 0 0 0 0 0 0|Host name... | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 The Host Name AVP within a Start-Control-Connection-Reply indi- 1212 cates the DNS name of the issuing LAC or LNS. It is encoded as 1213 the Attribute 5, not mandatory, with the indicated number of bytes 1214 representing the host name string. This AVP is optional. 1216 Vendor Name 1218 0 1 2 3 1219 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 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | (7 + vendor length) | 0 | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | 6 |0 0 0 0 0 0 0 0|Vendor name... | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 The Vendor Name AVP within a Start-Control-Connection-Reply con- 1227 tains a vendor specific string describing the type of LAC or LNS 1228 being used. It is encoded as the Attribute 6, not mandatory, with 1229 the indicated number of bytes representing the vendor string. 1230 This AVP is optional. 1232 Assigned Tunnel ID 1234 0 1 2 3 1235 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 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | (7 + vendor length) | 0 | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | 7 |0 0 0 0 0 0 0 1| ID (H) | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | ID (L) | 1242 +-+-+-+-+-+-+-+-+ 1244 The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply 1245 specifies the Tunnel ID which the peer should use in all subse- 1246 quent packets. It is encoded as the Attribute 7, mandatory, with 1247 the two bytes encoded as a 16-bit non-zero Tunnel ID value. This 1248 AVP must be present. 1250 Control Message Window 1252 0 1 2 3 1253 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 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | 8 | 0 | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | 8 |0 0 0 0 0 0 0 0| Window | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 The Control Message Window AVP within a Start-Control-Connection- 1261 Reply specifies the number of control messages which may be 1262 received without waiting for an acknowledgment. It is encoded as 1263 the Attribute 8, not mandatory, with a single octet indicating the 1264 number of such messages. If absent, the peer must use a value of 1265 1 for the Window. 1267 Result Code 1269 0 1 2 3 1270 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 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | 8 | 0 | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | 9 |0 0 0 0 0 0 0 1| Code | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 The Result Code AVP within a Start-Control-Connection-Reply packet 1278 indicates the result of the command channel establishment attempt. 1279 The Value field is 9, indicating a Result Code. The code is a 1280 single octet, and this AVP is mandatory. Result code values are: 1281 1 - Successful channel establishment 1282 2 - General error--Error Code indicates the problem 1283 3 - Command channel already exists 1284 4 - Requester is not authorized to establish a command channel 1285 5 - The protocol version of the requester is not supported 1287 Error Code 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 | 8 | 0 | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | 10 |0 0 0 0 0 0 0 1| Error | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 This AVP is present only if a "General Error" exists, in which 1298 case Result Code is set to 2 and this AVP encodes the general 1299 error value as documented in section 5.5. It has a Value of 10, 1300 and is marked mandatory. 1302 Challenge 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 | 7 + length of challenge | 0 | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | 11 |0 0 0 0 0 0 0 1| Challenge... | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 |Challenge... | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 The Challenge AVP within a Start-Control-Connection-Reply indi- 1315 cates that the peer wishes to authenticate the tunnel initiator. 1316 It is encoded as the Attribute 11, mandatory, with at least one 1317 byte of challenge value embedded. 1319 Response 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 | 23 | 0 | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | 12 |0 0 0 0 0 0 0 1| Response... | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | Response... (128 bits) | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 The Response AVP within a Start-Control-Connection-Reply packet 1332 provides a response to a challenge received. The Attribute value 1333 is 12, indicating Response, and the Value field is a 128-bit value 1334 reflecting the CHAP-style response to the challenge. This AVP 1335 must be present if a challenge was received, otherwise is omitted. 1336 For purposes of the ID value in the CHAP response calculation, the 1337 low order byte of the Sequence number of the challenge are used. 1339 6.3 Start-Control-Connection-Connected 1341 The Start-Control-Connection-Connected message is an L2TP control 1342 message sent in reply to a received Start-Control-Connection-Reply 1343 message. This message provides closure to the tunnel establishment 1344 process, and includes a challenge response if the peer sent a chal- 1345 lenge in the Start-Control-Connection-Reply message. The message is 1346 structured as: 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | L2TP Control Message Header | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Start-Control-Connection-Connected | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | Response | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+ 1356 Start-Control-Connection-Reply AVP 1358 0 1 2 3 1359 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 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | 7 | 0 | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | 17 |0 0 0 0 0 0 0 1| 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 The Attribute field is 17, indicating Start-Control-Connection- 1367 Connected. The Flags indicate a mandatory option. 1369 Response 1371 0 1 2 3 1372 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 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | 23 | 0 | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | 1 |0 0 0 0 0 0 0 1| Response... | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Response... (128 bits) | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 The Response AVP within a Start-Control-Connection-Connected 1382 packet provides a response to a challenge received. The Attribute 1383 value is 1, indicating Response, and the Value field is a 128-bit 1384 value reflecting the CHAP-style response to the challenge. This 1385 AVP must be present if a challenge was received, otherwise is 1386 omitted. For purposes of the ID value in the CHAP response calcu- 1387 lation, the low order byte of the Sequence number of the challenge 1388 are used. 1390 6.4 Stop-Control-Connection-Request 1392 The Stop-Control-Connection-Request is an L2TP control message sent 1393 by one peer of a LAC-LNS control connection to inform the other peer 1394 that the control connection should be closed. In addition to closing 1395 the control connection, all active user calls are implicitly cleared. 1396 The reason for issuing this request is indicated in the Reason field. 1397 The message is structured as: 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | L2TP Control Message Header | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Stop-Control-Connection-Request | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Reason | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+ 1407 Stop-Control-Connection-Request AVP 1409 0 1 2 3 1410 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 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | 7 | 0 | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | 3 |0 0 0 0 0 0 0 1| 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 The Attribute field is 3, indicating Stop-Control-Connection- 1418 Request. The Flags indicate a mandatory option. The Flags indi- 1419 cate a mandatory option. The single Reason AVP must follow this. 1421 Reason 1423 0 1 2 3 1424 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 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | 8 | 0 | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | 1 |0 0 0 0 0 0 0 1| Reason | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 The Reason octet indicates the reason for the control connection 1432 closure. Values are: 1434 1 - General request to clear control connection 1435 2 - Can't support peer's version of the protocol 1436 3 - Requester is being shut down 1438 6.5 Stop-Control-Connection-Reply 1440 The Stop-Control-Connection-Reply is an L2TP control message sent by 1441 one peer of a LAC-LNS control connection upon receipt of a Stop- 1442 Control-Connection-Request from the other peer. 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | L2TP Control Message Header | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Stop-Control-Connection-Reply | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Result Code | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Error Code | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+ 1453 Stop-Control-Connection-Reply AVP 1455 0 1 2 3 1456 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 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | 7 | 0 | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | 4 |0 0 0 0 0 0 0 1| 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 The Attribute field is 4, indicating Stop-Control-Connection- 1464 Reply. The Flags indicate a mandatory option. 1466 Result Code 1468 0 1 2 3 1469 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 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | 8 | 0 | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | 1 |0 0 0 0 0 0 0 1| Result | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 The Result octet indicates the result of the attempt to close the 1477 control connection. It has a Value of 1 and is marked mandatory. 1478 Valid Result Code values are: 1480 1 - Control connection closed 1481 2 - Control connection not closed for reason indicated in Error Code 1483 Error Code 1485 0 1 2 3 1486 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 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | 8 | 0 | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | 2 |0 0 0 0 0 0 0 1| Error | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 This AVP is present only if a "General Error" exists, in which 1494 case Result Code is set to 2 and this AVP encodes the general 1495 error value as documented in section 5.5. It has a Value of 2, 1496 and is marked mandatory. 1498 6.6 Echo-Request 1500 The Echo-Request is a L2TP control message sent by either peer of a 1501 LAC-LNS control connection. This control message is used as a "keep 1502 Alive" for the control connection. The receiving peer issues an 1503 Echo-Reply to each Echo-Request received. 1505 Keepalives should be implemented by sending an Echo-Request once 1506 every 5 seconds if 60 seconds have passed since a message has been 1507 received from the peer. If an Echo-Reply has not been received in 20 1508 seconds, the connection should be closed. These are guideline val- 1509 ues; actual values may need to vary based on the requirements of a 1510 particular tunnel media. 1512 Echoes are global to the tunnel; the Call ID field of these control 1513 messages must be 0. 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | L2TP Control Message Header | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Echo-Request | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | Identifier | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+ 1523 Echo-Request AVP 1525 0 1 2 3 1526 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 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | 7 | 0 | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | 5 |0 0 0 0 0 0 0 1| 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 The Attribute field is 5, indicating Echo-Request. The Flags 1534 indicate a mandatory option. 1536 Identifier 1538 0 1 2 3 1539 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 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | 11 | 0 | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | 1 |0 0 0 0 0 0 0 1| ID... | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | ... 32-bits | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 The Identifier AVP has an Attribute of 1, and the AVP is marked 1549 mandatory. The ID set in the value of this AVP is set by the 1550 sender of the Echo-Request and can be used to match the reply with 1551 the corresponding request. This AVP is optional. 1553 6.7 Echo-Reply 1555 The Echo-Reply is a L2TP control message sent back upon receipt of an 1556 Echo-Request. 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | L2TP Control Message Header | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | Echo-Reply | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | Identifier | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+ 1566 Echo-Reply AVP 1568 0 1 2 3 1569 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 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | 7 | 0 | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 | 6 |0 0 0 0 0 0 0 1| 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 The Attribute field is 6, indicating Echo-Reply. The Flags indi- 1577 cate a mandatory option. 1579 Identifier 1581 0 1 2 3 1582 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 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | 11 | 0 | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | 1 |0 0 0 0 0 0 0 1| ID... | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | ... 32-bits | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 The Identifier AVP has an Attribute of 1, and the AVP is marked 1592 mandatory. If an Echo-Request is received with this AVP, the same 1593 AVP (with identical ID) is sent back in the Echo-Reply packet. 1594 Otherwise this AVP is not included in the Echo-Reply. 1596 6.8 Outgoing-Call-Request 1598 The Outgoing-Call-Request is a L2TP control message sent by the LNS 1599 to the LAC to indicate that an outbound call from the LNS is to be 1600 established. This request provides the LAC with information required 1601 to make the call. It also provides information to the LAC that is 1602 used to regulate the transmission of data to the LNS for this session 1603 once it is established. The message is structured as: 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | L2TP Control Message Header | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | Outgoing-Call-Request | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | Assigned Call ID | 1611 | Call Serial Number | 1612 | Minumum BPS | 1613 | Maximum BPS | 1614 | Bearer Type | 1615 | Framing Type | 1616 | Packet Recv. Window | 1617 | Packet Processing Delay | 1618 | Phone Number | 1619 | Sub-Address | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 Outgoing-Call-Request AVP 1624 0 1 2 3 1625 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 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | 7 | L2TP Message Type | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | 7 |0 0 0 0 0 0 0 1| 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 The Outgoing-Call-Request AVP encodes a request to an LAC to 1633 establish an outgoing call. The flags indicate a mandatory 1634 option. 1636 Assigned Call ID AVP 1638 0 1 2 3 1639 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 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | 9 | 0 | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | 1 |0 0 0 0 0 0 0 1| ID (H) | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | ID (L) | 1646 +-+-+-+-+-+-+-+-+ 1648 The Assigned Call ID AVP encodes the ID being assigned to call by 1649 the LNS. The flags indicate a mandatory option. ID value is a 1650 unique identifier, unique to a tunnel, assigned by the LNS to this 1651 session. It is used to multiplex and demultiplex data sent over 1652 that tunnel between the LNS and LAC. This AVP must be present. 1654 Call Serial Number 1656 0 1 2 3 1657 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 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | 9 | 0 | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | 2 |0 0 0 0 0 0 0 1| Number (H) | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | Number (L) | 1664 +-+-+-+-+-+-+-+-+ 1666 Call Serial Number AVP encodes an identifier assigned by the LNS to 1667 this call. The flags indicate a mandatory option. The Number value 1668 (Call Serial Number) is an identifier used by the LNS and the LAC 1669 for identifying the call. Unlike the Call ID, both the LNS and LAC 1670 associate the same Call Serial Number with a given call. This AVP 1671 must be present. 1673 Minimum BPS 1675 0 1 2 3 1676 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 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | 11 | 0 | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | 3 |0 0 0 0 0 0 0 1| BPS (H) | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | BPS (L) | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 Minimum BPS AVP encodes the lowest acceptable line speed for this 1686 call. The flags indicate a mandatory option. The BPS value indi- 1687 cates the speed in bits/second. This AVP must be present. 1689 Maximum BPS 1691 0 1 2 3 1692 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 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | 11 | 0 | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | 4 |0 0 0 0 0 0 0 1| BPS (H) | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | BPS (L) | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 Maximum BPS AVP encodes the highest acceptable line speed for this 1702 call. The flags indicate a mandatory option. The BPS value indi- 1703 cates the speed in bits/second. This AVP must be present. 1705 Bearer Type AVP 1707 0 1 2 3 1708 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 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | 11 | 0 | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | 5 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 Bearer Type AVP encodes the bearer type for the requested call. 1718 The flags indicate a mandatory option. The value bit field indi- 1719 cates the bearer capability required for this outgoing call. Bit 1720 A if set indicates that the call should be on an analog channel. 1721 Bit D if set indicates that the call should be on a digital chan- 1722 nel. Both bits set indicate that the call can be of either type. 1724 This AVP must be present. 1726 Framing Type AVP 1728 0 1 2 3 1729 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 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 | 11 | 0 | 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | 6 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A S| 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 Framing Type AVP encodes the framing type for the requested call. 1739 The flags indicate a mandatory option. The value bit field indi- 1740 cates the type of PPP framing to be used for the outgoing call. 1741 Bit A if set indicates that Asynchronous framing should be used. 1742 Bit S is set indicates that Synchronous framing should be used. 1743 This AVP must be present. 1745 Packet Receive Window Size AVP 1747 0 1 2 3 1748 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 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | 9 | 0 | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | 7 |0 0 0 0 0 0 0 1| Size (H) | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | Size (L) | 1755 +-+-+-+-+-+-+-+-+ 1757 Packet Recieve Window Size AVP encodes the window size being 1758 advertised by the LNS for this call. The flags indicate a manda- 1759 tory option. The Size value indicates the number of received data 1760 packets the LNS will buffer for this call. This AVP is optional. 1762 Packet Processing Delay AVP 1764 0 1 2 3 1765 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 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 | 9 | 0 | 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | 8 |0 0 0 0 0 0 0 1| Delay (H) | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Delay (L) | 1772 +-+-+-+-+-+-+-+-+ 1774 Packet Processing Delay AVP encodes the delay LNS has for process- 1775 ing window full of packets sent by the LAC. The flags indicate a 1776 mandatory option. The Delay value is specified in units of 1/10 1777 seconds. This AVP is optional. Refer to appendix A to see a 1778 description of how this value is determined and used. 1780 Phone Number AVP 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 | 7 + N | 0 | 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 | 9 |0 0 0 0 0 0 0 1| Phone Number..| 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | Phone Number ... | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 Phone Number AVP encodes the phone number to be called. The flags 1793 indicate a mandatory option. The Phone Number value is an ASCII 1794 string. The length of the string is the length in the AVP header 1795 minus 7 bytes. This AVP is optional. 1797 Sub-Address AVP 1799 0 1 2 3 1800 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 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | 7 + N | 0 | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | 10 |0 0 0 0 0 0 0 1| Sub-Address ..| 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Sub-Address ... | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 Sub-Address AVP encodes additional dialing information. The flags 1810 indicate a mandatory option. The Sub-Address value is an ASCII 1811 string. The length of the string is the length in the AVP header 1812 minus 7 bytes. This AVP is optional. 1814 6.9 Outgoing-Call-Reply 1816 The Outgoing-Call-Reply is a L2TP control message sent by the LAC to 1817 the LNS in response to a received Outgoing-Call-Request message. The 1818 reply indicates the result of the outgoing call attempt. It also 1819 provides information to the LNS about particular parameters used for 1820 the call. It provides information to allow the LNS to regulate the 1821 transmission of data to the LAC for this session. The message is 1822 structured as: 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | L2TP Control Message Header | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | Outgoing-Call-Reply | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | Assigned Call ID | 1830 | Result Code | 1831 | Error Code | 1832 | Cause Code | 1833 | Connect Speed | 1834 | Framing Type | 1835 | Packet Recv. Window | 1836 | Packet Processing Delay | 1837 | Physical Channel Id | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 Outgoing-Call-Reply AVP 1842 0 1 2 3 1843 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 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 | 7 | 0 | 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 | 8 |0 0 0 0 0 0 0 1| 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 The Outgoing-Call-Reply AVP encodes a result of an outgoing call 1851 request. The flags indicate a mandatory option. 1853 Assigned Call ID AVP 1855 0 1 2 3 1856 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 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | 9 | 0 | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | 1 |0 0 0 0 0 0 0 1| ID (H) | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | ID (L) | 1863 +-+-+-+-+-+-+-+-+ 1865 The Assigned Call ID AVP encodes the ID being assigned to call by the 1866 LAC. The flags indicate a mandatory option. ID value is a unique 1867 identifier, unique to a tunnel, assigned by the LNS to this session. 1868 It is used to multiplex and demultiplex data sent over that tunnel 1869 between the LNS and LAC. This AVP must be present. 1871 Result Code AVP 1873 0 1 2 3 1874 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 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 | 8 | 0 | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 | 2 |0 0 0 0 0 0 0 1| Result Code | 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 Result Code AVP encodes the result of the Outgoing-Call-Request. The 1882 flags indicate a mandatory option. The Result Code value can be one 1883 of the following: 1885 1 - Call established with no errors 1886 2 - Outgoing Call not established for the reason indicated in Error Code 1887 3 - Outgoing Call failed due to no carrier detected 1888 4 - Outgoing Call failed due to detection of a busy signal 1889 5 - Outgoing Call failed due to lack of a dial tone 1890 6 - Outgoing Call was not established within time allotted by LAC 1891 7 - Outgoing Call administratively prohibited 1893 This AVP is mandatory. 1895 Error Code AVP 1897 0 1 2 3 1898 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 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | 8 | 0 | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | 3 |0 0 0 0 0 0 0 1| Error Code | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 The Error Code AVP is used to encode a specific error code in case 1906 the result AVP indicates a General Error. The flags indicate a 1907 mandatory option. The value can be one of the general error IDs 1908 specified in Section 5.5. This AVP is optional. 1910 Cause Code AVP 1912 0 1 2 3 1913 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 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 | 8 | 0 | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | 4 |0 0 0 0 0 0 0 1| Error Code | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 The Cause Code AVP is used to give additional information in case of 1921 call failure. The flags indicate a mandatory option. The Code value 1922 can vary depending upon the type of call attempted. For ISDN call 1923 attempts it is the Q.931 cause code. 1925 Connect Speed AVP 1927 0 1 2 3 1928 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 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | 11 | 0 | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | 5 |0 0 0 0 0 0 0 1| BPS (H) | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | BPS (L) | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 Connect Speed BPS AVP encodes the speed for the connection. The 1938 flags indicate a mandatory option. The BPS value indicates the speed 1939 in bits/second. This AVP must be present if the call attempt is 1940 successful. 1942 Framing Type AVP 1944 0 1 2 3 1945 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 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 | 11 | 0 | 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | 6 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 Framing Type AVP encodes the framing type for the call. The flags 1955 indicate a mandatory option. The value bit field indicates the type 1956 of PPP framing is used for the call. Bit A if set indicates that 1957 Asynchronous framing is being used. Bit S is set indicates that Syn- 1958 chronous framing is being used. This AVP must be present if the call 1959 attempt is successful. 1961 Packet Receive Window Size AVP 1963 0 1 2 3 1964 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 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | 9 | 0 | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 | 7 |0 0 0 0 0 0 0 1| Size (H) | 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | Size (L) | 1971 +-+-+-+-+-+-+-+-+ 1973 Packet Recieve Window Size AVP encodes the window size being adver- 1974 tised by the LAC for this call. The flags indicate a mandatory 1975 option. The Size value indicates the number of received data packets 1976 the LAC will buffer for this call. This AVP is optional. 1978 Packet Processing Delay AVP 1980 0 1 2 3 1981 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 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | 9 | 0 | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | 8 |0 0 0 0 0 0 0 1| Delay (H) | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | Delay (L) | 1988 +-+-+-+-+-+-+-+-+ 1990 Packet Processing Delay AVP encodes the delay LAC has for processing 1991 window full of packets sent by the LNS. The flags indicate a 1992 mandatory option. The Delay value is specified in units of 1/10 1993 seconds. This AVP is optional. Please refer to appendix A to see a 1994 description of how this value is determined and used. 1996 Physical Channel ID AVP 1998 0 1 2 3 1999 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 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | 11 | 0 | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | 9 |0 0 0 0 0 0 0 1| ID (H) | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | ID (L) | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 Physical Channel ID AVP encodes the vendor specific physical channel 2009 number used for the call. The flags indicate a mandatory option. 2010 The value is used for logging purposes only. This AVP is optional. 2012 6.10 Incoming-Call-Request 2014 The Incoming-Call-Request is a L2TP control message sent by the LAC 2015 to the LNS to indicate that an inbound call is to be established from 2016 the LAC. This request provides the LNS with parameter information 2017 for the incoming call. 2019 This message is the first in the "three-way handshake" used by L2TP 2020 for establishing incoming calls. The LAC may defer answering the 2021 call until it has received an Incoming-Call-Reply from the LNS indi- 2022 cating that the call should be established. This mechanism allows 2023 the LNS to obtain sufficient information about the call before it is 2024 answered to determine whether the call should be answered or not. 2025 The message is structured as: 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 | L2TP Control Message Header | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | Incoming-Call-Request | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | Assigned Call ID | 2033 | Call Serial Number | 2034 | Call Bearer Type | 2035 | Physical Channel Id | 2036 | Dialed Number | 2037 | Dialing Number | 2038 | Sub-Address | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 Incoming-Call-Request AVP 2043 0 1 2 3 2044 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 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 | 7 | 0 | 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | 9 |0 0 0 0 0 0 0 1| 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 The Incoming-Call-Request AVP encodes an incoming call being indi- 2052 cated by the LAC. The flags indicate a mandatory option. 2054 Assigned Call ID AVP 2056 0 1 2 3 2057 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 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | 9 | 0 | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | 1 |0 0 0 0 0 0 0 1| ID (H) | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | ID (L) | 2064 +-+-+-+-+-+-+-+-+ 2066 The Assigned Call ID AVP encodes the ID being assigned to call by the 2067 LAC. The flags indicate a mandatory option. ID value is a unique 2068 identifier, unique to a tunnel, assigned by the LNS to this session. 2069 It is used to multiplex and demultiplex data sent over that tunnel 2070 between the LNS and LAC. This AVP must be present. 2072 Call Serial Number AVP 2074 0 1 2 3 2075 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 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | 9 | 0 | 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 | 2 |0 0 0 0 0 0 0 1| Number (H) | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | Number (L) | 2082 +-+-+-+-+-+-+-+-+ 2084 Call Serial Number AVP encodes an identifier assigned by the LAC to 2085 this call. The flags indicate a mandatory option. The Number value 2086 (Call Serial Number) is an identifier used by the LNS and the LAC for 2087 identifying the call. Unlike the Call ID, both the LNS and LAC asso- 2088 ciate the same Call Serial Number with a given call. This AVP must 2089 be present. 2091 Call Bearer Type AVP 2093 0 1 2 3 2094 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 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | 11 | 0 | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 | 3 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 Call Bearer Type AVP encodes the bearer type for the incoming call. 2103 The flags indicate a mandatory option. The value bit field indicates 2104 the bearer capability being used by the incoming call. Bit A if set 2105 indicates that the call is on an analog channel. Bit D if set indi- 2106 cates that the call is on a digital channel. This AVP must be pre- 2107 sent. 2109 Physical Channel ID AVP 2111 0 1 2 3 2112 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 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2114 11 | 0 | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2116 4 |0 0 0 0 0 0 0 1| ID (H) | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2118 ID (L) | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 Physical Channel ID AVP encodes the vendor specific physical channel 2122 number used for the call. The flags indicate a mandatory option. 2123 The value is used for logging purposes only. This AVP is optional. 2125 Dialed Number AVP 2127 0 1 2 3 2128 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 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | 7 + N | 0 | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | 5 |0 0 0 0 0 0 0 1| Number... | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | Number... | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 Dialed NUmber AVP encodes the dialed number for the incoming call. 2138 The flags indicate a mandatory option. The value is an ASCII string. 2139 The length of the number is the length in the AVP header minus 7. 2140 This AVP is optional. 2142 Dialing Number AVP 2144 0 1 2 3 2145 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 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | 7 + N | 0 | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | 6 |0 0 0 0 0 0 0 1| Number... | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 | Number... | 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 Dialing NUmber AVP encodes the originating number for the incoming 2155 call. The flags indicate a mandatory option. The value is an ASCII 2156 string. The length of the number is the length in the AVP header 2157 minus 7. This AVP is optional. 2159 Sub-Address AVP 2161 0 1 2 3 2162 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 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | 7 + N | 0 | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | 7 |0 0 0 0 0 0 0 1| Sub-Address...| 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Sub-Address ... | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 Sub-Address AVP encodes additional dialing information. The flags 2172 indicate a mandatory option. The Sub-Address value is an ASCII 2173 string. The length of the string is the length in the AVP header 2174 minus 7 bytes. This AVP is optional. 2176 6.11 Incoming-Call-Reply 2178 The Incoming-Call-Reply is a L2TP control message sent by the LNS to 2179 the LAC in response to a received Incoming-Call-Request message. The 2180 reply indicates the result of the incoming call attempt. It also 2181 provides information to allow the LAC to regulate the transmission of 2182 data to the LNS for this session. 2184 This message is the second in the three-way handshake used by L2TP 2185 for establishing incoming calls. It indicates to the LAC whether the 2186 call should be answered or not. The message is structured as: 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | L2TP Control Message Header | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | Incoming-Call-Reply | 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 | Assigned Call ID | 2194 | Result Code | 2195 | Error Code | 2196 | Packet Recv. Window Size | 2197 | Packet Transmit Delay | 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 Incoming-Call-Reply AVP 2202 0 1 2 3 2203 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 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | 7 | 0 | 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | 10 |0 0 0 0 0 0 0 1| 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 The Incoming-Call-Reply AVP encodes a response by the LNS to the 2210 incoming call indication given by the LAC. The flags indicate a 2211 mandatory option. 2213 Assigned Call ID AVP 2215 0 1 2 3 2216 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 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | 9 | 0 | 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 | 1 |0 0 0 0 0 0 0 1| ID (H) | 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | ID (L) | 2223 +-+-+-+-+-+-+-+-+ 2225 The Assigned Call ID AVP encodes the ID being assigned to call by the 2226 LNS. The flags indicate a mandatory option. ID value is a unique 2227 identifier, unique to a tunnel, assigned by the LNS to this session. 2228 It is used to multiplex and demultiplex data sent over that tunnel 2229 between the LNS and LAC. This AVP must be present. 2231 Result Code AVP 2233 0 1 2 3 2234 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 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | 8 | 0 | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | 2 |0 0 0 0 0 0 0 1| Result Code | 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 Result Code AVP encodes the result of the Incoming-Call-Request. The 2242 flags indicate a mandatory option. The Result Code value can be one 2243 of the following: 2245 1 - The LAC should answer the incoming call 2246 2 - The Incoming Call should not be established due to the reason 2247 indicated in Error Code 2248 3 - The LAC should not accept the incoming call. It should hang 2249 up or issue a busy indication 2251 This AVP is mandatory. 2253 Error Code AVP 2255 0 1 2 3 2256 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 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | 8 | 0 | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 | 3 |0 0 0 0 0 0 0 1| Error Code | 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 The Error Code AVP is used to encode a specific error code in case 2263 the result AVP indicates a General Error. The flags indicate a 2264 mandatory option. The value can be one of the general error IDs 2265 specified in Section 5.5. This AVP is optional. 2267 Packet Receive Window Size AVP 2269 0 1 2 3 2270 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 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 | 9 | 0 | 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | 4 |0 0 0 0 0 0 0 1| Size (H) | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | Size (L) | 2277 +-+-+-+-+-+-+-+-+ 2279 Packet Recieve Window Size AVP encodes the window size being adver- 2280 tised by the LNS for this call. The flags indicate a mandatory 2281 option. The Size value indicates the number of received packets the 2282 LNS will buffer for this call. This AVP is optional. 2284 Packet Processing Delay AVP 2286 0 1 2 3 2287 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 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | 9 | 0 | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 | 5 |0 0 0 0 0 0 0 1| Delay (H) | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | Delay (L) | 2294 +-+-+-+-+-+-+-+-+ 2296 Packet Processing Delay AVP encodes the delay LNS has for processing 2297 window full of packets sent by the LAC. The flags indicate a manda- 2298 tory option. The Delay value is specified in units of 1/10 seconds. 2299 This AVP is optional. Please refer to appendix A to see a descrip- 2300 tion of how this value is determined and used. 2302 6.12 Incoming-Call-Connected 2304 The Incoming-Call-Connected message is a L2TP control message sent by 2305 the LAC to the LNS in response to a received Incoming-Call-Reply. It 2306 provides information to the LNS about particular parameters used for 2307 the call. It also provides information to allow the LNS to regulate 2308 the transmission of data to the LAC for this session. 2310 This message is the third in the three-way handshake used by L2TP for 2311 establishing incoming calls. It provides a mechanism for providing 2312 the LNS with additional information about the call that cannot, in 2313 general, be obtained at the time the Incoming-Call-Request is issued 2314 by the LAC. The message is structured as: 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 | L2TP Control Message Header | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 | Incoming-Call-Connected | 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | Connect Speed | 2322 | Framing Type | 2323 | Packet Recv. Window | 2324 | Packet Processing Delay | 2325 | Initial LCP Conf | 2326 | Last Sent LCP Conf | 2327 | Last Received LCP Conf | 2328 | Proxy authen type | 2329 | Proxy authen name | 2330 | Proxy authen challenge | 2331 | Proxy authen ID | 2332 | Proxy authen response | 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 Incoming-Call-Connected AVP 2337 0 1 2 3 2338 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 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | 7 | 0 | 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | 11 |0 0 0 0 0 0 0 1| 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 The Incoming-Call-Connected AVP encodes a response by the LAC to the 2346 Incoming-Call-Reply message sent by the LAC. The flags indicate a 2347 mandatory option. 2349 Connect Speed AVP 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 | 11 | 0 | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | 1 |0 0 0 0 0 0 0 1| BPS (H) | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | BPS (L) | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 Connect Speed BPS AVP encodes the speed for the connection. The 2362 flags indicate a mandatory option. The BPS value indicates the speed 2363 in bits/second. This AVP must be present if the call attempt is suc- 2364 cessful. 2366 Framing Type AVP 2368 0 1 2 3 2369 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | 11 | 0 | 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 | 2 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2376 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 Framing Type AVP encodes the framing type for the call. The flags 2380 indicate a mandatory option. The value bit field indicates the type 2381 of PPP framing is used for the call. Bit A if set indicates that 2382 Asynchronous framing is being used. Bit S is set indicates that Syn- 2383 chronous framing is being used. This AVP must be present if the call 2384 attempt is successful. 2386 Packet Receive Window Size AVP 2388 0 1 2 3 2389 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | 11 | 0 | 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 | 3 |0 0 0 0 0 0 0 1| Size (H) | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | Size (L) | 2396 +-+-+-+-+-+-+-+-+ 2398 Packet Recieve Window Size AVP encodes the window size being adver- 2399 tised by the LAC for this call. The flags indicate a mandatory 2400 option. The Size value indicates the number of received packets the 2401 LAC will buffer for this call. This AVP is optional. 2403 Packet Processing Delay AVP 2405 0 1 2 3 2406 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 2407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 | 9 | 0 | 2409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2410 | 4 |0 0 0 0 0 0 0 1| Delay (H) | 2411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2412 | Delay (L) | 2413 +-+-+-+-+-+-+-+-+ 2415 Packet Processing Delay AVP encodes the delay LAC has for processing 2416 window full of packets sent by the LNS. The flags indicate a manda- 2417 tory option. The Delay value is specified in units of 1/10 seconds. 2418 This AVP is optional. Please refer to appendix A to see a descrip- 2419 tion of how this value is determined and used. 2421 Initial LCP Conf 2423 0 1 2 3 2424 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 | 7 + length of confreq | 0 | 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 | 5 |0 0 0 0 0 0 0 0| LCP confreq...| 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 The LAC may have answered the phone call and negotiated LCP with the 2433 dial-in client in order to establish the client's apparent identity. 2434 In this case, this option may be included to indicate the link prop- 2435 erties the client requested in its initial LCP CONFREQ request. The 2436 Value field is a copy of the body of the intial CONFREQ received, 2437 starting at the first option within this packet's body. This AVP is 2438 marked not mandatory, and the AVP itself is optional. 2440 Last Sent LCP Conf 2442 0 1 2 3 2443 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 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 | 7 + length of confreq | 0 | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | 6 |0 0 0 0 0 0 0 0| LCP confreq...| 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 See Initial LCP Conf above for rationale. The Value field is a copy 2451 of the body of the final CONFREQ sent to the client to complete LCP 2452 negotiation, starting at the first option within this packet's body. 2453 This AVP is marked not mandatory, and the AVP itself is optional. 2455 Last Received LCP Conf 2457 0 1 2 3 2458 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 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2460 | 7 + length of confreq | 0 | 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 | 7 |0 0 0 0 0 0 0 0| LCP confreq...| 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2465 See Initial LCP Conf above for rationale. The Value field is a copy 2466 of the body of the final CONFREQ received from the client to complete 2467 LCP negotiation, starting at the first option within this packet's 2468 body. This AVP is marked not mandatory, and the AVP itself is 2469 optional. 2471 Proxy authen type 2473 0 1 2 3 2474 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 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 | 8 | 0 | 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 | 8 |0 0 0 0 0 0 0 0| Type | 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 This AVP is marked mandatory, and the AVP itself must be present. 2481 Type is a byte, holding a value: 2483 1 - Textual username/password exchange 2484 2 - PPP CHAP 2485 3 - PPP PAP 2486 4 - None 2488 Associated AVP's for each type of authentication follow. 2490 Proxy authen name 2492 0 1 2 3 2493 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 2494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 | 7 + length of name | 0 | 2496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2497 | 9 |0 0 0 0 0 0 0 0| Name... | 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2500 This AVP is marked mandatory, and the AVP itself must be present for 2501 Proxy authen type values 1, 2, and 3. The Name field contains the 2502 name specified in the client's authentication response. 2504 Proxy authen challenge 2506 0 1 2 3 2507 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 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 | 7 + length of challenge | 0 | 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | 10 |0 0 0 0 0 0 0 0| Challenge... | 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 This AVP is marked mandatory, and the AVP itself must be present for 2515 Proxy authen type 2. The Challenge field contains the value pre- 2516 sented to the client by the LAC. 2518 Proxy authen ID 2520 0 1 2 3 2521 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 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 | 8 | 0 | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 | 11 |0 0 0 0 0 0 0 0| ID | 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 This AVP is marked mandatory, and the AVP itself must be present for 2529 Proxy authen type 2. The ID field contains the byte ID value pre- 2530 sented to the client by the LAC in its associated CHAP challenge. 2532 Proxy authen response 2533 0 1 2 3 2534 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 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 | 7 + length of Response | 0 | 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 | 12 |0 0 0 0 0 0 0 0| Response... | 2539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 This AVP is marked mandatory, and the AVP itself must be present for 2542 Proxy authen types 1, 2, and 3. The Response field contains the 2543 client's response to the challenge. For Proxy authen type 2, this 2544 field contains the response value received by the LAC. For types 1 2545 or 3, it contains the clear text password received from the client by 2546 the LAC. 2548 6.13 Call-Clear-Request 2550 The Call-Clear-Request is a L2TP control message sent by the LNS to 2551 the LAC indicating that a particular call is to be disconnected. The 2552 call being cleared can be either an incoming or outgoing call, in any 2553 state. The LAC responds to this message with a Call-Disconnect- 2554 Notify message. The message is structured as: 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 | L2TP Control Message Header | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2559 | Call-Clear-Request | 2560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 Call-Clear-Request AVP 2564 0 1 2 3 2565 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 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 | 7 | 0 | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | 12 |0 0 0 0 0 0 0 1| 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 The Call-Clear-Request AVP encodes a request by the LNS to the LAC to 2573 disconnect the call. The flags indicate a mandatory option. 2575 6.14 Call-Disconnect-Notify 2577 The Call-Disconnect-Notify message is a L2TP control message sent by 2578 the LAC to the LNS. It is issued whenever a call is disconnected, 2579 due to the receipt by the LAC of a Call-Clear-Request or for any 2580 other reason. Its purpose is to inform the LNS of the disconnection 2581 and the reason why the disconnection occured. The message is struc- 2582 tured as: 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 | L2TP Control Message Header | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 | Call-Disconnect-Notify | 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 | Result Code | 2590 | Error Code | 2591 | Cause Code | 2592 | Call Statistics | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 Call-Disconnect-Notify AVP 2597 0 1 2 3 2598 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 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 | 7 | 0 | 2601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 | 13 |0 0 0 0 0 0 0 1| 2603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 The Call-Disconnect-Nofity AVP encodes a disconnect indication from 2606 the LAC to the LNS. The flags indicate a mandatory option. 2608 Result Code AVP 2610 0 1 2 3 2611 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 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 | 8 | 0 | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 | 1 |0 0 0 0 0 0 0 1| Result Code | 2616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2618 Result Code AVP encodes the reason for disconnect. The flags indi- 2619 cate a mandatory option. The Result Code value can be one of the 2620 following: 2622 1 (Lost Carrier) - Call disconnected due to loss of carrier 2623 2 (General Error) - Call disconnected for the reason indicated in 2624 Error Code. 2625 3 (Admin Shutdown) - Call disconnected for administrative reasons 2626 4 (Request) - Call disconnected due to received Call-Clear-Request 2628 This AVP is mandatory. 2630 Error Code AVP 2632 0 1 2 3 2633 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 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | 8 | 0 | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | 2 |0 0 0 0 0 0 0 1| Error Code | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 The Error Code AVP is used to encode a specific error code in case 2641 the result AVP indicates a General Error. The flags indicate a 2642 mandatory option. The value can be one of the general error IDs 2643 specified in Section 5.5. This AVP is optional. 2645 Cause Code AVP 2647 0 1 2 3 2648 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 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 | 8 | 0 | 2651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2652 | 3 |0 0 0 0 0 0 0 1| Error Code | 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2655 The Cause Code AVP is used to give additional information in case of 2656 unsolicited call disconnection. The flags indicate a mandatory 2657 option. The Code value can vary depending upon the type of call. 2658 For ISDN call attempts it is the Q.931 cause code. 2660 Call Statistics AVP 2662 0 1 2 3 2663 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 2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2665 | 7 + N | 0 | 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 | 4 |0 0 0 0 0 0 0 1| Call Stats... | 2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2669 | Call Statistics ... | 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 The Call Statistics AVP is used by the LAC to send vendor specific 2673 call statistics for logging purposes. The flags indicate a mandatory 2674 option. The Call Statistics value is ab ASCII string containing ven- 2675 dor specific call statistics that LNS can log for diagnostic pur- 2676 poses. The length of the string is the length in the AVP header 2677 minus 7. This AVP is optional. 2679 6.15 WAN-Error-Notify 2681 The WAN-Error-Notify message is a L2TP control message sent by the 2682 LAC to the LNS to indicate WAN error conditions (conditions that 2683 occur on the interface supporting PPP). The counters in this message 2684 are cumulative. This message should only be sent when an error 2685 occurs, and not more than once every 60 seconds. The counters are 2686 reset when a new call is established. The message is structured as: 2688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2689 | L2TP Control Message Header | 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | WAN-Error-Notify | 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | Call Errors | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 WAN-Error-Notify AVP 2697 0 1 2 3 2698 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 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 | 7 | 0 | 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 | 14 |0 0 0 0 0 0 0 1| 2703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 The WAN-Error-Nofity AVP encodes line and other errors sent by the 2706 LAC to the LNS. The flags indicate a mandatory option. 2708 Call Errors AVP 2710 0 1 2 3 2711 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 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 | 32 | 0 | 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 | 14 |0 0 0 0 0 0 0 1| Reserved | 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 | CRC Errors | 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 | Framing Errors | 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 | Hardware Overruns | 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | Buffer Overruns | 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | Time-out Errors | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | Alignment Errors | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 The Call Errors AVP is used by the LAC to send error information to 2731 the LNS. The flags indicate a mandatory option. The value contains 2732 the following fields: 2734 Reserved - Not used 2735 CRC Errors - Number of PPP frames received with CRC errors since 2736 session was established 2737 Framing Errors - Number of improperly framed PPP packets received 2738 Hardware Overruns - Number of receive buffer over-runs since ses- 2739 sion was established 2740 Buffer Overruns - Number of buffer over-runs detected since ses- 2741 sion was established 2742 Time-out Errors - Number of time-outs since call was established 2743 Alignment Errors - Number of alignment errors since call was 2744 established 2746 This AVP must be present. 2748 6.16 Set-Link-Info 2749 The Set-Link-Info message is a L2TP control message sent by the LNS 2750 to the LAC to set PPP-negotiated options. Because these options can 2751 change at any time during the life of the call, the LAC must be able 2752 to update its internal call information dynamically and perform PPP 2753 negotiation on an active PPP session. The message is structured as: 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 | L2TP Control Message Header | 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758 | Set-Link-Info | 2759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 | ACCM | 2761 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 Set-Link-Info AVP 2765 0 1 2 3 2766 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 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | 7 | 0 | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770 | 15 |0 0 0 0 0 0 0 1| 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 The Set-Link-Info AVP encodes ACCM information sent from the LNS to 2774 the LAC after it is negotiated in LCP. The flags indicate a manda- 2775 tory option. 2777 ACCM AVP 2779 0 1 2 3 2780 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 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 | 32 | 0 | 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 | 14 |0 0 0 0 0 0 0 1| Reserved | 2785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 | Send ACCM | 2787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2788 | Receive ACCM | 2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. 2792 The flags indicate a mandatory option. The value contains Send ACCM 2793 and Receive ACCM fields. The send ACCM value should be used by the 2794 LAC to process packets it is sends on the connection. The receive 2795 ACCM value should be used by the LAC to process incoming packets on 2796 the connection. The default values used by the LAC for both these 2797 fields are 0xFFFFFFFF. This AVP must be present. 2799 6.17 No-op 2801 The No-op message is a L2TP control message sent by either side. Its 2802 primary purpose is to update the Acknowledgment window for the peer 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 | L2TP Control Message Header | 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 | No-op | 2807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 No-op AVP 2811 0 1 2 3 2812 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 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2814 | 7 | 0 | 2815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2816 | 16 |0 0 0 0 0 0 0 1| 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 The Value is set to 16, indicating No-op. The flags indicate a 2820 mandatory option. 2822 7.0 Control Connection State Machines 2824 The control messages defined in section 6 are exchanged by way of state 2825 tables defined in this section. Tables are defined for incoming call 2826 placement, outgoing call placement, as well as for initiation of the 2827 tunnel itself. The state tables do not encode timeout and retransmis- 2828 sion behavior, as this is handled in the underlying semantics defined in 2829 6.0.2. 2831 7.1 Control Connection Protocol Operation 2833 This section describes the operation of various L2TP control connec- 2834 tion functions and the Control Connection messages which are used to 2835 support them. 2837 Receipt of an invalid or malformed Control Connection message should 2838 be logged appropriately, and the control connection should be closed 2839 and restarted to ensure recovery into a known state. 2841 7.2 Control Connection States 2843 The control connection relies on a standard TCP connection for its 2844 service. The L2TP control connection protocol is not distinguishable 2845 between the LNS and LAC, but is distinguishable between the origina- 2846 tor and receiver. The originating peer is the one which first estab- 2847 lishes the tunnel. Since either LAC or LNS can be the originator, a 2848 collision can occur. See Section 6.0.1 for a description of this and 2849 its resolution situation. 2851 7.2.1 Control Connection Originator (may be LAC or LNS) 2853 State Event Action New State 2854 ----- ----- ------ --------- 2856 idle Open request Send wait_ctl_reply 2857 Start-Control- 2858 Connection-Request 2860 wait_ctl_reply Collision If terminating, idle 2861 clean-up. 2863 wait_ctl_reply Receive If version OK established 2864 Start-Control- Send Start-Control- 2865 Connection-Reply Connected-Connected 2867 wait_ctl_reply Receive If version not OK wait_stop_reply 2868 Start-Control- or bad auth, Send 2869 Connection-Reply Stop-Control- 2870 -Connection-Request 2872 established Local terminate Send 2873 Stop-Control- wait_stop_reply 2874 -Connection-Request 2876 wait_stop_reply Receive clean-up idle 2877 Stop-Control- 2878 Connection-Reply 2880 idle 2881 The control connection originator attempts to open a connection to 2882 the peer during idle state. When the connection is open, the 2883 originator transmits a send Start-Control-Connection-Request and 2884 then enters the wait_ctl_reply state. 2886 wait_ctl_reply 2887 The originator checks to see if another connection has been 2888 requested from the same peer, and if so, handles the collision 2889 situation described in Section 6.0.1. 2891 When a Start-Control-Connection-Reply is received, it is examined 2892 for a compatible version. If the version of the reply is lower 2893 than the version sent in the request, the older (lower) version 2894 should be used provided it is supported. If the version in the 2895 reply is earlier and supported, the originator moves to the estab- 2896 lished state. If the version is earlier and not supported, a 2897 Stop-Control-Connection- Request SHOULD be sent to the peer and 2898 the originator moves into the wait_stop_reply state. 2900 established 2901 An established connection may be terminated by either a local con- 2902 dition or the receipt of a Stop-Control-Connection-Request. In 2903 the event of a local termination, the originator MUST send a Stop- 2904 Control-Connection-Request and enter the wait_stop_reply state. 2906 If the originator receives a Stop-Control-Connection-Request it 2907 SHOULD send a Stop-Control-Connection-Reply and close the connec- 2908 tion. 2910 wait_stop_reply 2911 If a Stop-Control-Connection-Reply is received, the connection 2912 SHOULD be closed and the control connection becomes idle. 2914 7.2.2 Control connection Receiver (may be LAC or LNS) 2916 State Event Action New State 2917 ----- ----- ------ --------- 2918 idle Receive If version not OK idle 2919 Start-Control- send 2920 Connection-Request Start-Control- 2921 Connection-Reply 2922 with error 2924 idle Receive Version OK, send established 2925 Start-Control- Start-Control- 2926 Connection-Request Connection-Reply 2928 wait_ctl_reply Receive clean-up, send idle 2929 Stop-Control- Stop-Control- 2930 Connection-Request Connection-Reply 2932 wait_ctl_reply Receive If auth OK idle 2933 Start-Control- 2934 Connection- 2935 Connected 2937 wait_ctl_reply Receive If auth not OK wait-stop-reply 2938 Start-Control- Send Stop-Control- 2939 Connection- Connection-Request 2940 Connected 2942 established Receive clean-up, send idle 2943 Stop-Control- Stop-Control- 2944 Connection-Request Connection-Reply 2946 established Local terminate Send wait-stop-reply 2947 Start-Control- 2948 Connection-Request 2950 wait-stop-reply Receive clean-up idle 2951 Stop-Control- 2952 Connection-Reply 2954 idle 2955 The control connection receiver waits for an incoming connection 2956 attempt. When notified of an new connection, it should prepare to 2957 receive L2TP messages. When a Start-Control-Connection-Request is 2958 received its version field should be examined. If the version is 2959 earlier than the receiver's version and the earlier version can be 2960 supported by the receiver, the receiver SHOULD send a Start-Control- 2961 Connection-Reply. 2963 If the version is earlier than the receiver's 2964 version and the version cannot be supported, the receiver SHOULD send 2965 a Start- Connection-Reply message, close the TCP connection and 2966 remain in the idle state. If the receiver's version is the same as 2967 earlier than the peer's, the receiver SHOULD send a Start-Control- 2968 Connection-Reply with the receiver's version and enter the 2969 established state. 2971 established 2972 An established connection may be terminated by either a local 2973 condition or the reception of a Stop-Control-Connection-Request. In 2974 the event of a local termination, the originator MUST send a Stop- 2975 Control-Connection-Request and enter the wait_stop_reply state. 2977 If the originator receives a Stop-Control-Connection-Request it 2978 SHOULD send a Stop-Control-Connection-Reply and close the 2979 connection. 2981 wait_stop_reply 2982 If a Stop-Control-Connection-Reply is received, the connection 2983 SHOULD be closed and the control connection becomes idle. 2985 7.3 Timing considerations 2987 Because of the real-time nature of telephone signaling, both the LNS 2988 and LAC should be implemented with multi-threaded architectures such 2989 that messages related to multiple calls are not serialized and 2990 blocked. 2991 The call and connection state figures do not specify 2992 exceptions caused by timers. These are addressed in Section 6.0.2. 2994 7.4 Incoming calls 2996 An Incoming-Call-Request message is generated by the LAC when an 2997 associated telephone line rings. The LAC selects a Call ID and serial 2998 number and indicates the call bearer type. Modems should always 2999 indicate analog call type. ISDN calls should indicate digital when 3000 unrestricted digital service or rate adaption is used and analog if 3001 digital modems are involved. Dialing number, dialed number, and 3002 subaddress may be included in the message if they are available from 3003 the telephone network. 3005 Once the LAC sends the Incoming-Call-Request, it waits for a response 3006 from the LNS but does not answer the call from the telephone network. 3007 The LNS may choose not to accept the call if: 3009 - No resources are available to handle more sessions 3010 - The dialed, dialing, or subaddress fields are not indicative of 3011 an authorized user 3012 - The bearer service is not authorized or supported 3014 If the LNS chooses to accept the call, it responds with an Outgoing- 3015 Call-Reply which also indicates window sizes (see Appendix B). When 3016 the LAC receives the Outgoing-Call-Reply, it attempts to connect the 3017 call, assuming the calling party has not hung up. A final call 3018 connected message from the LAC to the LNS indicates that the call 3019 states for both the LAC and the LNS should enter the established 3020 state. 3022 When the dialed-in client hangs up, the call is cleared normally and 3023 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 3024 clear a call, it sends a Call-Clear-Request message and then waits 3025 for a Call-Disconnect-Notify. 3027 State Event Action New State 3028 ----- ----- ------ --------- 3029 idle Ring OR Send wait_reply 3030 Ready to indicate Incoming-Call-Request 3031 incoming conn. 3033 wait-reply Receive clean-up idle 3034 Incoming-Call-Reply 3035 Not Accepting 3037 wait-reply Receive Answer call established 3038 Incoming-Call-Reply Send 3039 Accepting Incoming-Call-Connected 3041 wait-reply Abort, Send clean-up idle 3042 Call-Disconnect- 3043 Notify 3045 established Receive Hang-up and send idle 3046 Clear-Call-Request Call-Disconnect-Notify 3048 established telco line drop Send idle 3049 Call-Disconnect-Notify 3051 established local disconnect Send idle 3052 Call-Disconnect-Notify 3054 The states associated with the LAC for incoming calls are: 3056 idle 3058 The LAC detects an incoming call on one of its telco interfaces. 3059 Typically this means an analog line is ringing or an ISDN TE has 3060 detected an incoming Q.931 SETUP message. The LAC sends an Incom- 3061 ing- Call-Request message and moves to the wait_reply state. 3063 wait_reply 3065 The LAC receives an Incoming-Call-Reply message indicating non- 3066 willingness to accept the call (general error or don't accept) and 3067 moves back into the idle state. If the reply message indicates 3068 that the call is accepted, the LAC sends an Incoming-Call- 3069 Connected message and enters the established state. 3071 established 3072 Data is exchanged over the tunnel. The call may be cleared fol- 3073 lowing: 3074 An event on the telco connection. The LAC sends a Call- Dis- 3075 connect-Notify message 3076 Receipt of a Call-Clear-Request. The LAC sends a Call- 3077 Disconnect- Notify message 3078 A local reason. The LAC sends a Call-Disconnect-Notify mes- 3079 sage. 3081 7.5 LNS Incoming Call States 3083 State Event Action New State 3084 ----- ----- ------ --------- 3085 idle Receive If not accepting idle 3086 Incoming-Call-Request Send 3087 Incoming-Call-Reply 3088 with Error 3090 idle Receive If accepting wait-connect 3091 Incoming-Call-Request Send 3092 Incoming-Call-Reply 3094 wait-connect Receive clean-up idle 3095 Call-Disconnect-Notify 3097 wait-connect Receive get ready for data established 3098 Incoming-Call-Connect 3100 established Receive clean-up idle 3101 Call-Disconnect-Notify 3103 established Local terminate Send wait- 3104 Clear-Call-Request disconnect 3106 wait- Receive clean-up idle 3107 disconnect Call-Disconnect-Notify 3109 The states associated with the LNS for incoming calls are: 3111 idle 3113 An Incoming-Call-Request message is received. If the request is 3114 not acceptable, an Incoming-Call-Reply is sent back to the LAC and 3115 the LNS remains in the idle state. If the Incoming-Call-Request 3116 message is acceptable, an Incoming-Call-Reply is sent indicating 3117 accept in the result code. The session moves to the wait_connect 3118 state. 3120 wait_connect 3122 If the session is connected on the LAC, the LAC sends an incoming 3123 call connect message to the LNS which then moves into established 3124 state. The LAC may send a Call-Disconnect-Notify to indicate that 3125 the incoming caller could not be connected. This could happen, 3126 for example, if a telephone user accidently places a standard 3127 voice call to a LAC resulting in a handshake failure on the called 3128 modem. 3130 established 3132 The session is terminated either by receipt of a Call-Disconnect- 3133 Notify message from the LAC or by sending a Call-Clear-Request. 3134 Once a Call-Clear-Request has been sent, the session enters the 3135 wait_disconnect state. 3137 wait_disconnect 3139 Once a Call-Disconnect-Notify is received the session moves back 3140 to the idle state. 3142 7.6 Outgoing calls 3144 Outgoing messages are initiated by a LNS and instruct a LAC to place a 3145 call on a telco interface. There are only two messages for outgoing 3146 calls: Outgoing-Call-Request and Outgoing-Call-Reply. The LNS sends an 3147 Outgoing-Call-Request specifying the dialed party phone number and sub- 3148 address as well as speed and window parameters. The LAC MUST respond to 3149 the Outgoing-Call-Request message with an Outgoing-Call- Reply message 3150 once the LAC determines that: 3152 The call has been successfully connected 3153 A call failure has occurred for reasons such as: no interfaces are 3154 available for dial-out, the called party is busy or does not 3155 answer, or no dial tone is detected on the interface chosen for 3156 dialing 3158 3.2.4.1 LAC Outgoing Call States 3160 State Event Action New State 3161 ----- ----- ------ --------- 3162 idle Receive If cannot service wait_cs_ans 3163 Outgoing-Call-Request send 3164 Outgoing-Call-Reply 3165 with Error 3167 idle Receive If can service, dial, idle 3168 Outgoing-Call- send 3169 Request Outgoing-Call-Reply 3171 wait_cs_ans Telco answer Send established 3172 Outgoing-Call-Reply 3174 wait_cs_ans Call failure Send 3175 Outgoing-Call-Reply idle 3176 with Error 3178 wait_cs_ans Receive Hang-up, send idle 3179 Clear-Call-Request Call-Disconnect-Notify 3181 established Receive Hang-up, send idle 3182 Clear-Call-Request Call-Disconnect-Notify 3184 The states associated with the LAC for outgoing calls are: 3186 idle 3188 Received Outgoing-Call-Request. If this is received in error, 3189 respond with an Outgoing-Call-Reply with error condition set. 3190 Otherwise, allocate physical channel to dial on. Place the out- 3191 bound call, wait for a connection, and move to the wait_cs_ans 3192 state. 3194 wait_cs_ans 3196 If the call is incomplete, send an Outgoing-Call-Reply with a non- 3197 zero Error Code. If a timer expires on an outbound call, send 3198 back an Outgoing-Call-Reply with a non-zero Error Code. If a cir- 3199 cuit switched connection is established, send an Outgoing-Call- 3200 Reply indicating success. 3202 established 3204 If a Call-Clear-Request is received, the telco call SHOULD be 3205 released via appropriate mechanisms and a Call-Disconnect-Notify 3206 message SHOULD BE sent to the LNS. If the call is disconnected by 3207 the client or by the telco interface, a Call-Disconnect-Notify 3208 message SHOULD be sent to the LNS. 3210 7.7 LNS Outgoing Call States 3212 State Event Action New State 3213 ----- ----- ------ --------- 3214 idle Open request Send wait-reply 3215 Outgoing-Call-Request 3217 wait-reply Receive clean-up idle 3218 Outgoing-Call-Reply 3219 with Error 3221 wait-reply Receive get ready for data established 3222 Outgoing-Call-Reply 3224 wait-reply Abort request Send wait-disconnect 3225 Clear-Call-Request 3227 established Receive clean-up idle 3228 Call-Disconnect-Notify 3230 established Local terminate Send wait-disconnect 3231 Clear-Call-Request 3233 wait-disconnect Receive clean-up idle 3234 Call-Disconnect- 3235 Notify 3237 The states associated with the LNS for outgoing calls are: 3239 idle 3240 An Outgoing-Call-Request message is sent to the LAC and the ses- 3241 sion moves into the wait_reply state. 3243 wait_reply 3244 An Outgoing-Call-Reply is received which indicates an error. The 3245 session returns to idle state. No telco call is active. If the 3246 Outgoing-Call-Reply does not indicate an error, the telco call is 3247 connected and the session moves to the established state. 3249 established 3250 If a Call-Disconnect-Notify is received, the telco call has been 3251 terminated for the reason indicated in the Result and Cause Codes. 3252 The session moves back to the idle state. If the LNS chooses to 3253 terminate the session, it sends a Call-Clear-Request to the LAC 3254 and then enters the wait_disconnect state. 3256 wait_disconnect 3257 A session disconnection is waiting to be confirmed by the LAC. 3258 Once the LNS receives the Call-Disconnect-Notify message, the ses- 3259 sion enters idle state. 3261 10.0 Acknowledgments 3263 The AVP construct comes from Glen Zorn, who thought up the framework 3264 for permitting multiple vendors to contribute to a common attribute 3265 space in a relatively orderly fashion. 3267 11.0 Contacts 3269 Kory Hamzeh 3270 Ascend Communications 3271 1275 Harbor Bay Parkway 3272 Alameda, CA 94502 3273 kory@ascend.com 3275 Tim Kolar, Morgan Littlewood, Andrew J. Valencia 3276 Cisco Systems 3277 170 West Tasman Drive 3278 San Jose CA 95134-1706 3279 tkolar@cisco.com 3280 littlewo@cisco.com 3281 vandys@cisco.com 3283 Gurdeep Singh Pall 3284 Microsoft Corporation 3285 Redmond, WA 3286 gurdeep@microsoft.com 3287 Jeff Taarud 3288 (formerly of 3COM Corporation, no current contact) 3290 William Verthein 3291 U.S. Robotics 3293 12.0 References 3295 TBD 3297 Appendix A: Acknowledgment Time-Outs 3299 L2TP uses sliding windows and time-outs to provide both user session 3300 flow-control across the internetwork and to perform efficient data 3301 buffering to keep the LAC-LNS data channels full without causing 3302 receive buffer overflow. L2TP requires that a time-out be used to 3303 recover from dropped data or acknowledgment packets. The exact 3304 implementation of the time-out is vendor-specific. It is suggested 3305 that an adaptive time-out be implemented with backoff for congestion 3306 control. The time-out mechanism proposed here has the following 3307 properties: 3309 Independent time-outs for each session. A device (LAC or LNS) 3310 will have to maintain and calculate time-outs for every active 3311 session. 3313 An administrator-adjustable maximum time-out, MaxTimeOut, unique 3314 to each device. 3316 An adaptive time-out mechanism that compensates for changing 3317 throughput. To reduce packet processing overhead, vendors may 3318 choose not to recompute the adaptive time-out for every received 3319 acknowledgment. The result of this overhead reduction is that the 3320 time-out will not respond as quickly to rapid network changes. 3322 Timer backoff on time-out to reduce congestion. The backed-off 3323 timer value is limited by the configurable maximum time-out value. 3324 Timer backoff is done every time an acknowledgment time-out 3325 occurs. 3327 In general, this mechanism has the desirable behavior of quickly 3328 backing off upon a time-out and of slowly decreasing the time-out 3329 value as packets are delivered without time-outs. 3331 Some definitions: 3333 Packet Processing Delay (PPD) is the amount of time required for 3334 each side to process the maximum amount of data buffered in their 3335 receive packet sliding window. The PPD is the value exchanged 3336 between the LAC and LNS when a call is established. For the LNS, 3337 this number should be small. For a LAC making modem connections, 3338 this number could be significant. 3340 Sample is the actual amount of time incurred receiving an 3341 acknowledgment for a packet. The Sample is measured, not calcu- 3342 lated. 3344 Round-Trip Time (RTT) is the estimated round-trip time for an 3345 Acknowledgment to be received for a given transmitted packet. 3346 When the network link is a local network, this delay will be mini- 3347 mal (if not zero). When the network link is the Internet, this 3348 delay could be substantial and vary widely. RTT is adaptive: it 3349 will adjust to include the PPD and whatever shifting network 3350 delays contribute to the time between a packet being transmitted 3351 and receiving its acknowledgment. 3353 Adaptive Time-Out (ATO) is the time that must elapse before an 3354 acknowledgment is considered lost. After a time-out, the sliding 3355 window is partially closed and the ATO is backed off. 3357 Packet Processing Delay (PPD) 3359 The PPD parameter is a 16-bit word exchanged during the Call Control 3360 phase that represents tenths of a second (64 means 6.4 seconds). The 3361 protocol only specifies that the parameter is exchanged, it does not 3362 specify how it is calculated. The way values for PPD are calculated 3363 is implementation-dependent and need not be variable (static time- 3364 outs are allowed). The PPD must be exchanged in the call connect 3365 sequences, even if it remains constant in an implementation. One 3366 possible way to calculate the PPD is: 3368 PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 3369 PPD = PPD' + LACFudge 3371 Header is the total size of the IP and GRE headers, which is 36. The 3372 MTU is the overall MTU for the internetwork link between the LAC and 3373 LNS. WindowSize represents the number of packets in the sliding win- 3374 dow, and is implementation-dependent. The latency of the internet- 3375 work could be used to pick a window size sufficient to keep the cur- 3376 rent session's pipe full. The constant 8 converts octets to bits 3377 (assuming ConnectRate is in bits per second). If ConnectRate is in 3378 bytes per second, omit the 8. LACFudge is not required but can be 3379 used to take overall processing overhead of the LAC into account. 3381 The value of PPD is used to seed the adaptive algorithm with the ini- 3382 tial RTT[n-1] value. 3384 Sample 3386 Sample is the actual measured time for a returned acknowledgment. 3388 Round-Trip Time (RTT) 3390 The RTT value represents an estimate of the average time it takes for 3391 an acknowledgment to be received after a packet is sent to the remote 3392 end of the tunnel. 3394 A.1 Calculating Adaptive Acknowledgment Time-Out 3395 We still must decide how much time to allow for acknowledgments to 3396 return. If the time-out is set too high, we may wait an unnecessar- 3397 ily long time for dropped packets. If the time-out is too short, we 3398 may time out just before the acknowledgment arrives. The acknowledg- 3399 ment time-out should also be reasonable and responsive to changing 3400 network conditions. 3402 The suggested adaptive algorithm detailed below is based on the TCP 3403 1989 implementation and is explained in Richard Steven's book TCP/IP 3404 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 3405 calculation, and 'n-1' refers to values from the last calculation. 3407 DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta * 3408 (|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 3409 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 3411 DIFF represents the error between the last estimated round-trip 3412 time and the measured time. DIFF is calculated on each iteration. 3414 DEV is the estimated mean deviation. This approximates the stan- 3415 dard deviation. DEV is calculated on each iteration and stored 3416 for use in the next iteration. Initially, it is set to 0. 3418 RTT is the estimated round-trip time of an average packet. RTT is 3419 calculated on each iteration and stored for use in the next itera- 3420 tion. Initially, it is set to PPD. 3422 ATO is the adaptive time-out for the next transmitted packet. ATO 3423 is calculated on each iteration. Its value is limited, by the MIN 3424 function, to be a maximum of the configured MaxTimeOut value. 3426 Alpha is the gain for the average and is typically 1/8 (0.125). 3428 Beta is the gain for the deviation and is typically 1/4 (0.250). 3430 Chi is the gain for the time-out and is typically set to 4. 3432 To eliminate division operations for fractional gain elements, the 3433 entire set of equations can be scaled. With the suggested gain con- 3434 stants, they should be scaled by 8 to eliminate all division. To 3435 simplify calculations, all gain values are kept to powers of two so 3436 that shift operations can be used in place of multiplication or divi- 3437 sion. 3439 A.2 Congestion Control: Adjusting for Time-Out 3441 This section describes how the calculation of ATO is modified in the 3442 case where a time-out does occur. When a time-out occurs, the time- 3443 out value should be adjusted rapidly upward. Although the GRE pack- 3444 ets are not retransmitted when a time-out occurs, the time-out should 3445 be adjusted up toward a maximum limit. To compensate for shifting 3446 internetwork time delays, a strategy must be employed to increase the 3447 time-out when it expires. A simple formula called Karn's Algorithm 3448 is used in TCP implementations and may be used in implementing the 3449 backoff timers for the LNS or the LAC. Notice that in addition to 3450 increasing the time-out, we are also shrinking the size of the window 3451 as described in the next section. 3453 Karn's timer backoff algorithm, as used in TCP, is: 3455 NewTIMEOUT = delta * TIMEOUT 3457 Adapted to our time-out calculations, for an interval in which a 3458 time-out occurs, the new ATO is calculated as: 3460 RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MIN (RTT[n] + 3461 (chi * DEV[n]), MaxTimeOut) 3463 In this modified calculation of ATO, only the two values that con- 3464 tribute to ATO and that are stored for the next iteration are calcu- 3465 lated. RTT is scaled by chi, and DEV is unmodified. DIFF is not 3466 carried forward and is not used in this scenario. A value of 2 for 3467 Delta, the time-out gain factor for RTT, is suggested. 3469 Appendix B: Acknowledgment Time-Out and Window Adjustment 3471 B.1 Initial Window Size 3473 Although each side has indicated the maximum size of its receive win- 3474 dow, it is recommended that a slow start method be used to begin 3475 transmitting data. The initial window size on the transmitter is set 3476 to half the maximum size the receiver requested, with a minimum size 3477 of one packet. The transmitter stops sending packets when the number 3478 of packets awaiting acknowledgment is equal to the current window 3479 size. As the receiver successfully digests each window, the window 3480 size on the transmitter is bumped up by one packet until the maximum 3481 is reached. This method prevents a system from flooding an already 3482 congested network because no history has been established. 3484 B.2 Closing the Window 3486 When a time-out does occur on a packet, the sender adjusts the size 3487 of the transmit window down to one half its value when it failed. 3488 Fractions are rounded up, and the minimum window size is one. 3490 B.3 Opening the Window 3492 With every successful transmission of a window's worth of packets 3493 without a time-out, the transmit window size is increased by one 3494 packet until it reaches the maximum window size that was sent by the 3495 other side when the call was connected. As stated earlier, no 3496 retransmission is done on a time-out. After a time-out, the trans- 3497 mission resumes with the window starting at one half the size of the 3498 transmit window when the time-out occurred and adjusting upward by 3499 one each time the transmit window is filled with packets that are all 3500 acknowledged without time-outs. 3502 B.4 Window Overflow 3503 When a receiver's window overflows with too many incoming packets, 3504 excess packets are thrown away. This situation should not arise if 3505 the sliding window procedures are being properly followed by the 3506 transmitter and receiver. It is assumed that, on the transmit side, 3507 packets are buffered for transmission and are no longer accepted from 3508 the packet source when the transmit buffer fills. 3510 8.0 L2TP Over Specific Media 3512 L2TP tries to be self-describing, operating at a level above the par- 3513 ticular media over which it is carried. However, some details of its 3514 connection to media are required to permit interoperable implementa- 3515 tions. The following sections describe details needed to permit 3516 interoperability over specific media. 3518 8.1 IP/UDP 3520 L2TP uses the well-known UDP port 1701 [3]. The entire L2TP packet, 3521 including payload and L2TP header, is sent within a UDP datagram. 3522 The source and destination ports are the same (1701), with demulti- 3523 plexing being achieved using Tunnel ID values. It is legal for the 3524 source IP address of a given Tunnel ID to change over the life of a 3525 connection, as this may correspond to a peer with multiple IP inter- 3526 faces responding to a network topology change. Responses should 3527 reflect the last source IP address for that Tunnel ID. 3529 IP fragmentation may occur as the L2TP packet travels over the IP 3530 sub- strate. L2TP makes no special efforts to optimize this. A LAC 3531 imple- mentation MAY cause its LCP to negotiate for a specific MRU, 3532 which could optimize for LAC environments in which the MTUs of the 3533 path over which the L2TP packets are likely to travel have a consis- 3534 tent value. 3536 Port 1701 is used for both L2F [XXX] and L2TP packets. The two types 3537 of packets may be detected by their headers; L2TP has a Vers field of 3538 2, L2F has a 1 in this field instead. 3540 8.2 IP 3542 When operating directly over IP, protocol number TBD [3] is used to 3543 encode the packet as L2TP-over-IP. IP source address and MTU issues 3544 are identical to 8.1, except that the lack of a UDP header makes the 3545 packet more compact. 3547 9.0 Security Considerations 3549 L2TP encounters several security issues in its operation. The gen- 3550 eral approach of L2TP to these issues is documented here. 3552 9.1 Tunnel Endpoint Security 3554 The tunnel endpoints may authenticate each other during tunnel 3555 establishment. This authentication has the same security 3556 attributes as CHAP, and has reasonable protection against reply 3557 and snooping. 3559 Once the tunnel endpoints have authenticated, a derived Key may be 3560 carried in subsequent packets, which provides mild protection 3561 against brief or "accidental" attacks. There is no cryptographic 3562 strength to these Keys, and any attacker which can snoop packets 3563 can take control of the tunnel. 3565 For L2TP tunnels over IP, IP-level packet security provides very 3566 strong protection of the tunnel. This requires no modification to 3567 the L2TP protocol, and leverages extensive IETF work in this area. 3569 For L2TP tunnels over Frame Relay or other switched networks, cur- 3570 rent practice indicates that these media are much less likely to 3571 experience attacks of in-transit data. If these attacks became 3572 prevalent, either the media or the L2TP packets would have to be 3573 encrypted. 3575 9.2 Client Security 3577 A more systematic method of protection in tunneled PPP environ- 3578 ments may be achieved through client security. PPP layer encryp- 3579 tion would provide end-to-end security for both direct dial-in 3580 clients as well as PPP clients carried within a tunnel. With this 3581 level of client security, sessions are protected against attacks 3582 against the carrying tunnel, as well as attacks on the LAC itself. 3583 Because both encryption and compression can occur at the PPP 3584 layer, the two can be coordinated, permitting compression to pre- 3585 cede encryption. 3587 The optional proxy CHAP function of L2TP can permit an entirely 3588 transparent PPP tunnel, with a single LCP and CHAP sequence being 3589 seen by the client. For cases where the LAC and the entire path 3590 to the LNS are operated by a single entity, this function may pro- 3591 vide acceptable security. For cases where LNS-initiated authenti- 3592 cation is required, proxy CHAP still permits an initial access 3593 decision to be made before accepting the tunnel, permitting the 3594 LNS in most cases to reject tunnel initiations rather than accept 3595 them and later disconnect.