idnits 2.17.1 draft-ietf-pppext-l2tp-01.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-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 74 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 75 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 61 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 152: '... o MUST, SHALL, or MANDATORY --...' RFC 2119 keyword, line 155: '... o SHOULD or RECOMMEND -- This ...' RFC 2119 keyword, line 158: '... o MAY or OPTIONAL -- This item...' RFC 2119 keyword, line 637: '... tions MUST implement flow contro...' RFC 2119 keyword, line 651: '...the sending peer MUST NOT clear a sess...' (99 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3384 has weird spacing: '...or data est...' == Line 3391 has weird spacing: '...Request dis...' == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'H' on line 333 -- Looks like a reference, but probably isn't: 'R' on line 335 -- Looks like a reference, but probably isn't: 'U' on line 336 -- Looks like a reference, but probably isn't: 'L' on line 334 -- Looks like a reference, but probably isn't: 'N' on line 337 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1340 (ref. '5') (Obsoleted by RFC 1700) -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-02) exists of draft-grant-tacacs-00 -- Possible downref: Normative reference to a draft: ref. '7' -- Unexpected draft version: The latest known version of draft-ietf-radius-radius is -04, but you're referring to -05. Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group Kory Hamzeh 2 INTERNET-DRAFT Ascend Communications 3 Category: Internet Draft Tim Kolar 4 Title: draft-ietf-pppext-l2tp-01.txt Cisco Systems 5 Date: December 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 Hello 78 6.7 (deleted) 79 6.8 Outgoing-Call-Request 80 6.9 Outgoing-Call-Reply 81 6.10 Outgoing-Call-Connected 82 6.11 Incoming-Call-Request 83 6.12 Incoming-Call-Reply 84 6.13 Incoming-Call-Connected 85 6.14 Call-Clear-Request 86 6.15 Call-Disconnect-Notify 87 6.16 WAN-Error-Notify 88 6.17 Set-Link-Info 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 93 7.2.2 Control connection Receiver 94 7.3 Timing considerations 95 7.4 Incoming Calls 96 7.4.1 LAC Incoming Call States 97 7.4.2 LNS Incoming Call States 98 7.5 Outgoing calls 99 7.5.1 LAC Outgoing Call States 100 7.5.2 LNS Outgoing Call States 101 8.0 L2TP Over Specific Media 102 8.1 IP/UDP 103 8.2 IP 104 9.0 Security Considerations 105 9.1 Tunnel Endpoint Security 106 9.2 Client Security 107 10.0 Acknowledgments 108 11.0 Contacts 109 12.0 References 110 Appendix A: Acknowledgment Time-Outs 111 Appendix B: Acknowledgment Time-Out and Window Adjustment 112 Appendix C: Handling of out-of-order packets 113 Appendix D: Transport Layer Adaptive Time-Outs and Window Adjustment 115 1.0 Introduction 117 The traditional dial-up network service on the Internet is for regis- 118 tered IP addresses only. A new class of virtual dial-up application 119 which allows multiple protocols and unregistered IP addresses is also 120 desired on the Internet. Examples of this class of network applica- 121 tion are support for privately addressed IP, IPX, and AppleTalk dial- 122 up via PPP across existing Internet infrastructure. 124 The support of these multiprotocol virtual dial-up applications is of 125 significant benefit to end users, enterprises, and Internet Service 126 providers as it allows the sharing of very large investments in 127 access and core infrastructure and allows local calls to be used. It 128 also allows existing investments in non-IP protocol applications to 129 be supported in a secure manner while still leveraging the access 130 infrastructure of the Internet. 132 It is the purpose of this draft to identify the issues encountered in 133 integrating multiprotocol dial-up services into an existing Internet 134 Service Provider's Point of Presence (hereafter referred to as ISP 135 and POP, respectively), and to describe the L2TP protocol which per- 136 mits the leveraging of existing access protocols. 138 This protocol may also be used to solve the "multilink hunt-group 139 splitting" problem. Multilink PPP, often used to aggregate ISDN B 140 channels, requires that all channels composing a multilink bundle be 141 grouped at a single NAS. Because L2TP makes a PPP session appear at 142 a location other than the physical point at which the session was 143 physically received, it can be used to make all channels appear at a 144 single NAS, allowing multilink operation even when the physical calls 145 are spread across distinct physical NAS's. 147 1.1 Conventions 149 The following language conventions are used in the items of specifi- 150 cation in this document: 152 o MUST, SHALL, or MANDATORY -- This item is an absolute 153 requirement of the specification. 155 o SHOULD or RECOMMEND -- This item should generally be followed 156 for all but exceptional circumstances. 158 o MAY or OPTIONAL -- This item is truly optional and may be 159 followed or ignored according to the needs of the implementor. 161 1.2 Terminology 163 Analog Channel 165 A circuit-switched communication path which is intended to carry 166 3.1 Khz audio in each direction. 168 Digital Channel 170 A circuit-switched communication path which is intended to carry 171 digital information in each direction. 173 Call 175 A connection or attempted connection between two terminal end- 176 points on a PSTN or ISDN--for example, a telephone call between 177 two modems. 179 CHAP 181 Challenge Authentication Protocol, a PPP cryptographic chal- 182 lenge/response authentication protocol in which the cleartext 183 password is not passed in the clear over the line. 185 CLID 187 Calling Line ID, an indication to the receiver of a call as to the 188 phone number of the caller. 190 Control Messages 191 Control messages are exchanged between LAC, LNS pairs, and operate 192 in-band within the tunnel protocol. Control messages govern 193 aspects of the tunnel and sessions within the tunnel. 195 Dial User 197 An end-system or router attached to an on-demand PSTN or ISDN 198 which is either the initiator or recipient of a call. 200 DNIS 202 Dialed Number Information String, an indication to the receiver of 203 a call as to what phone number the caller used to reach it. 205 EAP 207 Extensible Authentication Protocol, a framework for a family of 208 PPP authentication protocols, including cleartext, chal- 209 lenge/response, and arbitrary dialog sequences. 211 L2TP Access Concentrator (LAC) 213 A device attached to one or more PSTN or ISDN lines capable of PPP 214 operation and of handling the L2TP protocol. The LAC needs only 215 implement the media over which L2TP is to operate to pass traffic 216 to one or more LNS's. It may tunnel any protocol carried within 217 PPP. 219 L2TP Network Server (LNS) 221 An LNS operates on any platform capable of PPP termination. The 222 LNS handles the server side of the L2TP protocol. Since L2TP 223 relies only on the single media over which L2TP tunnels arrive, 224 the LNS may have only a single LAN or WAN interface, yet still be 225 able to terminate calls arriving at any LAC's full range of PPP 226 interfaces (async, synchronous ISDN, V.120, etc.). 228 Network Access Server (NAS) 230 A device providing temporary, on-demand network access to users. 231 This access is point-to-point using PSTN or ISDN lines. 233 PAP 235 Password Authentication Protocol, a simple PPP authentication 236 mechanism in which a cleartext username and password are transmit- 237 ted to prove identity. 239 Session 241 L2TP is connection-oriented. The LNS and LAC maintain state for 242 each user that is attached to an LAC. A session is created when 243 an end-to-end PPP connection is attempted between a dial user and 244 the LNS, or when a outbound call is initiated. The datagrams 245 related to a session are sent over the tunnel between the LAC and 246 LNS. 248 Quality of Service (QOS) 250 A given Quality of Service level is sometimes required for a given 251 user being tunneled between an LNS-LAC pair. For this scenario, a 252 unique L2TP tunnel is created (generally on top of a new SVC) and 253 encapsulated directly on top of the media providing the indicated 254 QOS. 256 Switched Virtual Circuit (SVC) 258 An L2TP-compatible media on top of which L2TP is directly encapsu- 259 lated. SVC's are dynamically created, permitting tunnel media to 260 be created dynamically in response to desired LNS-LAC connectivity 261 requirements. 263 Tunnel 265 A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP 266 datagrams between the LAC and the LNS; many sessions can be multi- 267 plexed over a single tunnel. A control connection operating in- 268 band over the same tunnel controls the establishment, release, and 269 maintenance of sessions and of the tunnel itself. 271 2.0 Problem Space Overview 273 In this section we describe in high level terms the scope of the 274 problem that will be explored in more detail in later sections. 276 2.1 Initial Assumptions 278 We begin by assuming that Internet access is provided by an ISP and 279 that the ISP wishes to offer services other than traditional regis- 280 tered IP address based services to dial-up users of the network. 282 We also assume that the user of such a service wants all of the secu- 283 rity facilities that are available to him in a dedicated dial-up con- 284 figuration. In particular, the end user requires: 286 + End System transparency: Neither the remote end system nor his 287 home site hosts should require any special software to use this ser- 288 vice in a secure manner. 290 + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or 291 through other dialogs, for instance, a textual exchange on V.120 292 before starting PPP. This will include TACACS+ [7] and RADIUS [8] 293 solutions as well as support for smart cards and one-time passwords. 294 The authentication should be manageable by the user independently of 295 the ISP. 297 + Addressing should be as manageable as dedicated dial-up solutions. 298 The address should be assigned by the home site and not the ISP. 300 + Authorization should be managed by the home site as it would in a 301 direct dial-up solution. 303 + Accounting should be performed both by the ISP (for billing pur- 304 poses) and by the user (for charge-back and auditing). 306 2.2 Topology 308 Shown below is a generic Internet with Public switched Telephone Net- 309 work (PSTN) access (i.e., async PPP via modems) and Integrated Ser- 310 vices Digital Network (ISDN) access (i.e., synchronous PPP access). 311 Remote users (either async or ISDN PPP) will access the Home LAN as 312 if they were dialed into the L2TP Network Server (LNS), although 313 their physical dial-up is via the ISP Network Access Server. 315 ...----[L]----+---[L]-----... 316 | 317 | 318 [H] 319 | 320 ________|________________________ 321 | | 322 ________|__ ______|________ 323 | | | | 324 | PSTN [R] [R] ISDN | 325 | Cloud | | Cloud [N]__[U] 326 | | Internet | | 327 | | [R] | 328 [N]______[R] |_____________| 329 | | | 330 | | | 331 [U] |________________________________| 333 [H] = LNS 334 [L] = Home LAN(s) 335 [R] = Router 336 [U] = Remote User 337 [N] = ISP Network Access Server 339 2.3 Providing Virtual dial-up Services--a walk-through 341 To motivate the following discussion, this section walks through an 342 example of what might happen when a Virtual dial-up client initiates 343 access. 345 The remote user initiates a PPP connection to an ISP via either the 346 PSTN or ISDN. The Network Access Server (NAS) accepts the connection 347 and the PPP link is established (L2TP also permits the NAS to check 348 with an LNS after call indication prior to accepting the call--this 349 is useful where DNIS or CLID information is available in the incoming 350 call notification). 352 The ISP may now undertake a partial authentication of the end sys- 353 tem/user. Only the username field would be interpreted to determine 354 whether the user requires a Virtual dial-up service. It is 355 expected--but not required--that usernames will be structured (e.g. 356 username@company.com). Alternatively, the ISP may maintain a 357 database mapping users to services. In the case of Virtual dial-up, 358 the mapping will name a specific endpoint, the LNS. 360 Alternatively, the ISP may have already determined the target LNS 361 from DNIS. If the LNS is willing to accept tunnel creation without 362 any authentication of the caller, the NAS may tunnel the PPP connec- 363 tion without ever having communicated with the remote user. 365 If a virtual dial-up service is not required, standard access to the 366 Internet may be provided. 368 If no tunnel connection currently exists to the desired LNS, one is 369 initiated. L2TP is designed to be largely insulated from the details 370 of the media over which the tunnel is established; L2TP requires only 371 that the tunnel media provide packet oriented point-to-point connec- 372 tivity. Obvious examples of such media are UDP, Frame Relay PVC's, 373 or X.25 VC's. 375 Once the tunnel exists, an unused slot within the tunnel, a "Call 376 ID", is allocated, and a connect indication is sent to notify the LNS 377 of this new dial-up session. The LNS either accepts the connection, 378 or rejects it. Rejection may include a reason indication, which may 379 be displayed to the dial-up user, after which the call should be dis- 380 connected. 382 The initial setup notification may include the authentication infor- 383 mation required to allow the LNS to authenticate the user and decide 384 to accept or decline the connection. In the case of CHAP, the set-up 385 packet includes the challenge, username and raw response. For PAP or 386 text dialog, it includes username and clear text password. The LNS 387 may choose to use this information to complete its authentication, 388 avoiding an additional cycle of authentication. 390 If the LAC negotiated PPP LCP before initiating the tunnel, the ini- 391 tial setup notification may also include a copy of the LCP CONFACKs 392 sent in each direction which completed LCP negotiation. The LNS may 393 use this information to initialize its own PPP state (thus avoiding 394 an additional LCP negotiation), or it may choose to initiate a new 395 LCP CONFREQ exchange. 397 If the LNS accepts the connection, it creates a "virtual interface" 398 for PPP in a manner analogous to what it would use for a direct- 399 dialed connection. With this "virtual interface" in place, link 400 layer frames may now pass over this tunnel in both directions. 401 Frames from the remote user are received at the POP, stripped of any 402 link framing or transparency bytes, encapsulated in L2TP, and for- 403 warded over the appropriate tunnel. 405 The LNS accepts these frames, strips L2TP, and processes them as nor- 406 mal incoming frames for the appropriate interface and protocol. The 407 "virtual interface" behaves very much like a hardware interface, with 408 the exception that the hardware in this case is physically located at 409 the ISP POP. The other direction behaves analogously, with the LNS 410 encapsulating the packet in L2TP, and the NAS stripping L2TP before 411 transmitting it out the physical interface to the remote user. For 412 the remainder of this document, a NAS operating as a peer to an LNS 413 will be referred to as an L2TP Access Concentrator, or "LAC". 415 At this point, the connectivity is a point-to-point PPP session whose 416 endpoints are the remote user's networking application on one end and 417 the termination of this connectivity into the LNS's PPP support on 418 the other. Because the remote user has become simply another dial-up 419 client of the LNS, client connectivity can now be managed using tra- 420 ditional mechanisms with respect to further authorization, protocol 421 access, and packet filtering. 423 Accounting can be performed at both the LAC as well as the LNS. This 424 document illustrates some Accounting techniques which are possible 425 using L2TP, but the policies surrounding such Accounting are outside 426 the scope of this specification. 428 L2TP offers optional facilities which maximize compatibility with 429 legacy client requirements; L2TP connect notifications for PPP 430 clients can contain sufficient information for an LNS to authenticate 431 and initialize its LCP state machine. With these facilities, the 432 remote user need not be queried a second time for PPP authentication, 433 nor undergo multiple rounds of LCP negotiation and convergence. 434 These techniques are intended to optimize connection setup, and are 435 not intended to deprecate any functions required by the PPP specifi- 436 cation. 438 3.0 Service Model Issues 440 There are several significant differences between the standard Inter- 441 net access service and the Virtual dial-up service with respect to 442 authentication, address allocation, authorization and accounting. 443 The details of the differences between these services and the prob- 444 lems presented by these differences are described below. The mecha- 445 nisms used for Virtual Dial-up service are intended to coexist with 446 more traditional mechanisms; it is intended that an ISP's POP can 447 simultaneously service ISP clients as well as Virtual dial-up 448 clients. 450 3.1 Security 452 For the Virtual dial-up service, the ISP pursues authentication only 453 to the extent required to discover the user's apparent identity (and 454 by implication, their desired LNS). This may involve no more than 455 detecting DNIS information when a call arrives, or may involve full 456 LCP negotiation and initiation of PPP authentication. As soon as the 457 apparent identity is determined, a connection to the LNS is initiated 458 with any authentication information gathered by the ISP. The LNS 459 completes the authentication by either accepting the connection, or 460 rejecting it. 462 The LNS may need to protect against attempts by third parties to 463 establish tunnels to the LNS. Tunnel establishment can include 464 authentication to protect against such attacks. 466 3.2 Address Allocation 468 For an Internet service, the user accepts that the IP address may be 469 allocated dynamically from a pool of ISP addresses. This model often 470 means that the remote user has little or no access to their home net- 471 work's resources, due to firewalls and other security policies 472 applied by the home network to accesses from external IP addresses. 474 For the Virtual dial-up service, the LNS can exist behind the home 475 firewall, allocating addresses which are internal (and, in fact, can 476 be RFC1918 addresses, or non-IP addresses). Because L2TP tunnels 477 exclusively at the frame layer, the actual policies of such address 478 management are irrelevant to correct Virtual dial-up service; for all 479 purposes of PPP protocol handling, the dial-in user appears to have 480 connected at the LNS. 482 3.3 Authentication 484 The authentication of the user occurs in three phases; the first at 485 the ISP, and the second and optional third at the LNS. 487 The ISP uses DNIS, CLID, or username to determine that a Virtual 488 dial-up service is required and initiates the tunnel connection to 489 the appropriate LNS. Once a tunnel is established, The ISP NAS allo- 490 cates a new Call ID and initiates a session by forwarding the gath- 491 ered authentication information. 493 The LNS undertakes the second phase by deciding whether or not to 494 accept the connection. The connection indication may include CHAP, 495 PAP, EAP, or textual authentication information. Based on this 496 information, the LNS may accept the connection, or may reject it (for 497 instance, it was a PAP request and the username/password are found to 498 be incorrect). 500 Once the connection is accepted, the LNS is free to pursue a third 501 phase of authentication at the PPP layer. These activities are out- 502 side the scope of this specification, but might include an additional 503 cycle of LCP authentication, proprietary PPP extensions, or textual 504 challenges carried via a TCP/IP telnet session. 506 3.4 Accounting 508 It is a requirement that both the LAC and the LNS be capable of pro- 509 viding accounting data and hence both may count packets, octets and 510 connection start and stop times. 512 Since Virtual dial-up is an access service, accounting of connection 513 attempts (in particular, failed connection attempts) is of signifi- 514 cant interest. The LNS can reject new connections based on the 515 authentication information gathered by the LAC, with corresponding 516 logging. For cases where the LNS accepts the connection and then 517 continues with further authentication, the LNS might subsequently 518 disconnect the client. For such scenarios, the disconnection indica- 519 tion back to the LAC may also include a reason. 521 Because the LNS can decline a connection based on the authentication 522 information collected by the LAC, accounting can easily draw a dis- 523 tinction between a series of failed connection attempts and a series 524 of brief successful connections. Lacking this facility, the LNS must 525 always accept connection requests, and would need to exchange a num- 526 ber of PPP packets with the remote system. Note that the LNS could 527 use this information to decide to accept the connection (which pro- 528 tects against most invalid connection attempts) while still insisting 529 on running its own CHAP authentication (for instance, to protect 530 against CHAP replay attacks). 532 4.0 Protocol Overview 534 There are two parallel components of L2TP operating over a given tun- 535 nel: control messages between each LAC-LNS pair, and payload packets 536 between the same LAC-LNS pair. The latter are used to transport L2TP 537 encapsulated PPP packets for user sessions between the pair. 539 The Nr (Next Received) and Ns (Next Sent) fields are always present 540 in control messages, and are optionally present in payload messages. 541 Distinct sequence number state is maintained for control messages 542 related to the tunnel (Call ID is 0), and for each distinct user ses- 543 sion within the tunnel. Sequence number state is also distinct for 544 control and for payload messages within a particular session. Each 545 distinct state is initialized so the first packet is sent with an Ns 546 of 0. Nr is sent reflecting one more than the last in-order received 547 packet; if sent before any packet is received it would be 0, indicat- 548 ing that it expects the next new Ns value received to be 0. 550 The sequence number state is maintained and updated as packets are 551 sent. A message (control or payload) with a zero-length body indi- 552 cates that the packet is only used to communicate Nr and Ns fields. 553 The Nr and Ns fields are filled in as above, but the sequence number 554 state remains the same. For non-zero-length body messages, the 555 sequence number state is incremented (modulo 2**16) after it is 556 copied to the packet's Ns field. 558 4.1 Control Message Overview 560 Before PPP tunneling can occur between an LAC and LNS, control 561 messages must be exchanged between them. Control messages are 562 exchanged over the same tunnel which will be used to forward pay- 563 load data once L2TP call control and management information have 564 been passed. The control messages are responsible for establish- 565 ment, management, and release of sessions carried through the tun- 566 nel, as well as status on the tunnel itself. It is the means by 567 which an LNS is notified of an incoming call at an associated LAC, 568 as well as the means by which an LAC is instructed to place an 569 outgoing dial call. 571 A tunnel may be established by either an LAC (for incoming calls) 572 or an LNS (for outgoing calls). Following the establishment of 573 the tunnel, the LNS and LAC configure the tunnel by exchanging 574 Start-Control-Connection-Request and -Reply messages. These mes- 575 sages are also used to exchange information about basic operating 576 capabilities of the LAC and LNS. Once the control message 577 exchange is complete, the LAC may initiate sessions by indicating 578 inbound requests, or the LNS by requesting outbound calls. Con- 579 trol messages may indicate changes in operating characteristics of 580 an individual user session with a Set-Link-Info message. Individ- 581 ual sessions may be released by either the LAC or LNS, also 582 through control messages. 584 Independent Call ID values are established for each end of a user 585 session. The sender of a packet associated with a particular 586 session places the Call ID established by its peer in the Call ID 587 header field of all outgoing packets. For the cases where a Call 588 ID has not yet been assigned from the peer (i.e., during call 589 establishment of a new session), the Call ID field is sent as 0, 590 and further fields within the message are used to identify the 591 session. 593 Two mechanisms provide for detection of tunnel connectivity prob- 594 lems, one by the reliable transport layer of L2TP and another by 595 the higher layer. The transport layer of L2TP performs control 596 message retransmission. If the number of retransmission attempts 597 for a given control message exceeds a configured maximum value, 598 the tunnel is reset. This retransmission mechanism exists in both 599 the LNS and LAC ends of the tunnel. In addition, keepalive con- 600 trol echo messages are injected into the control stream by the 601 higher L2TP layer after a certain duration of inactivity on a 602 given tunnel is detected. A response to the sent keepalive is 603 expected within a configured time interval. If not received 604 within the allowed time interval, the tunnel is reset. These two 605 mechanisms ensure that a connectivity failure between the LNS and 606 the LAC can be detected at either end of a tunnel in a timely man- 607 ner. 609 It is intended that control messages will also carry management 610 related information in the future, such as a message allowing the 611 LNS to request the status of a given LAC; these message types are 612 not defined in this document. 614 4.2 Payload Packet Overview 616 Once a tunnel is established and control messages have completed 617 tunnel setup, the tunnel can be used to carry user session PPP 618 packets for sessions involving a given LNS-LAC pair. The "Call 619 ID" field in the L2TP header indicates to which session a particu- 620 lar PPP packet belongs. In this manner, PPP packets are multi- 621 plexed and demultiplexed over a single tunnel between a given LNS- 622 LAC pair. The "Call ID" field value is established during the 623 exchange of call setup control messages. 625 It is legal for multiple tunnels to exist between a given LNS-LAC 626 pair. This is useful where each tunnel is used for a single user 627 session, and the tunnel media (an SVC, for instance) has specific 628 QOS attributes dedicated to a given user. L2TP provides a tunnel 629 identifier so that individual tunnels can be identified, even when 630 arriving from a single source LAC or LNS. 632 The L2TP header also contains optional acknowledgment and sequenc- 633 ing information that can be used to perform congestion control 634 over the tunnel. Control messages are used to determine rate and 635 buffering parameters that are used to regulate the flow of PPP 636 packets for a particular session over the tunnel. All implementa- 637 tions MUST implement flow control, but may indicate that flow con- 638 trol is not desired by omitting the Packet Window Size and Packet 639 Processing Delay AVP's during call setup. L2TP does not specify 640 the particular algorithms to use for congestion and flow control. 641 Suggested algorithms for the determination of adaptive time-outs 642 to recover from dropped data or acknowledgments on the tunnel are 643 included in Appendix A of this document. 645 L2TP does not include a "Receive-Not-Ready" function. It is 646 expected that the flow-control mechanism used will provide an ade- 647 quate "pacing" mechanism so that the sender does not overflow the 648 receiver's allotted receive window and receive buffers. It is 649 permissible for the receiving peer to withhold Acks if it is 650 unable to accept more data for a connection. Thus, unlike for the 651 Control Message session, the sending peer MUST NOT clear a session 652 (or the whole tunnel) as a result of not receiving timely acknowl- 653 edgments for transmitted packets. The job of detecting a non- 654 functioning tunnel lies solely with the Control Message functions 655 of L2TP. 657 5. Message Format and Protocol Extensibility 659 L2TP defines a set of control messages sent in packets over the tun- 660 nel between an LNS and a given LAC. The exact technique for initiat- 661 ing a tunnel between an LNS-LAC pair is specific to the tunnel media, 662 and specific media are described in section 8.0. 664 Once media-level connectivity is reached, L2TP message formats define 665 the protocol for an LAC and LNS to manage the tunnel and its associ- 666 ated sessions. 668 In each case where a field is optional, if the field is not present, 669 its space does not exist in the packet. Existing fields are placed 670 back-to-back to form the packet. 672 5.1 AVP 674 To maximize extensibility while still permitting interoperability, 675 a uniform method for encoding message types and bodies is used 676 throughout L2TP. This encoding will be termed an AVP (Attribute- 677 Value Pair) in the remainder of this document. Each AVP is 678 encoded as: 680 0 1 2 3 681 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 |M|H|0|0|0|0| Overall Length | Vendor ID | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Attribute | Value... | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | [until Overall Length is reached]... | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 The first four bits are a bit mask, describing the general 691 attributes of the AVP. The M bit, known as the "mandatory" bit, 692 controls the behavior required of an implementation which receives 693 an AVP which it does not recognize. If M is set, any session 694 associated with this AVP MUST be terminated. If the AVP is asso- 695 ciated with the overall tunnel, the entire tunnel (and all ses- 696 sions within) MUST be terminated. If M is not set, an unrecog- 697 nized AVP should be ignored. 699 The H bit, known as the "hidden" bit, controls the encryption of 700 the contents of the AVP. This bit MUST only be set if tunnel 701 authentication was used and, therefore, a shared secret exists 702 between the peers on either end of the tunnel. If the H bit is 703 set in an AVP, the following mechanism is applied to the contents 704 of the AVP, starting with the first byte beyond the Attribute 705 field: 707 The contents is first padded at the end with nulls to a multi- 708 ple of 16 octets. A one-way MD5 hash is calculated over a 709 stream of octets consisting of the shared secret followed by a 710 16 octet random vector, referred to as the Authenticator. The 711 sender computes the random Authenticator and passes it in the 712 first 16 octets of the AVP value. The MD5 hash value is XORed 713 with the first 16 octet segment of the password and placed in 714 the next 16 octets of the Value field of the Proxy-Authen AVP. 716 If the password is longer than 16 characters, a second one-way 717 MD5 hash is calculated over a stream of octets consisting of 718 the shared secret followed by the result of the first XOR. 719 That hash is XORed with the second 16 octet segment of the 720 password and placed in the next 16 octets of the Value field of 721 the AVP. 723 If necessary, this operation is repeated, with each XOR result 724 being used along with the shared secret to generate the next 725 hash to XOR the next segment of the password, to no more than 726 128 characters. 728 On receipt, the Authenticator is taken from the first 16 octets 729 of the received AVP value field and the process is reversed to 730 yield the original password. For more details on this hiding 731 method, consult the RADIUS [8] specification. 733 Overall Length encodes the number of octets (including the Overall 734 Length field itself) contained in this AVP. It is 10 bits, per- 735 mitting a maximum of 1024 bytes of data in a single AVP. 737 Vendor ID is the IANA assigned "SMI Network Management Private 738 Enterprise Codes" value, encoded in network byte order. The value 739 0, reserved in this table, corresponds to IETF adopted Attribute 740 values, defined within this document. Any vendor wishing to 741 implement L2TP extensions can use their own Vendor ID along with 742 private Attribute values, guaranteeing that they will not collide 743 with any other vendor's extensions, nor with future IETF exten- 744 sions. 746 Attribute is the actual attribute, a 16-bit value with a unique 747 interpretation across all AVP's defined under a given Vendor ID. 749 Value follows immediately after the Attribute field, and runs for 750 the remaining octets indicated in the Overall Length (i.e., Over- 751 all Length minus six octets of header). 753 AVP's should be kept compact; the combined AVP's within a control 754 message MUST NOT ever cause a control message's total length to 755 exceed 1500 bytes in length. 757 5.2 Control Message Format 759 Each L2TP control message begins with a 20 octet fixed header por- 760 tion followed by zero or more AVP's. This fixed header is format- 761 ted: 763 0 1 2 3 764 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 |T|1|1|1|1|K|0| | Ver | Length | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Tunnel ID | Call ID | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Ns | Nr | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Key (opt) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Message Type AVP | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 The T bit MUST be 1, indicating a control message. The next four 778 bits MUST be set to 1, making the header more compatible in encod- 779 ing with the payload message (defined in the next section). The K 780 bit is optional, documented below. The bit following the K bit 781 MUST be 0. 783 Ver MUST be the value 002, indicating a version 1 L2TP message 784 (values 000 and 001 are reserved to permit detection of L2F [2] 785 and PPTP [3] packets if they arrive intermixed). 787 Length is the overall length of the message, including header, 788 message type AVP, plus any additional AVP's associated with a 789 given control message type. 791 Tunnel ID and Call ID identify the tunnel and user session within 792 the tunnel to which a control message applies. If a control mes- 793 sage does not apply to a single user session within the tunnel 794 (for instance, a Stop-Control-Connection-Request message), Call ID 795 MUST be set to 0. If an Assigned Tunnel ID has not yet been 796 received from the peer, Tunnel ID MUST be set to 0. 798 Nr and Ns reflect the currently transmitted packet and latest 799 received packet respectively. See section 4.0. 801 If the K bit is set, the Key field is present. The K bit MUST be 802 set if a Challenge value was received during tunnel setup, and the 803 Key reflects the challenge response of this authentication, with 804 the resulting MD5 hash value broken into successive 32-bit fields 805 which are XOR'ed together and this value put in the Key field. 807 5.3 Payload Message Format 809 PPP payload packets tunneled within L2TP have a smaller encapsula- 810 tion than the L2TP control message header, reducing overhead of 811 L2TP during the life of a tunneled PPP session. The MTU for the 812 user data packets encapsulated in L2TP is expected to be 1500 813 octets, not including L2TP and media encapsulation. The smallest 814 L2TP encapsulation is 2 octets; the largest is 18 octets (plus 815 padding bytes, if present). See section 8.1 for further MTU con- 816 siderations. 818 0 1 2 3 819 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 |T|L|I|C|F|K|O| | Ver | Length (opt) | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Tunnel ID (opt) | Call ID (opt) | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Ns (opt) | Nr (opt) | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Key (opt) | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Offset Size | Offset bytes of pad... | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 The T bit MUST be 0, indicating payload. 834 Ver MUST be 002, indicating version 1 of the L2TP protocol. 836 If the L bit is set, the Length field is present, indicating the 837 total length of the received packet. 839 The I and C bits indicate the presence of Tunnel ID and Call ID, 840 respectively. The interpretation of these fields, if present, is 841 described in section 5.2. 843 If the F bit is set, both the Nr and Ns fields are present. Ns 844 indicates the sequence number of the packet being sent. The cur- 845 rent packet will be this sequence number if the payload size is 846 non-zero, otherwise this packet is only an acknowledgment 847 (sequence number does not advance). Nr indicates the next packet 848 sequence number to be received (if the last data packet had Ns set 849 to 1, the Nr sent back would be 2). Together, these fields can be 850 used to handle out-of-order packets, and to provide flow control 851 for the connection. 853 If the K bit is set, the Key field is present. Refer to the 854 description in 5.2. 856 The Offset Size field is present if the O bit is set in the header 857 flags. This field specifies the number of bytes past the L2TP 858 header at which the payload data is expected to start. It is rec- 859 ommended that data thus skipped be initialized to 0's. If Offset 860 Size is 0, or the O bit is not set, the first byte following the 861 last byte of L2TP header is the first byte of payload data. 863 5.4 Control Message Types 865 Control message types defined in this specification exist under 866 Vendor ID 0, indicating IETF defined behavior. The actual message 867 semantics are defined in the next section. The currently defined 868 control messages types, grouped by function, are: 870 Control Message Message Code 872 (Control Connection Management) 874 Start-Control-Connection-Request 1 875 Start-Control-Connection-Reply 2 876 Start-Control-Connection-Connected 17 877 Stop-Control-Connection-Request 3 878 Stop-Control-Connection-Reply 4 879 Hello 5 880 (deleted) 6 882 (Call Management) 884 Outgoing-Call-Request 7 885 Outgoing-Call-Reply 8 886 Outgoing-Call-Connected 16 887 Incoming-Call-Request 9 888 Incoming-Call-Reply 10 889 Incoming-Call-Connected 11 890 Call-Clear-Request 12 891 Call-Disconnect-Notify 13 893 (Error Reporting) 895 WAN-Error-Notify 14 897 (PPP Session Control) 898 Set-Link-Info 15 900 5.5 General Error Codes 902 General error codes pertain to types of errors which are not spe- 903 cific to any particular L2TP request, but rather to protocol or 904 message format errors. If an L2TP reply indicates in its Result 905 Code that a general error occurred, the General Error value should 906 be examined to determined what the error was. The currently 907 defined General Error codes and their meanings are: 909 0 - No general error 910 1 - No control connection exists yet for this LAC-LNS pair 911 2 - Length is wrong 912 3 - One of the field values was out of range or 913 reserved field was non-zero 914 4 - Insufficient resources to handle this operation now 915 5 - The Call ID is invalid in this context 916 6 - A generic vendor-specific error occurred in the LAC 917 7 - Try another. If LAC is aware of other possible LNS 918 destinations, it should try one of them. This can be 919 used to guide an LAC based on LNS policy, for instance, 920 the existence of multilink PPP bundles. 922 Generally, when a value of 6 is used, a vendor-specific AVP 923 will be present also, providing further detail for that vendor 924 implementation. 926 If the length of an AVP indicating a General Error specifies 927 that the Value field is more than two bytes in length, the 928 remaining bytes are an arbitrary string providing further (pos- 929 sibly human readable) text associated with the condition. 931 6.0 Control Connection Protocol Specification 933 Control Connection messages are used to establish and clear user ses- 934 sions. The first set of Control Connection messages are used to 935 maintain the control connection itself. The control connection is 936 initiated by an LAC or LNS after establishing the underlying tunnel- 937 over-media connection. 939 6.0.1 Control Connection Collision 941 For the case where an LAC and LNS both initiate tunnels to each 942 other concurrently, and where the LAC and LNS both determine that 943 a single tunnel suffices (generally because of media characteris- 944 tic considerations, for instance, whether individual tunnels are 945 needed to gain QOS guarantees for each tunnel), a "tie breaker" 946 may be undertaken. The details of breaking a tie are documented 947 with the tunnel establishment messages. 949 6.0.2 Reliable Delivery of Control Messages 951 Since L2TP may run across media where packets may be lost, an L2TP 952 peer sending a control message will retransmit the control message 953 after deciding that its remote peer has not received it. The 954 reliable transport mechanism built into L2TP is essentially a 955 lower layer transport service; the Nr and Ns fields of the control 956 message header belong to this transport layer. The higher layer 957 functions of L2TP are not concerned with retransmission or order- 958 ing of control messages. 960 Each tunnel maintains a queue of control messages to be transmit- 961 ted to the peer. The message at the front of the queue is sent 962 with a given Ns value, and is held until a control message arrives 963 from the peer in which the Nr field indicates receipt of this 964 message. After a fixed (recommended default is 1 second) or adap- 965 tive (see Appendix D) timeout interval expires without receiving 966 such an acknowledgment, the control message packet is retransmit- 967 ted. The retransmitted packet contains the same Ns value, but the 968 Nr value MUST be updated to reflect any packets received in the 969 interim. 971 If no peer response is detected after several retransmissions (a 972 recommended default is 5, but may be altered due to media consid- 973 erations), the tunnel and all sessions within MUST be cleared. 975 When a tunnel is being shut down for reasons other than loss of 976 connectivity, the state and reliable delivery mechanisms MUST be 977 maintained and operated for the full retransmission interval after 978 the final message exchange has occurred. This permits reliable 979 delivery of closing messages in environments where these closing 980 messages might be dropped. 982 Unlike payload traffic, a peer MUST NOT withhold acknowledgment of 983 packets as a technique for flow controlling control messages. An 984 L2TP implementation is expected to be able to keep up with incom- 985 ing control messages, possible responding to some with errors 986 reflecting an inability to honor the requested action. 988 A sliding window mechanism is used, by default, for control mes- 989 sage transmission. The default is to permit four control message 990 to be outstanding on a given tunnel. If a peer specifies a con- 991 trol message window in the Start-Control-Connection-Request and 992 -Reply packets, up to the indicated number of control messages may 993 be sent and held outstanding. An implementation may only support 994 a receive window of 1, but MUST accept at least a window of 4 from 995 its peer. 997 The transport layer at a receiving peer is responsible for making 998 sure that control messages are delivered in order to the higher 999 layer and that duplicate messages are not delivered to the higher 1000 layer. Messages arriving out of order may be queued for in-order 1001 delivery when the missing messages are received or they may be 1002 discarded, requiring a retransmission. 1004 6.0.3 Control Message Format 1006 The following Control Connection messages are all sent as packets 1007 on the established tunnel connection between a given LNS-LAC pair. 1008 All data is sent in network order (high order octets first). Any 1009 "reserved" or "empty" fields MUST be sent as 0 values to allow for 1010 protocol extensibility. 1012 Each control message has a header, specified in section 5.2, 1013 including an AVP indicating the type of control message, followed 1014 by zero or more AVP's appropriate for the given type of control 1015 message. Each control message is described first at a block 1016 level, and then with details of each AVP. 1018 6.1 Start-Control-Connection-Request 1020 The Start-Control-Connection-Request is an L2TP control message used 1021 to initialize the tunnel between an LNS and an LAC. The tunnel must 1022 be initialized through the exchange of these control messages before 1023 any other L2TP messages can be issued. The establishment of the con- 1024 trol connection is started by the initiator of the underlying tunnel. 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | L2TP Control Message Header | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Start-Control-Connection-Request | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Protocol Version | 1032 | Framing Capabilities | 1033 | Bearer Capabilities | 1034 | Tie Breaker | 1035 | Firmware Revision | 1036 | Host Name | 1037 | Vendor Name | 1038 | Assigned Tunnel ID | 1039 | Control Message Window| 1040 | Challenge | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+ 1043 Start-Control-Connection-Request AVP 1045 0 1 2 3 1046 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 |1|0|0|0| 6 | 0 | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | 1 | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 The Attribute field is 1, indicating Start-Control-Connection- 1054 Request. The Flags indicate a mandatory option. Details associ- 1055 ated with this tunneled session follow in additional AVP's within 1056 the packet. 1058 Protocol Version 1060 0 1 2 3 1061 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 |1|0|0|0| 8 | 0 | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | 101 | 0x01 | 0x00 | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 The Protocol Version AVP within a Start-Control-Connection-Request 1069 packet indicates the L2TP protocol version available. The 1070 Attribute value is 101, indicating Protocol Version, and is marked 1071 mandatory. This AVP MUST be present. The Value field is a 16-bit 1072 hexadecimal value 0x100, indicating L2TP protocol version 1, revi- 1073 sion 0. 1075 Framing Capabilities 1077 0 1 2 3 1078 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 |1|0|0|0| 10 | 0 | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | 102 | 0x00 | 0x00 | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | 0x00 |0|0|0|0|0|0|S|A| 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 The Framing Capabilities AVP within a Start-Control-Connection- 1088 Request indicates the type of framing that the sender of this mes- 1089 sage can provide. The Attribute value is 102, indicating Framing 1090 Capabilities, and is marked mandatory. This AVP MUST be present. 1091 The Value field is a 32-bit quantity, with two bits defined. If 1092 bit A is set, asynchronous framing is supported. If bit S is set, 1093 synchronous framing is supported. 1095 Bearer Capabilities 1097 0 1 2 3 1098 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 |1|0|0|0| 10 | 0 | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | 103 | 0x00 | 0x00 | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | 0x00 |0|0|0|0|0|0|D|A| 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 The Bearer Capabilities AVP within a Start-Control-Connection- 1108 Request indicates the bearer capabilities that the sender of this 1109 message can provide. The Attribute value is 103, indicating 1110 Bearer Capabilities, and is marked mandatory. This AVP MUST be 1111 present. The Value field is a 32-bit quantity with two bits 1112 defined. If bit A is set, analog access is supported. If bit D 1113 is set, digital access is supported. 1115 Tie Breaker 1117 0 1 2 3 1118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 |0|0|0|0| 14 | 0 | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | 104 | Tie Break Value... | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Value... | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | ...(64 bits) | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 The Tie Breaker AVP within a Start-Control-Connection-Request con- 1130 tains a 64-bit Value used to break ties in tunnel establishment 1131 between an LAC-LNS pair. The Attribute value is 104, indicating 1132 Tie Breaker, and is marked optional. This AVP itself is optional. 1133 The 8 byte Value is used as a 64-bit tie breaker value. 1135 If present, it indicates the sender wishes a single tunnel to 1136 exist between the given LAC-LNS pair, and this value will be used 1137 to choose a single tunnel where both LAC and LNS initiate a tunnel 1138 concurrently. The recipient of a Start-Control-Connection-Request 1139 must check to see if a Start-Control-Connection-Request has been 1140 sent to the peer, and if so, must compare its Tie Breaker value 1141 with the received one. The lower value "wins", and the "loser" 1142 MUST initiate a tunnel disconnect for their outstanding tunnel. 1143 In the case where a tie breaker is present on both sides, and the 1144 value is equal, both sides MUST initiate tunnel disconnects. 1146 If a tie breaker is received, and the outstanding Start-Control- 1147 Connection-Request had no tie breaker value, the initiator which 1148 included the Tie Breaker AVP "wins". 1150 It is recommended that the Value be set to the MAC address of a 1151 LAN interface on the sender. If no MAC address is available, a 1152 64-bit random number should be used instead. 1154 Firmware Revision 1156 0 1 2 3 1157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 |0|0|0|0| 8 | 0 | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | 105 | Max (H) | Max (L) | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 The Firmware Revision AVP within a Start-Control-Connection- 1165 Request indicates the firmware revision of the issuing device. 1166 The Attribute value is 105, indicating Firmware Revision, and is 1167 marked optional. This AVP itself is optional. The Value field is 1168 a 16-bit integer encoded in a vendor specific format. For devices 1169 which do not have a firmware revision (general purpose computers 1170 running L2TP software modules, for instance), the revision of the 1171 L2TP software module may be reported instead. 1173 Host Name 1175 0 1 2 3 1176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 |0|0|0|0| 6 + Host name length | 0 | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | 106 |Host name... | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 The Host Name AVP within a Start-Control-Connection-Request indi- 1184 cates the name of the issuing LAC or LNS. The Attribute value is 1185 106, indicating Host Name, and is marked optional. This AVP 1186 itself is optional. This name should be as broadly unique as pos- 1187 sible; for hosts participating in DNS [4], a hostname with fully 1188 qualified domain would be appropriate. 1190 Vendor Name 1192 0 1 2 3 1193 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 |0|0|0|0| 6 + vendor name len | 0 | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | 107 |Vendor name... | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 The Vendor Name AVP within a Start-Control-Connection-Request con- 1201 tains a vendor specific string describing the type of LAC or LNS 1202 being used. The Attribute value is 107, indicating Vendor Name, 1203 and is marked optional. This AVP itself is optional. The Value 1204 is the indicated number of bytes representing the vendor string. 1206 Assigned Tunnel ID 1208 0 1 2 3 1209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 |1|0|0|0| 8 | 0 | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | 108 | Tunnel ID | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 The Assigned Tunnel ID AVP within a Start-Control-Connection- 1217 Request specifies the Tunnel ID which the receiving peer MUST use 1218 in the Tunnel ID field of all subsequent packets. The Attribute 1219 value is 108, indicating Assigned Tunnel ID, and is marked manda- 1220 tory. This AVP MUST be present. Before the Assigned Tunnel ID 1221 AVP is received, packets MUST be sent with a Tunnel ID value of 0. 1222 The Value is a 16-bit non-zero Tunnel ID value. 1224 Control Message Window 1226 0 1 2 3 1227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 |1|0|0|0| 8 | 0 | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | 109 | Window | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 The Control Message Window AVP within a Start-Control-Connection- 1234 Request specifies the receive window size being offered to the 1235 remote peer. The Attribute value is 109, indicating Control Mes- 1236 sage Window, and is mandatory. This AVP itself is optional. 1237 Value is a 16-bit word indicating the offered window size. If 1238 absent, the peer must assume a value of 4 for its transmit window. 1239 The remote peer may send the specified number of control messages 1240 before it must wait for an acknowledgment. 1242 Challenge 1244 0 1 2 3 1245 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 |1|0|0|0| 6 + Challenge length | 0 | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | 110 | Challenge... | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 The Challenge AVP within a Start-Control-Connection-Request indi- 1253 cates that the issuing peer wishes to authenticate the tunnel end- 1254 points. The Attribute value is 110, indicating Challenge, and is 1255 marked mandatory. This AVP is optional. The Value is one or more 1256 octets of challenge value. 1258 6.2 Start-Control-Connection-Reply 1260 The Start-Control-Connection-Reply is an L2TP control message sent in 1261 reply to a received Start-Control-Connection-Request message. This 1262 message contains a result code indicating the result of the control 1263 connection establishment attempt. 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | L2TP Control Message Header | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Start-Control-Connection-Reply | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Protocol Version | 1271 | Result Code | 1272 | Error Code | 1273 | Framing Capabilities | 1274 | Bearer Capabilities | 1275 | Firmware Revision | 1276 | Host Name | 1277 | Vendor Name | 1278 | Assigned Tunnel ID | 1279 | Control Message Window| 1280 | Challenge | 1281 | Response | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+ 1284 Start-Control-Connection-Reply AVP 1286 0 1 2 3 1287 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 |1|0|0|0| 6 | 0 | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | 2 | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 The Attribute field is 2, indicating Start-Control-Connection- 1295 Reply. The Flags indicate a mandatory option. 1297 Protocol Version 1299 0 1 2 3 1300 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 |1|0|0|0| 8 | 0 | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | 201 | 0x01 | 0x00 | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 The Protocol Version AVP within a Start-Control-Connection-Reply 1308 packet indicates the L2TP protocol version available. The 1309 Attribute value is 201, indicating Protocol Version, and the Value 1310 field is a 16-bit hexadecimal value 0x100, indicating L2TP proto- 1311 col version 1, revision 0. This AVP MUST be present. 1313 Framing Capabilities 1315 0 1 2 3 1316 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 |1|0|0|0| 10 | 0 | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | 202 | 0x00 | 0x00 | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | 0x00 |0|0|0|0|0|0|S|A| 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 The Framing Capabilities AVP within a Start-Control-Connection- 1326 Reply indicates the type of framing that the sender of this mes- 1327 sage can provide. The Attribute is 202, it is a mandatory AVP, 1328 the Value field is a 32-bit quantity, with two bits defined. If 1329 bit A is set, asynchronous framing is supported. If bit S is set, 1330 synchronous framing is supported. This AVP MUST be present. 1332 Bearer Capabilities 1334 0 1 2 3 1335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 |1|0|0|0| 10 | 0 | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | 203 | 0x00 | 0x00 | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | 0x00 |0|0|0|0|0|0|D|A| 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 The Bearer Capabilities AVP within a Start-Control-Connection- 1345 Reply indicates the bearer capabilities that the sender of this 1346 message can provide. The Attribute is 203, it is a mandatory AVP, 1347 the Value field is a 32-bit quantity with two bits defined. If 1348 bit A is set, analog access is supported. If bit D is set, digi- 1349 tal access is supported. This AVP MUST be present. 1351 Firmware Revision 1353 0 1 2 3 1354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 |0|0|0|0| 8 | 0 | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | 204 | Max (H) | Max (L) | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 The Firmware Revision AVP within a Start-Control-Connection-Reply 1362 indicates the firmware revision of the issuing device. The 1363 Attribute is 204, it is not a mandatory AVP, the Value field is a 1364 16-bit integer encoded in a vendor specific format. For devices 1365 which do not have a firmware revision (general purposes computers 1366 running L2TP software modules, for instance), the revision of the 1367 L2TP software module may be reported instead. This AVP is 1368 optional. 1370 Host Name 1372 0 1 2 3 1373 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 |0|0|0|0| 6 + Host name length | 0 | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | 205 |Host name... | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 The Host Name AVP within a Start-Control-Connection-Reply indi- 1381 cates the name of the issuing LAC or LNS. See the notes in sec- 1382 tion 6.1 concerning Host Name contents. It is encoded as the 1383 Attribute 205, not mandatory, with the indicated number of bytes 1384 representing the host name string. This AVP is optional. 1386 Vendor Name 1388 0 1 2 3 1389 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 |0|0|0|0| 6 + Vendor name len | 0 | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | 206 |Vendor name... | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 The Vendor Name AVP within a Start-Control-Connection-Reply con- 1396 tains a vendor specific string describing the type of LAC or LNS 1397 being used. It is encoded as the Attribute 206, not mandatory, 1398 with the indicated number of bytes representing the vendor string. 1399 This AVP is optional. 1401 Assigned Tunnel ID 1403 0 1 2 3 1404 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 |1|0|0|0| 6 + length | 0 | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | 207 | ID | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply 1412 specifies the Tunnel ID which the receiving peer MUST use in all 1413 subsequent packets. It is encoded as the Attribute 207, manda- 1414 tory, with a 16-bit non-zero Tunnel ID value. This AVP MUST be 1415 present. 1417 Control Message Window 1419 0 1 2 3 1420 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 |0|0|0|0| 8 | 0 | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | 208 | Window | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 The Control Message Window AVP within a Start-Control-Connection- 1428 Reply specifies the number of control messages which may be 1429 received without waiting for an acknowledgment. It is encoded as 1430 the Attribute 208, not mandatory, with a 16-bit word indicating 1431 the number of such messages. If absent, the peer MUST use a value 1432 of 4 for the Window. 1434 Result Code 1436 0 1 2 3 1437 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 |1|0|0|0| 8 | 0 | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | 209 | Code | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 The Result Code AVP within a Start-Control-Connection-Reply packet 1445 indicates the result of the control channel establishment attempt. 1446 The Value field is 209, indicating a Result Code. The code is a 1447 16-bit word, and this AVP is mandatory. This AVP MUST be present. 1448 Result code values are: 1450 1 - Successful channel establishment 1451 2 - General error--Error Code indicates the problem 1452 3 - Control channel already exists 1453 4 - Requester is not authorized to establish a control channel 1454 5 - The protocol version of the requester is not supported 1456 Error Code 1458 0 1 2 3 1459 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 |1|0|0|0| 8 | 0 | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | 210 | Error | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Optional Message... | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 This AVP is present only if a "General Error" exists, in which 1469 case Result Code was set to 2 and this AVP encodes the general 1470 error value as documented in section 5.5. It has a Value of 210, 1471 and is marked mandatory. 1473 Challenge 1475 0 1 2 3 1476 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 |1|0|0|0| 6 + length | 0 | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | 211 | Challenge... | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 The Challenge AVP within a Start-Control-Connection-Reply indi- 1484 cates that the peer wishes to authenticate the tunnel initiator. 1485 It is encoded as the Attribute 211, mandatory, with at least one 1486 byte of challenge value embedded. If this AVP is not present, it 1487 indicates to the receiving peer that the sender does not wish to 1488 authenticate that peer. 1490 Response 1492 0 1 2 3 1493 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 |1|0|0|0| 22 | 0 | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | 212 | Response... | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Response... (128 bits) | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 The Response AVP within a Start-Control-Connection-Reply packet 1503 provides a response to a challenge received. The Attribute value 1504 is 212, indicating Response, and the Value field is a 128-bit 1505 value reflecting the CHAP-style response to the challenge. This 1506 AVP marked mandatory, and MUST be present if a challenge was 1507 received and this Start-Control-Connection-Reply indicates suc- 1508 cess. For purposes of the ID value in the CHAP response calcula- 1509 tion, the low order byte of the Sequence number of the challenge 1510 is used. 1512 6.3 Start-Control-Connection-Connected 1514 The Start-Control-Connection-Connected message is an L2TP control 1515 message sent in reply to a received Start-Control-Connection-Reply 1516 message. This message provides closure to the tunnel establishment 1517 process, and includes a challenge response if the peer sent a chal- 1518 lenge in the Start-Control-Connection-Reply message. 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | L2TP Control Message Header | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | Start-Control-Connection-Connected | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | Response | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+ 1528 Start-Control-Connection-Connected AVP 1530 0 1 2 3 1531 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 |1|0|0|0| 6 | 0 | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | 17 | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 The Attribute field is 17, indicating Start-Control-Connection- 1539 Connected. The Flags indicate a mandatory option. 1541 Response 1543 0 1 2 3 1544 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 |1|0|0|0| 22 | 0 | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | 1701 | Response... | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | Response... (128 bits) | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 The Response AVP within a Start-Control-Connection-Connected 1554 packet provides a response to a challenge received. The Attribute 1555 value is 1701, indicating Response, and the Value field is a 1556 128-bit value reflecting the CHAP-style response to the challenge. 1557 This AVP is marked mandatory, and MUST be present if a challenge 1558 was received, otherwise MUST be omitted. For purposes of the ID 1559 value in the CHAP response calculation, the low order byte of the 1560 Sequence number of the challenge are used. 1562 6.4 Stop-Control-Connection-Request 1564 The Stop-Control-Connection-Request is an L2TP control message sent 1565 by one peer of an LAC-LNS control connection to inform the other peer 1566 that the control connection should be closed. In addition to closing 1567 the control connection, all active user calls are implicitly cleared. 1568 The reason for issuing this request is indicated in the Reason field. 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | L2TP Control Message Header | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 | Stop-Control-Connection-Request | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | Assigned Tunnel ID | 1576 | Reason | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+ 1579 Stop-Control-Connection-Request AVP 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 |1|0|0|0| 6 | 0 | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | 3 | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 The Attribute field is 3, indicating Stop-Control-Connection- 1590 Request. The Flags indicate a mandatory option. The Flags indi- 1591 cate a mandatory option. The single Reason AVP MUST follow this. 1593 Assigned Tunnel ID 1595 0 1 2 3 1596 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 |1|0|0|0| 8 | 0 | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | 301 | Assigned Tunnel ID | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 The Attribute value is 301, indicating Assigned Tunnel ID, and is 1604 marked mandatory. This AVP MUST be present. The Value MUST be 1605 the same Assigned Tunnel ID first sent to the receiving peer. 1606 This AVP permits the peer to identify the appropriate tunnel even 1607 if Stop-Control-Connection-Request must be sent before an Assigned 1608 Tunnel ID is received. 1610 Reason 1611 0 1 2 3 1612 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 |1|0|0|0| 8 | 0 | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | 302 | Reason | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 The Attribute value is 302, indicating Reason, and is marked 1620 mandatory. This AVP MUST be present. The Value is a 16-bit word 1621 indicates the reason for the control connection closure. Values 1622 are: 1624 1 - General request to clear control connection 1625 2 - Can't support peer's version of the protocol 1626 3 - Requester is being shut down 1628 6.5 Stop-Control-Connection-Reply 1630 The Stop-Control-Connection-Reply is an L2TP control message sent by 1631 one peer of an LAC-LNS control connection upon receipt of a Stop- 1632 Control-Connection-Request from the other peer. 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | L2TP Control Message Header | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Stop-Control-Connection-Reply | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Result Code | 1640 | Error Code | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+ 1643 Stop-Control-Connection-Reply AVP 1645 0 1 2 3 1646 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 |1|0|0|0| 8 | 0 | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | 4 | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 The Attribute field is 4, indicating Stop-Control-Connection- 1654 Reply. The Flags indicate a mandatory option. 1656 Result Code 1658 0 1 2 3 1659 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 |1|0|0|0| 8 | 0 | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | 401 | Result | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 The Attribute value is 401, indicating Result Code, and is marked 1666 mandatory. This AVP MUST be present. The Value is a 16-bit word 1667 indicating the result of the attempt to close the control connec- 1668 tion. Values are: 1670 1 - Control connection closed 1671 2 - Control connection not closed for reason indicated in Error Code 1673 Error Code 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 |1|0|0|0| 8 | 0 | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | 402 | Error | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | Optional Message... | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 The Attribute value is 402, indicating Error Code, and is marked 1686 mandatory. This AVP is present only if a "General Error" exists, 1687 in which case the Value encodes the general error value as docu- 1688 mented in section 5.5. 1690 6.6 Hello 1692 The Hello message is an L2TP control message sent by either peer of a 1693 LAC-LNS control connection. This control message is used as a 1694 "keepalive" for the control connection. 1696 Keepalives should be implemented by sending a Hello once every 60 1697 seconds if 60 seconds have passed without sending a message to the 1698 peer. When a Hello is received, it MUST be silently discarded (after 1699 updating any effects of the indicated Nr/Ns values). 1701 Because a Hello is a control message, and control messages are reli- 1702 ably sent by the lower level transport, this keepalive function oper- 1703 ates by causing the transport level to reliably deliver a message. 1704 If a media interruption has occurred, the reliable transport will be 1705 unable to deliver the Hello across, and will clean up the tunnel. 1707 Hello messages are global to the tunnel; the Call ID field of these 1708 control messages MUST be 0. 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | L2TP Control Message Header | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Hello | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 Hello AVP 1718 0 1 2 3 1719 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 |0|0|0|0| 6 | 0 | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | 5 | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 The The Attribute value is 5, indicating Hello, and is marked 1727 optional. 1729 6.7 (Deleted) 1731 This section has been deleted. 1733 6.8 Outgoing-Call-Request 1735 The Outgoing-Call-Request is an L2TP control message sent by the LNS 1736 to the LAC to indicate that an outbound call from the LNS is to be 1737 established. This request provides the LAC with information required 1738 to make the call. It also provides information to the LAC that is 1739 used to regulate the transmission of data to the LNS for this session 1740 once it is established. 1742 This message is the first in the "three-way handshake" used by L2TP 1743 for establishing outgoing calls. The first message requests the 1744 call; the second indicates that the call was successfully initiated. 1745 The third and final message indicates that the call was established. 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | L2TP Control Message Header | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Outgoing-Call-Request | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Assigned Call ID | 1753 | Call Serial Number | 1754 | Minimum BPS | 1755 | Maximum BPS | 1756 | Bearer Type | 1757 | Framing Type | 1758 | Packet Recv. Window | 1759 | Packet Processing Delay | 1760 | Phone Number | 1761 | Sub-Address | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 Outgoing-Call-Request AVP 1766 0 1 2 3 1767 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 |1|0|0|0| 6 | 0 | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | 7 | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 The Outgoing-Call-Request AVP encodes a request to an LAC to 1774 establish an outgoing call. The flags indicate a mandatory 1775 option. 1777 Assigned Call ID AVP 1779 0 1 2 3 1780 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 |1|0|0|0| 8 | 0 | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | 701 | Call ID | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 The Assigned Call ID AVP encodes the ID being assigned to this 1788 call by the LNS. The Attribute value is 701, indicating Assigned 1789 Call ID, and is marked mandatory. This AVP MUST be present. The 1790 LAC places this value in the Call ID header field of all command 1791 and payload packets that it subsequently transmits over the tunnel 1792 that belong to this call. The Call ID value is an identifier 1793 assigned by the LNS to this session. It is used to multiplex and 1794 demultiplex data sent over that tunnel between the LNS and LAC. 1796 Call Serial Number 1798 0 1 2 3 1799 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 |1|0|0|0| 6 + length | 0 | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | 702 | Number... | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 Call Serial Number AVP encodes an identifier assigned by the LNS to 1807 this call. 1808 Attribute is 702, indicating Call Serial Number, and is marked mandatory. 1809 This AVP MUST be present. 1810 The Number value 1811 is an identifier used by the LNS and the LAC 1812 for identifying the call. Unlike the Call ID, both the LNS and LAC 1813 associate the same Call Serial Number with a given call. This AVP 1814 MUST be present, and the Number MUST be at least one octet in length. 1816 Minimum BPS 1818 0 1 2 3 1819 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 |1|0|0|0| 10 | 0 | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | 703 | BPS (H) | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | BPS (L) | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 Minimum BPS AVP encodes the lowest acceptable line speed for this 1828 call. Attribute is 703, Minimum BPS, and is marked mandatory. 1829 This AVP MUST be present. The BPS value indicates the speed in 1830 bits/second. 1832 Maximum BPS 1834 0 1 2 3 1835 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 |1|0|0|0| 10 | 0 | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | 704 | BPS (H) | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | BPS (L) | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 Maximum BPS AVP encodes the highest acceptable line speed for this 1845 call. Attribute is 704, indicating Maximum BPS, and is marked 1846 mandatory. This AVP MUST be present. The BPS value indicates the 1847 speed in bits/second. 1849 Bearer Type AVP 1851 0 1 2 3 1852 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 |1|0|0|0| 10 | 0 | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | 705 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 Bearer Type AVP encodes the bearer type for the requested call. 1862 The value bit field Attribute is 705, indicating Bearer Type, and 1863 is marked mandatory. This AVP MUST be present. The Value is a 1864 32-bit quantity indicating the bearer capability required for this 1865 outgoing call. If set, bit A indicates that the call should be on 1866 an analog channel. If set, bit D indicates that the call should 1867 be on a digital channel. Both may be set, indicating that the 1868 call can be of either type. 1870 Framing Type AVP 1872 0 1 2 3 1873 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 |1|0|0|0| 10 | 0 | 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | 706 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 Framing Type AVP encodes the framing type for the requested call. 1882 Attribute is 706, indicating Framing Type, and is marked manda- 1883 tory. This AVP MUST be present. The 32-bit field indicates the 1884 type of PPP framing to be used for the outgoing call. Bit A if 1885 set indicates that asynchronous framing should be used. Bit S is 1886 set indicates that synchronous framing should be used. 1888 Packet Receive Window Size AVP 1890 0 1 2 3 1891 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 |1|0|0|0| 8 | 0 | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | 707 | Size (H) | Size (L) | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 Packet Receive Window Size AVP encodes the window size being 1899 advertised by the LNS for this call. Attribute is 707, indicating 1900 Packet Receive Window, and is marked mandatory. This AVP is 1901 optional. The Size value indicates the number of received data 1902 packets the LNS will buffer for this call, which is also the maxi- 1903 mum number of data packets the LAC should send before waiting for 1904 an acknowledgment. The absence of this AVP indicates that 1905 Sequence and Acknowledgment Numbers are not to be used in the pay- 1906 load session for this call. 1908 Packet Processing Delay AVP 1910 0 1 2 3 1911 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 |1|0|0|0| 8 | 0 | 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 | 708 | Delay (H) | Delay (L) | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 The Packet Processing Delay AVP encodes the delay LNS has for pro- 1919 cessing a window full of packets sent by the LAC. Attribute is 1920 708, indicating Packet Processing Delay, and is marked mandatory. 1921 This AVP is optional. The Delay value is specified in units of 1922 1/10 seconds. Refer to Appendix A for a description of how this 1923 value is determined and used. 1925 Phone Number 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 |1|0|0|0| 6 + Phone Number len | 0 | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | 709 | Phone Number..| 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 Phone Number AVP encodes the phone number to be called. Attribute 1935 is 709, indicating Phone Number, and is marked mandatory. This 1936 AVP MUST be present. The Phone Number value is an ASCII string. 1938 Sub-Address AVP 1940 0 1 2 3 1941 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 |1|0|0|0| 6 + Sub-Address len | 0 | 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 | 710 | Sub-Address ..| 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 Sub-Address AVP encodes additional dialing information. Attribute 1949 is 710, indicating Sub-Address, and is marked mandatory. This AVP 1950 is optional. The Sub-Address value is an ASCII string. 1952 6.9 Outgoing-Call-Reply 1954 The Outgoing-Call-Reply is an L2TP control message sent by the LAC to 1955 the LNS in response to a received Outgoing-Call-Request message. The 1956 reply indicates whether or not the LAC is able to attempt the out- 1957 bound call and also returns certain parameters regarding the call 1958 attempt. 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | L2TP Control Message Header | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | Outgoing-Call-Reply | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | Assigned Call ID | 1966 | Result Code | 1967 | Error Code | 1968 | Connect Speed | 1969 | Physical Channel Id | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 Outgoing-Call-Reply AVP 1974 0 1 2 3 1975 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 |1|0|0|0| 6 | 0 | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | 8 | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 The Outgoing-Call-Reply AVP encodes an immediate result of attempting 1983 an outgoing call request. The flags indicate a mandatory option. 1985 Assigned Call ID AVP 1987 0 1 2 3 1988 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 |1|0|0|0| 8 | 0 | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 | 801 | Call ID | 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 The Assigned Call ID AVP encodes the ID being assigned to this call 1996 by the LAC. Attribute is 801, indicating Assigned Call ID, and is 1997 marked mandatory. This AVP MUST be present. Call ID value is an 1998 identifier, unique within the tunnel, assigned by the sender to this 1999 session. The remote peer MUST place this Call ID in the Call ID por- 2000 tion of all future packets it sends associated with this session. It 2001 is used to multiplex and demultiplex data sent over that tunnel 2002 between the LNS and LAC. 2004 Result Code AVP 2006 0 1 2 3 2007 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 |1|0|0|0| 8 | 0 | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 | 802 | Result Code | 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 Result Code AVP encodes the result of the Outgoing-Call-Request. 2015 Attribute is 802, indicating Result Code, and is marked mandatory. 2016 This AVP MUST be present. The Result Code is a 16-bit value indicat- 2017 ing: 2019 1 - Call attempt in progress 2020 2 - Outgoing Call not attempted for the reason indicated in Error Code 2021 3 - No appropriate facilities are available (temporary condition) 2022 4 - No appropriate facilities are available (permanent condition) 2023 5 - Invalid destination 2024 6 - Outgoing Call administratively prohibited 2026 Error Code AVP 2028 0 1 2 3 2029 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 |1|0|0|0| 8 | 0 | 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 | 803 | Error Code | 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | Optional Message... | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 The Error Code AVP is used to encode a specific error code in case 2039 the result AVP indicates a General Error. Attribute is 803, indicat- 2040 ing Error Code, and is marked mandatory. This AVP is present only if 2041 the Result Code indicates a value of 2. The value can be one of the 2042 general error IDs specified in Section 5.5. 2044 Connect Speed AVP 2046 0 1 2 3 2047 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 |1|0|0|0| 10 | 0 | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | 804 | BPS (H) | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | BPS (L) | 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 Connect Speed BPS AVP encodes the speed for the connection. The 2057 Attribute value is 804, indicating Connect Speed, and is marked 2058 mandatory. This AVP MUST be present if the Result indicates a call 2059 is in progress. The BPS is a 16-bit value indicating the speed in 2060 bits/second. 2062 Physical Channel ID AVP 2064 0 1 2 3 2065 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 |1|0|0|0| 10 | 0 | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | 805 | ID (H) | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 | ID (L) | 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 Physical Channel ID AVP encodes the vendor specific physical channel 2075 number used for the call. The Attribute value is 805, indicating 2076 Physical Channel ID, and is marked optional. This AVP itself is 2077 optional. ID is a 32-bit value in network byte order. The value is 2078 used for logging purposes only. 2080 6.10 Outgoing-Call-Connected 2082 Outgoing-Call-Connected is an L2TP control message sent by the LAC to 2083 the LNS to indicate the result of a requested outgoing call. The LAC 2084 MUST send the corresponding Outgoing-Call-Reply to the LNS before 2085 sending this message. This message provides information to the LNS 2086 about the particular parameters used for the call. It provides 2087 information to allow the LNS to regulate the transmission of data to 2088 the LAC for this session. 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 | L2TP Control Message Header | 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2093 | Outgoing-Call-Connected | 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | Result Code | 2096 | Error Code | 2097 | Cause Code | 2098 | Connect Speed | 2099 | Framing Type | 2100 | Packet Recv. Window | 2101 | Packet Processing Delay | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 Outgoing-Call-Connected AVP 2106 0 1 2 3 2107 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 |1|0|0|0| 6 | 0 | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | 16 | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 The Outgoing-Call-Connected AVP encodes the final result of an outgo- 2115 ing call request. The flags indicate a mandatory option. 2117 Result Code 2119 0 1 2 3 2120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 |1|0|0|0| 8 | 0 | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | 1601 | Result Code | 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 The Result Code indicates the result of the call attempt. The 2128 Attribute value is 1601, indicating Result Code, and is marked 2129 mandatory. This AVP MUST be present. The Result Code is a 16-bit 2130 value: 2132 1 - Call established with no errors 2133 2 - Outgoing Call not established for the reason indicated in Error Code 2134 3 - Outgoing Call failed due to no carrier detected 2135 4 - Outgoing Call failed due to detection of a busy signal 2136 5 - Outgoing Call failed due to lack of a dial tone 2137 6 - Outgoing Call was not established within time allotted by LAC 2138 7 - Outgoing Call was connected but no appropriate framing was detected 2140 Error Code AVP 2142 0 1 2 3 2143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 |1|0|0|0| 8 | 0 | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | 1602 | Error Code | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | Optional Message... | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 The Error Code AVP is used to encode a specific error code. 2153 Attribute is 1602, indicating Error Code, and is marked mandatory. 2154 This AVP is present only if the Result Code indicates a value of 2155 2. The value is encoded as specified in Section 5.5. 2157 Cause Code AVP 2159 0 1 2 3 2160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 |0|0|0|0| 9 + Advisory Msg len | 0 | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | 1603 | Cause Code | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | Cause Msg | Advisory Msg ... | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 The Cause Code AVP is used to give additional information in cases 2170 of call failure. The Attribute value is 1603, indicating Cause 2171 Code, and is marked mandatory. This AVP is optional. It is only 2172 relevant when the LAC uses Q.931/DSS1 for the outbound call 2173 attempt. Cause Code is the returned Q.931 Cause code and Cause 2174 Msg is the returned Q.931 message code (e.g., DISCONNECT) associ- 2175 ated with the Cause Code. Both values are returned in their 2176 native ITU encodings. An additional ASCII text Advisory Message 2177 may also be included (presence indicated by the AVP length) to 2178 further explain the call failure. 2180 Connect Speed AVP 2182 0 1 2 3 2183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 |1|0|0|0| 10 | 0 | 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 | 1604 | BPS (H) | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | BPS (L) | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 Connect Speed BPS AVP encodes the final negotiated speed for the 2193 connection. The Attribute value is 1604, indicating Connect 2194 Speed, and is marked mandatory. This AVP MUST be present if the 2195 call attempt is successful. The BPS value indicates the speed in 2196 bits/second. 2198 Framing Type AVP 2200 0 1 2 3 2201 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 |1|0|0|0| 10 | 0 | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | 1605 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 Framing Type AVP encodes the framing type for the call. The 2211 Attribute value is 1605, indicating Framing Type, and is marked 2212 mandatory. This AVP MUST be present if the call attempt is suc- 2213 cessful. The value bit field indicates the type of PPP framing is 2214 used for the call. If set, bit A indicates that asynchronous 2215 framing is being used. If set, bit S indicates that synchronous 2216 framing is being used. 2218 Packet Receive Window Size AVP 2220 0 1 2 3 2221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 |1|0|0|0| 8 | 0 | 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2225 | 1606 | Size | 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2228 Packet Receive Window Size AVP encodes the window size being 2229 offered by the LNS for this call. The Attribute value is 1606, 2230 indicating Packet Receive Window Size, and is marked mandatory. 2231 The Size is a 16-bit value indicating the number of received data 2232 packets the LAC will buffer for this call, which is also the maxi- 2233 mum number of data packets the LNS should send before waiting for 2234 an acknowledgment. This AVP MUST be present if and only if 2235 Sequence and Acknowledgment Numbers are to be used in the payload 2236 session for this call. 2238 Packet Processing Delay AVP 2240 0 1 2 3 2241 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 |1|0|0|0| 8 | 0 | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 | 1607 | Delay | 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 Packet Processing Delay AVP encodes the delay the LAC expects for processing 2249 a window full of packets sent by the LNS. 2250 The Attribute value 2251 is 1607, indicating Packet Processing Delay, and is marked mandatory. 2252 This AVP is optional. 2253 The Delay value is specified in units of 1/10 2254 seconds. Refer to Appendix A to see a 2255 description of how this value is determined and used. 2257 6.11 Incoming-Call-Request 2259 Incoming-Call-Request is an L2TP control message sent by the LAC 2260 to the LNS to indicate that an inbound call is to be established from 2261 the LAC. This request provides the LNS with parameter information 2262 for the incoming call. 2264 This message is the first in the "three-way handshake" used by L2TP 2265 for establishing incoming calls. The LAC may defer answering the 2266 call until it has received an Incoming-Call-Reply from the LNS 2267 indicating that the call should be established. This mechanism allows 2268 the LNS to obtain sufficient information about the call before it is 2269 answered to determine whether the call should be answered or not. 2270 Alternatively, the LAC may answer the call, negotiate LCP and 2271 PPP authentication, and use the information gained to choose the LNS. 2272 In this case, the call has already been answered by the time 2273 the Incoming-Call-Reply message is received; the LAC simply spoofs 2274 the "call indication/answer call" phase in this case. 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | L2TP Control Message Header | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Incoming-Call-Request | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | Assigned Call ID | 2282 | Call Serial Number | 2283 | Call Bearer Type | 2284 | Physical Channel Id | 2285 | Dialed Number | 2286 | Dialing Number | 2287 | Sub-Address | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 Incoming-Call-Request AVP 2292 0 1 2 3 2293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 |1|0|0|0| 7 | 0 | 2296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2297 | 9 | 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 The Incoming-Call-Request AVP encodes an incoming call being indi- 2301 cated by the LAC. The flags indicate a mandatory option. 2303 Assigned Call ID AVP 2305 0 1 2 3 2306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 |1|0|0|0| 8 | 0 | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2310 | 901 | Call ID | 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 The Assigned Call ID AVP encodes the Call ID being assigned to call 2314 by the LAC. The Attribute value is 901, indicating Call ID, and is 2315 marked mandatory. This AVP MUST be present. The LNS places this 2316 value in the Call ID header field of all command and payload packets 2317 that it subsequently transmits over the tunnel that belong to this 2318 call. The Call ID value is an identifier assigned by the LAC to this 2319 session. It is used to multiplex and demultiplex data sent over that 2320 tunnel between the LNS and LAC. 2322 Call Serial Number AVP 2324 0 1 2 3 2325 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 |1|0|0|0| 6 + Number length | 0 | 2328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2329 | 902 | Number... | 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 Call Serial Number AVP encodes an identifier assigned by the LAC to 2333 this call. The Attribute value is 902, Call Serial Number, and is 2334 marked mandatory. This AVP MUST be present. The Number value is an 2335 identifier assigned by the LAC and used by the LNS and the LAC for 2336 identifying the call. Unlike the Call ID, both the LNS and LAC asso- 2337 ciate the same Call Serial Number with a given call. 2339 Call Bearer Type AVP 2341 0 1 2 3 2342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 |1|0|0|0| 10 | 0 | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 | 903 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 Call Bearer Type AVP encodes the bearer type for the incoming call. 2352 The Attribute value is 903, Call Bearer Type, and is marked manda- 2353 tory. This AVP MUST be present. The Value is a 32-bit field indi- 2354 cating the bearer capability being used by the incoming call. If 2355 set, bit A indicates that the call is on an analog channel. If set, 2356 bit D indicates that the call is on a digital channel. 2358 Physical Channel ID AVP 2360 0 1 2 3 2361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 |1|0|0|0| 10 | 0 | 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 | 904 | ID (H) | 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 | ID (L) | 2368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 Physical Channel ID AVP encodes the vendor specific physical channel 2371 number used for the call. The Attribute value is 904, Physical Chan- 2372 nel ID, and is marked mandatory. The presence of this AVP is 2373 optional. ID is a 32-bit value in network byte order. The value is 2374 used for logging purposes only. 2376 Dialed Number AVP 2378 0 1 2 3 2379 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 |1|0|0|0| 6 + Number len | 0 | 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | 905 | Number... | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 Dialed Number AVP encodes the dialed number for the incoming call, 2387 that is, DNIS. The Attribute value is 905, Dialed Number, and is 2388 marked mandatory. The presence of this AVP is optional. The value 2389 is an ASCII string. 2391 Dialing Number AVP 2393 0 1 2 3 2394 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 |1|0|0|0| 6 + length | 0 | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | 906 | Number... | 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 Dialing Number AVP encodes the originating number for the incoming 2402 call, that is, CLID. The Attribute value is 906, Dialing Number, and 2403 is marked mandatory. The presence of this AVP is optional. The 2404 value is an ASCII string. 2406 Sub-Address AVP 2408 0 1 2 3 2409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 |1|0|0|0| 6 + length | 0 | 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 | 907 | Sub-Address...| 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 Sub-Address AVP encodes additional dialing information. The 2417 Attribute value is 907, Sub-Address, and is marked mandatory. The 2418 presence of this AVP is optional. The Sub-Address value is an ASCII 2419 string. 2421 6.12 Incoming-Call-Reply 2423 The Incoming-Call-Reply is an L2TP control message sent by the LNS to 2424 the LAC in response to a received Incoming-Call-Request message. The 2425 reply indicates the result of the incoming call attempt. It also 2426 provides information to allow the LAC to regulate the transmission of 2427 data to the LNS for this session. 2429 This message is the second in the three-way handshake used by L2TP 2430 for establishing incoming calls. It indicates to the LAC whether the 2431 call should be answered or not. 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | L2TP Control Message Header | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | Incoming-Call-Reply | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | Assigned Call ID | 2439 | Result Code | 2440 | Error Code | 2441 | Packet Recv. Window Size | 2442 | Packet Processing Delay | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 Incoming-Call-Reply AVP 2447 0 1 2 3 2448 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 |1|0|0|0| 6 | 0 | 2451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 | 10 | 2453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2455 The Incoming-Call-Reply AVP encodes a response by the LNS to the 2456 incoming call indication given by the LAC. The flags indicate a 2457 mandatory option. 2459 Assigned Call ID AVP 2461 0 1 2 3 2462 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 |1|0|0|0| 8 | 0 | 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 | 1001 | Call ID | 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 The Assigned Call ID AVP encodes the ID being assigned to call by the 2470 LNS. The Attribute value is 1001, Assigned Call ID, and is marked 2471 mandatory. This AVP MUST be present. The LAC places this value in 2472 the Call ID header field of all command and payload packets that it 2473 subsequently transmits over the tunnel that belong to this call. The 2474 Call ID value is an identifier assigned by the LNS to this session. 2475 It is used to multiplex and demultiplex data sent over that tunnel 2476 between the LNS and LAC. 2478 Result Code AVP 2480 0 1 2 3 2481 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 |1|0|0|0| 8 | 0 | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | 1002 | Result Code | 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 Result Code AVP encodes the result of the Incoming-Call-Request. The 2489 Attribute value is 1002, Result Code, and is marked mandatory. This 2490 AVP MUST be present. The Result Code value is a 16-bit value: 2492 1 - The LAC should answer the incoming call 2493 2 - The Incoming Call should not be established due to the reason 2494 indicated in Error Code 2495 3 - The LAC should not accept the incoming call. It should hang 2496 up or issue a busy indication 2498 Error Code AVP 2500 0 1 2 3 2501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 |1|0|0|0| 8 | 0 | 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 | 1003 | Error Code | 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 | Optional Message... | 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 This AVP is present only if a "General Error" exists, in which case 2511 Result Code was set to 2 and this AVP encodes the general error value 2512 as documented in section 5.5. It has a Value of 1003, and is marked 2513 mandatory. 2515 Packet Receive Window Size AVP 2517 0 1 2 3 2518 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 |1|0|0|0| 8 | 0 | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 | 1004 | Size (H) | Size (L) | 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 Packet Receive Window Size AVP encodes the receive window size being 2526 offered by the LNS for this call. The Attribute value is 1004, 2527 Packet Receive Window Size, and is marked mandatory. The Size value 2528 indicates the number of received data packets the LNS will buffer for 2529 this call, which is also the maximum number of data packets the LAC 2530 should send before waiting for an acknowledgment. This AVP is 2531 optional if Sequence and Acknowledgment Numbers are not to be used in 2532 the payload session for this call. 2534 Packet Processing Delay AVP 2536 0 1 2 3 2537 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 |1|0|0|0| 8 | 0 | 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 | 1005 | Delay (H) | Delay (L) | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2544 Packet Processing Delay AVP encodes the delay the LNS expects for 2545 processing a window full of packets sent by the LAC. The Attribute 2546 value is 1005, Packet Processing Delay AVP, and is marked mandatory. 2547 The presence of this AVP is optional. The Delay value is specified 2548 in units of 1/10 seconds. Refer to Appendix A to see a description 2549 of how this value is determined and used. 2551 6.13 Incoming-Call-Connected 2553 The Incoming-Call-Connected message is an L2TP control message sent 2554 by the LAC to the LNS in response to a received Incoming-Call-Reply. 2555 It provides information to the LNS about particular parameters used 2556 for the call. It also provides information to allow the LNS to regu- 2557 late the transmission of data to the LAC for this session. 2559 This message is the third in the three-way handshake used by L2TP for 2560 establishing incoming calls. It provides a mechanism for providing 2561 the LNS with additional information about the call that cannot, in 2562 general, be obtained at the time the Incoming-Call-Request is issued 2563 by the LAC. 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | L2TP Control Message Header | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | Incoming-Call-Connected | 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 | Connect Speed | 2571 | Framing Type | 2572 | Packet Recv. Window | 2573 | Packet Processing Delay | 2574 | Initial LCP Conf | 2575 | Last Sent LCP Conf | 2576 | Last Received LCP Conf | 2577 | Proxy authen type | 2578 | Proxy authen name | 2579 | Proxy authen challenge | 2580 | Proxy authen ID | 2581 | Proxy authen response | 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 Incoming-Call-Connected AVP 2586 0 1 2 3 2587 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 |1|0|0|0| 6 | 0 | 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 | 11 | 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 The Incoming-Call-Connected AVP encodes a response by the LAC to the 2595 Incoming-Call-Reply message sent by the LAC. The flags indicate a 2596 mandatory option. 2598 Connect Speed AVP 2600 0 1 2 3 2601 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 |1|0|0|0| 10 | 0 | 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 | 1101 | BPS (H) | 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 | BPS (L) | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 Connect Speed BPS AVP encodes the speed for the connection. The 2611 Attribute value is 1101, Connect Speed, and is marked mandatory. 2612 This AVP MUST be present if the call attempt is successful. The 2613 value is a 32-bit quantity indicating the speed in bits/second. 2615 Framing Type AVP 2617 0 1 2 3 2618 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 |1|0|0|0| 10 | 0 | 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2622 | 1102 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2624 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 Framing Type AVP encodes the framing type for the call. The 2628 Attribute value is 1102, Call Serial Number, and is marked mandatory. 2629 This AVP MUST be present if the call attempt is successful. The 2630 value is a 32-bit bit field indicating the type of PPP framing used 2631 for the call. If set, bit A indicates that asynchronous framing is 2632 being used. If set, bit S indicates that synchronous framing is 2633 being used. 2635 Packet Receive Window Size AVP 2637 0 1 2 3 2638 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 |1|0|0|0| 8 | 0 | 2641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 | 1103 | Size | 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 Packet Receive Window Size AVP encodes the window size being offered 2646 by the LAC for this call. The Attribute value is 1103, Packet 2647 Receive Window Size, and is marked mandatory. This AVP is optional 2648 if Sequence and Acknowledgment Numbers are not to be used in the pay- 2649 load session for this call. The 16-bit Size value indicates the num- 2650 ber of received data packets the LAC will buffer for this call, which 2651 is also the maximum number of data packets the LNS should send before 2652 waiting for an acknowledgment. 2654 Packet Processing Delay AVP 2656 0 1 2 3 2657 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 |1|0|0|0| 8 | 0 | 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 | 1104 | Delay | 2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 Packet Processing Delay AVP encodes the delay the LAC expects for 2665 processing a window full of packets sent by the LNS. The Attribute 2666 value is 1104, Packet Processing Delay, and is marked mandatory. The 2667 presence of this AVP is optional. The 16-bit Delay value is speci- 2668 fied in units of 1/10 seconds. Refer to Appendix A to see a descrip- 2669 tion of how this value is determined and used. 2671 Initial LCP Conf 2673 0 1 2 3 2674 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 |0|0|0|0| 6 + LCP confreq len | 0 | 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 | 1105 | LCP confreq...| 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 The LAC may have answered the phone call and negotiated LCP with the 2682 dial-in client in order to establish the client's apparent identity. 2683 In this case, this option may be included to indicate the link prop- 2684 erties the client requested in its initial LCP CONFREQ request. The 2685 Attribute value is 1105, Initial LCP Conf, and is marked optional. 2686 The presence of this AVP is optional. The Value field is a copy of 2687 the body of the initial CONFREQ received, starting at the first 2688 option within this packet's body. 2690 Last Sent LCP Conf 2692 0 1 2 3 2693 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 |0|0|0|0| 6 + LCP confreq len | 0 | 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | 1106 | LCP confreq...| 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 See Initial LCP Conf above for rationale. The Attribute value is 2701 1106, Last Sent LCP Conf, and is marked optional. The presence of 2702 this AVP is optional. The Value field is a copy of the body of the 2703 final CONFREQ sent to the client to complete LCP negotiation, start- 2704 ing at the first option within this packet's body. 2706 Last Received LCP Conf 2708 0 1 2 3 2709 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 |0|0|0|0| 6 + LCP confreq len | 0 | 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 | 1107 | LCP confreq...| 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 See Initial LCP Conf above for rationale. The Attribute value is 2717 1107, Last Received LCP Conf, and is marked optional. The presence 2718 of this AVP is optional. The Value field is a copy of the body of 2719 the final CONFREQ received from the client to complete LCP negotia- 2720 tion, starting at the first option within this packet's body. 2722 Proxy Authen Type 2724 0 1 2 3 2725 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 |1|0|0|0| 8 | 0 | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | 1108 | Type | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 The Attribute value is 1108, Proxy Authen Type, and is marked manda- 2733 tory. This AVP MUST be present. The value Type is a 16-bit word, 2734 holding a value: 2736 1 - Textual username/password exchange 2737 2 - PPP CHAP 2738 3 - PPP PAP 2739 4 - None 2741 Associated AVP's for each type of authentication follow. 2743 Proxy Authen Name 2744 0 1 2 3 2745 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 |0|0|0|0| 6 + length | 0 | 2748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2749 | 1109 | Name... | 2750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 The Attribute value is 1109, Proxy Authen Name, and is marked manda- 2753 tory. This AVP MUST be present for Proxy Authen Type values 1, 2, 2754 and 3. The Name field contains the name specified in the client's 2755 authentication response. Note that the AVP H bit may be desirable 2756 for obscuring the cleartext name. 2758 Proxy Authen Challenge 2760 0 1 2 3 2761 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 |0|0|0|0| 6 + length | 0 | 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 | 1110 | Challenge... | 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 The Attribute value is 1110, Proxy Authen Challenge, and is marked 2769 mandatory. The AVP itself MUST be present for Proxy authen type 2. 2770 The Challenge field contains the value presented to the client by the 2771 LAC. 2773 Proxy Authen ID 2775 0 1 2 3 2776 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 |0|0|0|0| 8 | 0 | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 | 1111 | ID | 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 The Attribute value is 1111, Proxy Authen ID, and is marked manda- 2784 tory. The AVP itself MUST be present for Proxy authen type 2. The 2785 ID field contains the byte ID value presented to the client by the 2786 LAC in its associated CHAP challenge. The most significant 8 bits of 2787 ID MUST be 0, and are reserved. 2789 Proxy Authen Response 2791 0 1 2 3 2792 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 |1|0|0|0| 6 + length | 0 | 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 | 1112 | Response... | 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 The Attribute value is 1112, Proxy Authen Response, and is marked 2799 mandatory. The AVP itself MUST be present for Proxy authen types 1, 2800 2, and 3. The Response field contains the client's response to the 2801 challenge. For Proxy authen type 2, this field contains the response 2802 value received by the LAC. For types 1 or 3, it contains the clear 2803 text password received from the client by the LAC. In the case of 2804 cleartext passwords, use of the AVP H bit is recommended. 2806 6.14 Call-Clear-Request 2808 The Call-Clear-Request is an L2TP control message sent by the LNS to 2809 the LAC indicating that a particular call is to be disconnected. The 2810 call being cleared can be either an incoming or outgoing call, in any 2811 state. The LAC responds to this message with a Call-Disconnect- 2812 Notify message. 2814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2815 | L2TP Control Message Header | 2816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2817 | Call-Clear-Request | 2818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 | Assigned Call ID | 2820 +-+-+-+-+-+-+-+-+-+-+-+-+ 2822 Call-Clear-Request AVP 2824 0 1 2 3 2825 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 |1|0|0|0| 6 | 0 | 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | 12 | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 The Call-Clear-Request AVP encodes a request by the LNS to the LAC to 2833 disconnect the call. The flags indicate a mandatory option. 2835 Assigned Call ID AVP 2837 0 1 2 3 2838 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 |1|0|0|0| 8 | 0 | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 | 1201 | Call ID | 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2845 This attribute is used to provide the LAC with the Call ID assigned 2846 by the LNS for the call to be cleared in the case where the LNS has 2847 not yet learned the LAC's Call ID for the call. The Attribute value 2848 is 1201, Assigned Call ID, and is marked mandatory. This AVP MUST be 2849 present. The value Call ID MUST be the same value sent from the LNS 2850 to the LAC in the initial call setup exchange. 2852 6.15 Call-Disconnect-Notify 2854 The Call-Disconnect-Notify message is an L2TP control message sent by 2855 the LAC to the LNS. It is issued whenever a call is disconnected, 2856 due to the receipt by the LAC of a Call-Clear-Request or for any 2857 other reason. Its purpose is to inform the LNS of the disconnection 2858 and the reason why the disconnection occurred. 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2861 | L2TP Control Message Header | 2862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2863 | Call-Disconnect-Notify | 2864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 | Result Code | 2866 | Error Code | 2867 | Cause Code | 2868 | Assigned Call ID | 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 Call-Disconnect-Notify AVP 2873 0 1 2 3 2874 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 |1|0|0|0| 6 | 0 | 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 | 13 | 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2881 The Call-Disconnect-Notify AVP encodes a disconnect indication from 2882 the LAC to the LNS. The flags indicate a mandatory option. 2884 Result Code AVP 2886 0 1 2 3 2887 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 |1|0|0|0| 8 | 0 | 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | 1301 | Result Code | 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2894 Result Code AVP encodes the reason for disconnect. The Attribute 2895 value is 1301, Result Code, and is marked mandatory. This AVP MUST 2896 be present. The Result Code value can be one of: 2898 1 (Lost Carrier) - Call disconnected due to loss of carrier 2899 2 (General Error) - Call disconnected for the reason indicated in 2900 Error Code. 2901 3 (Admin Shutdown) - Call disconnected for administrative reasons 2902 4 (Request) - Call disconnected due to received Call-Clear-Request 2904 Error Code AVP 2905 0 1 2 3 2906 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2908 |1|0|0|0| 8 | 0 | 2909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2910 | 1302 | Error Code | 2911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 | Optional Message... | 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2915 This AVP is present only if a "General Error" exists, in which case 2916 Result Code was set to 2 and this AVP encodes the general error value 2917 as documented in section 5.5. The Attribute value is 1302, Error 2918 Code, and is marked mandatory. This AVP MUST be present if Result 2919 Code was 2. 2921 Cause Code AVP 2923 0 1 2 3 2924 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2926 |1|0|0|0| 8 | 0 | 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2928 | 1303 | Cause Code | 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2930 | Optional message... | 2931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 The Cause Code AVP is used to give additional information in case of 2934 unsolicited call disconnection. The Attribute value is 1303, Cause 2935 Code, and is marked mandatory. The presence of this AVP is optional. 2936 The Cause Code AVP is used to give additional information about the 2937 reason for disconnecting. It is only relevant when the LAC is using 2938 Q.931/DSS1 for the call. This AVP is optional. Cause Code is the 2939 returned Q.931 Cause code and Cause Msg is the returned Q.931 message 2940 code (e.g., DISCONNECT) associated with the Cause Code. Both values 2941 are returned in their native ITU encodings. An additional Ascii text 2942 Advisory Message may also be included (presence indicated by the AVP 2943 length) to further explain the reason for disconnecting. 2945 Assigned Call ID AVP 2947 0 1 2 3 2948 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2950 |1|0|0|0| 8 | 0 | 2951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2952 | 1304 | Call ID | 2953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 The Assigned Call ID which was provided to the LNS from this LAC is 2956 included in the Call-Disconnect-Notify message. This permits a con- 2957 nection to be terminated even before the LNS has provided its own 2958 Assigned Call ID to this LAC (the Call ID field in the control 2959 message header is 0). The Attribute value is 1304, Assigned Call ID, 2960 and is marked mandatory. This AVP MUST be present. 2962 6.16 WAN-Error-Notify 2964 The WAN-Error-Notify message is an L2TP control message sent by the 2965 LAC to the LNS to indicate WAN error conditions (conditions that 2966 occur on the interface supporting PPP). The counters in this message 2967 are cumulative. This message should only be sent when an error 2968 occurs, and not more than once every 60 seconds. The counters are 2969 reset when a new call is established. 2971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2972 | L2TP Control Message Header | 2973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 | WAN-Error-Notify | 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 | Call Errors | 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2979 WAN-Error-Notify AVP 2981 0 1 2 3 2982 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2984 |1|0|0|0| 6 | 0 | 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2986 | 14 | 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2989 The WAN-Error-Notify AVP encodes line and other errors sent by the 2990 LAC to the LNS. The flags indicate a mandatory option. 2992 Call Errors AVP 2994 0 1 2 3 2995 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2997 |1|0|0|0| 32 | 0 | 2998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2999 | 1401 | Reserved | 3000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3001 | CRC Errors | 3002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3003 | Framing Errors | 3004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3005 | Hardware Overruns | 3006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3007 | Buffer Overruns | 3008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3009 | Time-out Errors | 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3011 | Alignment Errors | 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 The Call Errors AVP is used by the LAC to send error information to 3014 the LNS. The Attribute value is 1401, WAN-Error-Notify, and is 3015 marked mandatory. This AVP MUST be present. The value contains the 3016 following fields: 3018 Reserved - Not used, MUST be 0 3019 CRC Errors - Number of PPP frames received with CRC errors since 3020 session was established 3021 Framing Errors - Number of improperly framed PPP packets received 3022 Hardware Overruns - Number of receive buffer over-runs since ses- 3023 sion was established 3024 Buffer Overruns - Number of buffer over-runs detected since ses- 3025 sion was established 3026 Time-out Errors - Number of time-outs since call was established 3027 Alignment Errors - Number of alignment errors since call was 3028 established 3030 6.17 Set-Link-Info 3032 The Set-Link-Info message is an L2TP control message sent by the LNS 3033 to the LAC to set PPP-negotiated options. Because these options can 3034 change at any time during the life of the call, the LAC MUST be able 3035 to update its internal call information dynamically and update its 3036 behavior on an active PPP session. 3038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3039 | L2TP Control Message Header | 3040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3041 | Set-Link-Info | 3042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3043 | ACCM | 3044 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3046 Set-Link-Info AVP 3048 0 1 2 3 3049 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 |1|0|0|0| 6 | 0 | 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 | 15 | 3054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3056 The Set-Link-Info AVP encodes ACCM information sent from the LNS to 3057 the LAC after it is negotiated in LCP. The flags indicate a manda- 3058 tory option. 3060 ACCM AVP 3062 0 1 2 3 3063 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 |1|0|0|0| 32 | 0 | 3066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3067 | 1501 | Reserved | 3068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3069 | Send ACCM | 3070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3071 | Receive ACCM | 3072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3074 The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. 3075 The Attribute value is 1501, ACCM, and is marked mandatory. The 3076 presence of this AVP is optional. The value contains Send ACCM and 3077 Receive ACCM fields. The send ACCM value should be used by the LAC 3078 to process packets it is sends on the connection. The receive ACCM 3079 value should be used by the LAC to process incoming packets on the 3080 connection. The default values used by the LAC for both these fields 3081 are 0xFFFFFFFF. The LAC should honor these fields unless it has spe- 3082 cific configuration information to indicate that the requested mask 3083 must be modified to permit operation. 3085 7.0 Control Connection State Machines 3087 The control messages defined in section 6 are exchanged by way of state 3088 tables defined in this section. Tables are defined for incoming call 3089 placement, outgoing call placement, as well as for initiation of the 3090 tunnel itself. The state tables do not encode timeout and retransmis- 3091 sion behavior, as this is handled in the underlying semantics defined in 3092 6.0.2. 3094 7.1 Control Connection Protocol Operation 3096 This section describes the operation of various L2TP control connec- 3097 tion functions and the Control Connection messages which are used to 3098 support them. 3100 Receipt of an invalid or malformed Control Connection message should 3101 be logged appropriately, and the control connection should be closed 3102 and restarted to ensure recovery into a known state. 3104 7.2 Control Connection States 3106 Control messages are carried over the same media as the payload mes- 3107 sages which are carried following successful connection establish- 3108 ment. The L2TP control connection protocol is not distinguishable 3109 between the LNS and LAC, but is distinguishable between the origina- 3110 tor and receiver. The originating peer is the one which first estab- 3111 lishes the tunnel. Since either LAC or LNS can be the originator, a 3112 collision can occur. See Section 6.0.1 for a description of this and 3113 its resolution situation. 3115 7.2.1 Control Connection Originator 3117 State Event Action New State 3118 ----- ----- ------ --------- 3120 idle Open request Send wait-ctl-reply 3121 Start-Control- 3122 Connection-Request 3124 wait-ctl-reply Collision If terminating, idle 3125 clean-up. 3127 wait-ctl-reply Collision If not terminating, wait-stop-reply 3128 Send Stop-Control- 3129 Connection-Request 3131 wait-ctl-reply Receive If version OK established 3132 Start-Control- Send Start-Control- 3133 Connection-Reply Connection-Connected 3135 wait-ctl-reply Receive If version not OK wait-stop-reply 3136 Start-Control- or bad auth, Send 3137 Connection-Reply Stop-Control- 3138 Connection-Request 3140 established Local terminate Send wait-stop-reply 3141 Stop-Control- 3142 Connection-Request 3144 established Receive Send idle 3145 Stop-Control- Stop-Control- 3146 Connection- Connection-Reply 3147 Request and clean-up 3149 wait-stop-reply Receive Clean-up idle 3150 Stop-Control- 3151 Connection-Reply 3153 idle 3154 The control connection originator attempts to open a connection to 3155 the peer during idle state. When the connection is open, the 3156 originator transmits a send Start-Control-Connection-Request and 3157 then enters the wait-ctl-reply state. 3159 wait-ctl-reply 3160 The originator checks to see if another connection has been 3161 requested from the same peer, and if so, handles the collision 3162 situation described in Section 6.0.1. 3164 When a Start-Control-Connection-Reply is received, it is examined 3165 for a compatible version. If the version of the reply is lower 3166 than the version sent in the request, the older (lower) version 3167 should be used provided it is supported. If the version in the 3168 reply is earlier and supported, the originator moves to the estab- 3169 lished state. If the version is earlier and not supported, a 3170 Stop-Control-Connection-Request SHOULD be sent to the peer and the 3171 originator moves into the wait-stop-reply state. 3173 established 3174 An established connection may be terminated by either a local 3175 condition or the receipt of a Stop-Control-Connection-Request. In 3176 the event of a local termination, the originator MUST send a Stop- 3177 Control-Connection-Request and enter the wait-stop-reply state. 3179 If the originator receives a Stop-Control-Connection-Request it 3180 SHOULD send a Stop-Control-Connection-Reply and close the connec- 3181 tion. 3183 wait-stop-reply 3184 If a Stop-Control-Connection-Reply is received, the connection 3185 SHOULD be closed and the control connection becomes idle. 3187 7.2.2 Control connection Receiver 3189 State Event Action New State 3190 ----- ----- ------ --------- 3191 idle Receive If version not OK idle 3192 Start-Control- send 3193 Connection-Request Start-Control- 3194 Connection-Reply 3195 with error 3197 idle Receive Version OK, send wait-ctl-reply 3198 Start-Control- Start-Control- 3199 Connection-Request Connection-Reply 3201 wait-ctl-reply Receive Clean-up, send idle 3202 Stop-Control- Stop-Control- 3203 Connection-Request Connection-Reply 3205 wait-ctl-reply Receive If auth OK established 3206 Start-Control- 3207 Connection-Connected 3209 wait-ctl-reply Receive If auth not OK wait-stop-reply 3210 Start-Control- Send Stop-Control- 3211 Connection- Connection-Request 3212 Connected 3214 established Receive Clean-up, send idle 3215 Stop-Control- Stop-Control- 3216 Connection-Request Connection-Reply 3218 established Local terminate Send wait-stop-reply 3219 Stop-Control- 3220 Connection-Request 3222 wait-stop-reply Receive Clean-up idle 3223 Stop-Control- 3224 Connection-Reply 3226 idle 3227 The control connection receiver waits for an incoming connection 3228 attempt. When notified of a new connection, it should prepare to 3229 receive L2TP messages. When a Start-Control-Connection-Request is 3230 received its version field MUST be examined. If the version is 3231 earlier than the receiver's version and the earlier version can be 3232 supported by the receiver, the receiver SHOULD send a 3233 Start-Control-Connection-Reply. 3235 If the version is earlier than the receiver's 3236 version and the version cannot be supported, the receiver SHOULD send 3237 a Start-Connection-Reply message indicating this error and remain in 3238 the idle state. If the receiver's version is the same as 3239 or earlier than the peer's, the receiver SHOULD send a 3240 Start-Control-Connection-Reply with the receiver's version and enter the 3241 wait-ctl-reply state. 3243 wait-ctl-reply 3245 The peer waits in this state after sending a Start-Control-Connection-Reply. 3246 If it receives a Start-Control-Connection-Reply, it checks to see if the 3247 message is properly authenticated and, if so, it enters the established 3248 state. 3249 If authentication fails, a Stop-Control-Connection-Request with the reason 3250 code set appropriately is sent and wait-stop-reply state is entered. 3251 if a Stop-Control-Connection-Request is received, a 3252 Stop-Control-Connection-Reply. is issued and idle state is entered. 3254 established 3255 An established connection may be terminated by either a local 3256 condition or the reception of a Stop-Control-Connection-Request. In 3257 the event of a local termination, the originator MUST send a 3258 Stop-Control-Connection-Request 3259 and enter the wait-stop-reply state. 3261 If the originator receives a Stop-Control-Connection-Request it 3262 SHOULD send a Stop-Control-Connection-Reply and close the 3263 connection. 3265 wait-stop-reply 3266 If a Stop-Control-Connection-Reply is received, the connection 3267 SHOULD be closed and the control connection becomes idle. 3269 7.3 Timing considerations 3271 Because of the real-time nature of telephone signaling, both the LNS 3272 and LAC should be implemented with multi-threaded architectures such 3273 that messages related to multiple calls are not serialized and 3274 blocked. 3275 The call and connection state figures do not specify 3276 exceptions caused by timers. These are addressed in Section 6.0.2. 3278 7.4 Incoming calls 3280 An Incoming-Call-Request message is generated by the LAC when an 3281 associated telephone line rings. The LAC selects a Call ID and serial 3282 number and indicates the call bearer type. Modems should always 3283 indicate analog call type. ISDN calls should indicate digital when 3284 unrestricted digital service or rate adaption is used and analog if 3285 digital modems are involved. CLID, DNIS, and 3286 subaddress may be included in the message if they are available from 3287 the telephone network. 3289 Once the LAC sends the Incoming-Call-Request, it waits for a response 3290 from the LNS but it does not necessarily answer the call from the 3291 telephone network yet. The LNS may choose not to accept the call if: 3293 - No resources are available to handle more sessions 3294 - The dialed, dialing, or subaddress fields are not indicative of 3295 an authorized user 3296 - The bearer service is not authorized or supported 3298 If the LNS chooses to accept the call, it responds with an 3299 Outgoing-Call-Reply 3300 which also indicates window sizes (see Appendix B). When 3301 the LAC receives the Outgoing-Call-Reply, it attempts to connect the 3302 call, assuming the calling party has not hung up. A final call 3303 connected message from the LAC to the LNS indicates that the call 3304 states for both the LAC and the LNS should enter the established 3305 state. 3307 When the dialed-in client hangs up, the call is cleared normally and 3308 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 3309 clear a call, it sends a Call-Clear-Request message and then waits 3310 for a Call-Disconnect-Notify. 3312 7.4.1 LAC Incoming Call States 3314 State Event Action New State 3315 ----- ----- ------ --------- 3316 idle Ring OR Send wait-reply 3317 Ready to indicate Incoming-Call-Request 3318 incoming conn. 3320 wait-reply Receive Clean-up idle 3321 Incoming-Call-Reply 3322 Not Accepting 3324 wait-reply Receive Answer call established 3325 Incoming-Call-Reply Send 3326 Accepting Incoming-Call-Connected 3328 wait-reply Abort Clean-up idle 3329 Send Call-Disconnect- 3330 Notify 3332 established Receive Hang-up and send idle 3333 Call-Clear-Request Call-Disconnect-Notify 3335 established telco line drop Send idle 3336 Call-Disconnect-Notify 3338 established local disconnect Send idle 3339 Call-Disconnect-Notify 3341 The states associated with the LAC for incoming calls are: 3343 idle 3345 The LAC detects an incoming call on one of its telco interfaces. 3346 Typically this means an analog line is ringing or an ISDN TE has 3347 detected an incoming Q.931 SETUP message. The LAC sends an Incoming- 3348 Call-Request message and moves to the wait-reply state. 3350 wait-reply 3352 The LAC receives an Incoming-Call-Reply message indicating non- will- 3353 ingness to accept the call (general error or don't accept) and moves 3354 back into the idle state. If the reply message indicates that the 3355 call is accepted, the LAC sends an Incoming-Call-Connected message 3356 and enters the established state. 3358 established 3360 Data is exchanged over the tunnel. The call may be cleared follow- 3361 ing: 3362 An event on the telco connection. The LAC sends a Call- 3363 Disconnect-Notify message 3364 Receipt of a Call-Clear-Request. The LAC sends a Call-Disconnect- 3365 Notify message 3366 A local reason. The LAC sends a Call-Disconnect-Notify message. 3368 7.4.2 LNS Incoming Call States 3370 State Event Action New State 3371 ----- ----- ------ --------- 3372 idle Receive If not accepting idle 3373 Incoming-Call-Request Send 3374 Incoming-Call-Reply 3375 with Error 3377 idle Receive If accepting wait-connect 3378 Incoming-Call-Request Send 3379 Incoming-Call-Reply 3381 wait-connect Receive Clean-up idle 3382 Call-Disconnect-Notify 3384 wait-connect Receive Get ready for data established 3385 Incoming-Call-Connect 3387 established Receive Clean-up idle 3388 Call-Disconnect-Notify 3390 established Local terminate Send wait- 3391 Call-Clear-Request disconnect 3393 wait- Receive Clean-up idle 3394 disconnect Call-Disconnect-Notify 3396 The states associated with the LNS for incoming calls are: 3398 idle 3400 An Incoming-Call-Request message is received. If the request is 3401 not acceptable, an Incoming-Call-Reply is sent back to the LAC and 3402 the LNS remains in the idle state. If the Incoming-Call-Request 3403 message is acceptable, an Incoming-Call-Reply is sent indicating 3404 accept in the result code. The session moves to the wait-connect 3405 state. 3407 wait-connect 3409 If the session is still connected on the LAC, the LAC sends an 3410 incoming call connect message to the LNS which then moves into 3411 established state. The LAC may send a Call-Disconnect-Notify to 3412 indicate that the incoming caller could not be connected. This 3413 could happen, for example, if a telephone user accidentally places 3414 a standard voice call to an LAC resulting in a handshake failure 3415 on the called modem. 3417 established 3419 The session is terminated either by receipt of a Call-Disconnect- 3420 Notify message from the LAC or by sending a Call-Clear-Request. 3421 Once a Call-Clear-Request has been sent, the session enters the 3422 wait-disconnect state. 3424 wait-disconnect 3426 Once a Call-Disconnect-Notify is received the session moves back 3427 to the idle state. 3429 7.5 Outgoing calls 3431 Outgoing calls are initiated by an LNS and instruct an LAC to place a 3432 call on a telco interface. There are three messages for outgoing calls: 3433 Outgoing-Call-Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. 3434 The LNS sends an Outgoing-Call-Request specifying the dialed party phone 3435 number and subaddress as well as speed and window parameters. The LAC 3436 MUST respond to the Outgoing-Call-Request message with an Outgoing-Call- 3437 Reply message once the LAC determines that the proper facilities exist 3438 to place the call and the call is administratively authorized. For 3439 example, is this LNS allowed to dial an international call? Once the 3440 outbound call is connected the LAC sends an Outgoing-Call-Connected mes- 3441 sage to the LNS indicating the final result of the call attempt: 3443 7.5.1 LAC Outgoing Call States 3444 State Event Action New State 3445 ----- ----- ------ --------- 3446 idle Receive If cannot service, idle 3447 Outgoing-Call- send Outgoing-Call-Reply 3448 Request with Error 3450 idle Receive If can service, wait-cs-ans 3451 Outgoing-Call- send 3452 Request Outgoing-Call-Reply 3454 wait-cs-ans Telco answer Send established 3455 and framing Outgoing-Call-Connected 3456 detected 3458 wait-cs-ans Call failure Send 3459 Outgoing-Call-Connected idle 3460 with Error 3462 wait-cs-ans Receive Hang-up, send idle 3463 Call-Clear-Request Call-Disconnect-Notify 3465 established Receive Hang-up, send idle 3466 Call-Clear-Request Call-Disconnect-Notify 3467 or detect call 3468 disconnected 3470 The states associated with the LAC for outgoing calls are: 3472 idle 3474 Received Outgoing-Call-Request. If this is received in error, 3475 respond with an Outgoing-Call-Reply with error condition set. 3476 Otherwise, allocate physical channel to dial on and send an Outgo- 3477 ing-Call-Reply. Place the outbound call and move to the wait-cs- 3478 ans state. 3480 wait-cs-ans 3482 If the call is not completed or a timer expires waiting for the 3483 call to complete, send an Outgoing-Call-Connected with the appro- 3484 priate error condition set and go to idle state. If a circuit 3485 switched connection is established and framing is detected, send 3486 an Outgoing-Call-Reply indicating success and go to established 3487 state. 3489 established 3491 If a Call-Clear-Request is received, the telco call SHOULD be 3492 released via appropriate mechanisms and a Call-Disconnect-Notify 3493 message SHOULD BE sent to the LNS. If the call is disconnected by 3494 the client or by the telco interface, a Call-Disconnect-Notify 3495 message MUST be sent to the LNS. Return to idle state after send- 3496 ing the Call-Disconnect-Notify. 3498 7.5.2 LNS Outgoing Call States 3500 State Event Action New State 3501 ----- ----- ------ --------- 3502 idle Open request Send wait-reply 3503 Outgoing-Call-Request 3505 wait-reply Receive Clean-up idle 3506 Outgoing-Call-Reply 3507 with Error 3509 wait-reply Receive Null wait-connect 3510 Outgoing-Call-Reply 3512 wait-reply Abort request Send wait-disconnect 3513 Call-Clear-Request 3515 wait-connect Abort request Send 3516 Call-Clear-Request wait-disconnect 3518 wait-connect Receive Get ready for data established 3519 Outgoing-Call-Connected 3520 no Error 3522 wait-connect Receive Clean-up idle 3523 Outgoing-Call-Connected 3524 with Error 3526 established Receive Clean-up idle 3527 Call-Disconnect-Notify 3529 established Local terminate Send wait-disconnect 3530 Call-Clear-Request 3532 wait-disconnect Receive Clean-up idle 3533 Call-Disconnect- 3534 Notify 3536 The states associated with the LNS for outgoing calls are: 3538 idle 3539 An Outgoing-Call-Request message is sent to the LAC and the ses- 3540 sion moves into the wait-reply state. 3542 wait-reply 3543 An Outgoing-Call-Reply is received which indicates an error. The 3544 session returns to idle state. If the Outgoing-Call-Reply does 3545 not indicate an error, the telco call is connected and the session 3546 moves to the established state. 3548 wait-connect 3549 An Outgoing-Call-Connected is received which indicates an error. 3550 The session returns to idle state. No telco call is active. If 3551 the Outgoing-Call-Connected does not indicate an error, the telco 3552 call is 3554 established 3555 If a Call-Disconnect-Notify is received, the telco call has been 3556 terminated for the reason indicated in the Result and Cause Codes. 3557 The session moves back to the idle state. If the LNS chooses to 3558 terminate the session, it sends a Call-Clear-Request to the LAC 3559 and then enters the wait-disconnect state. 3561 wait-disconnect 3562 A session disconnection is waiting to be confirmed by the LAC. 3563 Once the LNS receives the Call-Disconnect-Notify message, the ses- 3564 sion enters idle state. 3566 8.0 L2TP Over Specific Media 3568 L2TP tries to be self-describing, operating at a level above the par- 3569 ticular media over which it is carried. However, some details of its 3570 connection to media are required to permit interoperable implementa- 3571 tions. The following sections describe details needed to permit 3572 interoperability over specific media. 3574 8.1 IP/UDP 3576 L2TP uses the well-known UDP port 1701 [3]. The entire L2TP packet, 3577 including payload and L2TP header, is sent within a UDP datagram. 3578 The source and destination ports are the same (1701), with demulti- 3579 plexing being achieved using Tunnel ID values. It is legal for the 3580 source IP address of a given Tunnel ID to change over the life of a 3581 connection, as this may correspond to a peer with multiple IP inter- 3582 faces responding to a network topology change. Responses should 3583 reflect the last source IP address for that Tunnel ID. 3585 IP fragmentation may occur as the L2TP packet travels over the IP 3586 substrate. L2TP makes no special efforts to optimize this. A LAC 3587 implementation MAY cause its LCP to negotiate for a specific MRU, 3588 which could optimize for LAC environments in which the MTUs of the 3589 path over which the L2TP packets are likely to travel have a consis- 3590 tent value. 3592 Because a single UDP port is used for all packets, both the I and C 3593 bits MUST be used to permit correct demultiplexing. 3595 Port 1701 is used for both L2F [5] and L2TP packets. The two types 3596 of packets may be detected by their headers; L2TP has a Vers field of 3597 2, L2F has a 1 in this field instead. 3599 8.2 IP 3601 When operating directly over IP, protocol number TBD [3] is used to 3602 encode the packet as L2TP-over-IP. IP source address and MTU issues 3603 are identical to 8.1, except that the lack of a UDP header makes the 3604 packet more compact. As in IP/UDP, the I and C bits MUST be present. 3606 9.0 Security Considerations 3608 L2TP encounters several security issues in its operation. The gen- 3609 eral approach of L2TP to these issues is documented here. 3611 9.1 Tunnel Endpoint Security 3613 The tunnel endpoints may authenticate each other during tunnel 3614 establishment. This authentication has the same security 3615 attributes as CHAP, and has reasonable protection against reply 3616 and snooping. 3618 Once the tunnel endpoints have authenticated, a derived Key may be 3619 carried in subsequent packets, which provides mild protection 3620 against brief or "accidental" attacks. There is no cryptographic 3621 strength to these Keys, and any attacker which can snoop packets 3622 can take control of the tunnel. 3624 For L2TP tunnels over IP, IP-level packet security provides very 3625 strong protection of the tunnel. This requires no modification to 3626 the L2TP protocol, and leverages extensive IETF work in this area. 3628 For L2TP tunnels over Frame Relay or other switched networks, cur- 3629 rent practice indicates that these media are much less likely to 3630 experience attacks of in-transit data. If these attacks became 3631 prevalent, either the media or the L2TP packets would have to be 3632 encrypted. 3634 9.2 Client Security 3636 A more systematic method of protection in tunneled PPP environ- 3637 ments may be achieved through client security. PPP layer encryp- 3638 tion would provide end-to-end security for both direct dial-in 3639 clients as well as PPP clients carried within a tunnel. With this 3640 level of client security, sessions are protected against attacks 3641 against the carrying tunnel, as well as attacks on the LAC itself. 3642 Because both encryption and compression can occur at the PPP 3643 layer, the two can be coordinated, permitting compression to pre- 3644 cede encryption. 3646 9.3 Proxy Authentication 3648 The optional proxy CHAP function of L2TP can permit an entirely 3649 transparent PPP tunnel, with a single LCP and CHAP sequence being 3650 seen by the client. For cases where the LAC and the entire path 3651 to the LNS are operated by a single entity, this function may pro- 3652 vide acceptable security. For cases where LNS-initiated authenti- 3653 cation is required, proxy CHAP still permits an initial access 3654 decision to be made before accepting the tunnel, permitting the 3655 LNS in most cases to reject tunnel initiations rather than accept 3656 them and later disconnect. 3658 The optional proxy PAP may result in the cleartext password 3659 traversing the tunnel. Where PAP is being used in conjunction 3660 with static passwords, this may pose a significant security issue. 3661 Where PAP is only used to transport one-time passwords, such 3662 issues may be greatly mitigated. The H bit of the carrying AVP 3663 may be used to protect against this. 3665 10.0 Acknowledgments 3667 The AVP construct comes from Glen Zorn, who thought up the framework 3668 for permitting multiple vendors to contribute to a common attribute 3669 space in a relatively orderly fashion. 3671 Dory Leifer and Allan Rubens of Ascend Communications made valuable 3672 refinements to the protocol definition of L2TP and contributed to the 3673 editing of this document. 3675 11.0 Contacts 3677 Kory Hamzeh 3678 Ascend Communications 3679 1275 Harbor Bay Parkway 3680 Alameda, CA 94502 3681 kory@ascend.com 3683 Tim Kolar, Morgan Littlewood, Andrew J. Valencia 3684 Cisco Systems 3685 170 West Tasman Drive 3686 San Jose CA 95134-1706 3687 tkolar@cisco.com 3688 littlewo@cisco.com 3689 vandys@cisco.com 3691 Gurdeep Singh Pall 3692 Microsoft Corporation 3693 Redmond, WA 3694 gurdeep@microsoft.com 3696 Jeff Taarud 3697 (formerly of 3COM Corporation, no current contact) 3699 William Verthein 3700 U.S. Robotics 3702 12.0 References 3704 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 3705 07/21/1994 3707 [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet 3708 draft, April 1996 3710 [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point 3711 Tunneling Protocol", Internet draft, June 1996 3713 [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC1034, 3714 November 1987 3716 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, 3717 USC/Information Sciences Institute, July 1992. 3719 [6] Sally Floyd, Van Jacobson, "Random Early Detection Gateways for 3720 Congestion Avoidance", IEEE/ACM Transactions on Networking, 3721 August 1993 3723 [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, 3724 October 1996 3726 [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authentication 3727 Dial In User Service (RADIUS)." draft-ietf-radius-radius-05.txt, 3728 Livingston, Merit, Daydreamer, July 1996. 3730 Appendix A: Acknowledgment Time-Outs 3732 L2TP uses sliding windows and time-outs to provide both user session 3733 flow-control across the underlying medium (which may be an internet- 3734 work) and to perform efficient data buffering to keep the LAC-LNS 3735 data channels full without causing receive buffer overflow. L2TP 3736 requires that a time-out be used to recover from dropped data or 3737 acknowledgment packets. The exact implementation of the time-out is 3738 vendor-specific. It is suggested that an adaptive time-out be imple- 3739 mented with backoff for congestion control. The time-out mechanism 3740 proposed here has the following properties: 3742 Independent time-outs for each session. A device (LAC or LNS) 3743 will have to maintain and calculate time-outs for every active 3744 session. 3746 An administrator-adjustable maximum time-out, MaxTimeOut, unique 3747 to each device. 3749 An adaptive time-out mechanism that compensates for changing 3750 throughput. To reduce packet processing overhead, vendors may 3751 choose not to recompute the adaptive time-out for every received 3752 acknowledgment. The result of this overhead reduction is that the 3753 time-out will not respond as quickly to rapid network changes. 3755 Timer backoff on time-out to reduce congestion. The backed-off 3756 timer value is limited by the configurable maximum time-out value. 3757 Timer backoff is done every time an acknowledgment time-out 3758 occurs. 3760 In general, this mechanism has the desirable behavior of quickly 3761 backing off upon a time-out and of slowly decreasing the time-out 3762 value as packets are delivered without time-outs. 3764 Some definitions: 3766 Packet Processing Delay, "PPD", is the amount of time required for 3767 each peer to process the maximum amount of data buffered in their 3768 offered receive packet window. The PPD is the value exchanged 3769 between the LAC and LNS when a call is established. For the LNS, 3770 this number should be small. For an LAC supporting modem connec- 3771 tions, this number could be significant. 3773 "Sample" is the actual amount of time incurred receiving an 3774 acknowledgment for a packet. The Sample is measured, not calcu- 3775 lated. 3777 Round-Trip Time, "RTT", is the estimated round-trip time for an 3778 Acknowledgment to be received for a given transmitted packet. 3779 When the network link is a local network, this delay will be mini- 3780 mal (if not zero). When the network link is the Internet, this 3781 delay could be substantial and vary widely. RTT is adaptive: it 3782 will adjust to include the PPD and whatever shifting network 3783 delays contribute to the time between a packet being transmitted 3784 and receiving its acknowledgment. 3786 Adaptive Time-Out, "ATO", is the time that must elapse before an 3787 acknowledgment is considered lost. After a time-out, the sliding 3788 window is partially closed and the ATO is backed off. 3790 Packet Processing Delay (PPD) 3792 The PPD parameter is a 16-bit time value exchanged during the Call 3793 Control phase expressed in units of tenths of a second (64 means 6.4 3794 seconds). The protocol only specifies that the parameter is 3795 exchanged, it does not specify how it is calculated. The way values 3796 for ATO are calculated is implementation-dependent and need not be 3797 variable (static time-outs are allowed). IF adaptive time-outs are 3798 to be used then the PPD should be exchanged in the call connect 3799 sequences. A possible way to calculate the PPD is: 3801 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 3802 + LACFudge (for an LAC) 3803 or 3804 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 3805 + LNSFudge (for an LNS) 3807 Header is the total size of the L2TP and media dependent headers. 3808 MTU is the overall MTU for the link between the LAC and LNS. Window- 3809 Size represents the number of packets in the sliding window, and is 3810 implementation-dependent. The latency of the underlying connection 3811 path between the LAC and LNS could be used to pick a window size suf- 3812 ficient to keep the current session's pipe full. The constant 8 con- 3813 verts octets to bits (assuming ConnectRate is in bits per second). 3814 If ConnectRate is in bytes per second, omit the 8. LACFudge and LNS- 3815 Fudge are not required but can be used to take overall processing 3816 overhead of the LAC or LNS into account. 3818 In the case of the computed PPD for an LNS, AvePathRate is the aver- 3819 age bit rate of the path between the LNS and LAC. Given that this 3820 number is probably very large and WindowSize is relatively small, 3821 LNSFudge will be the dominant factor in the computation of PPD. It 3822 is recommended that the minimum value of PPD be on the order of 0.5 3823 second. 3825 The value of PPD is used to seed the adaptive algorithm with the ini- 3826 tial RTT[n-1] value. 3828 A.1 Calculating Adaptive Acknowledgment Time-Out 3830 We still must decide how much time to allow for acknowledgments to 3831 return. If the time-out is set too high, we may wait an unnecessar- 3832 ily long time for dropped packets. If the time-out is too short, we 3833 may time out just before the acknowledgment arrives. The acknowledg- 3834 ment time-out should also be reasonable and responsive to changing 3835 network conditions. 3837 The suggested adaptive algorithm detailed below is based on the TCP 3838 1989 implementation and is explained in Richard Steven's book TCP/IP 3839 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 3840 calculation, and 'n-1' refers to values from the last calculation. 3842 DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta * 3843 (|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 3844 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 3846 DIFF represents the error between the last estimated round-trip 3847 time and the measured time. DIFF is calculated on each iteration. 3849 DEV is the estimated mean deviation. This approximates the stan- 3850 dard deviation. DEV is calculated on each iteration and stored 3851 for use in the next iteration. Initially, it is set to 0. 3853 RTT is the estimated round-trip time of an average packet. RTT is 3854 calculated on each iteration and stored for use in the next itera- 3855 tion. Initially, it is set to PPD. 3857 ATO is the adaptive time-out for the next transmitted packet. ATO 3858 is calculated on each iteration. Its value is limited, by the MIN 3859 function, to be a maximum of the configured MaxTimeOut value. 3861 Alpha is the gain for the average and is typically 1/8 (0.125). 3863 Beta is the gain for the deviation and is typically 1/4 (0.250). 3865 Chi is the gain for the time-out and is typically set to 4. 3867 To eliminate division operations for fractional gain elements, the 3868 entire set of equations can be scaled. With the suggested gain con- 3869 stants, they should be scaled by 8 to eliminate all division. To 3870 simplify calculations, all gain values are kept to powers of two so 3871 that shift operations can be used in place of multiplication or divi- 3872 sion. The above calculations are carried out each time an acknowl- 3873 edgment is received for a packet that was not retransmitted (no time- 3874 out occurs). 3876 A.2 Congestion Control: Adjusting for Time-Out 3878 This section describes how the calculation of ATO is modified in the 3879 case where a time-out does occur. When a time-out occurs, the time- 3880 out value should be adjusted rapidly upward. Although L2TP payload 3881 packets are not retransmitted when a time-out occurs, the time-out 3882 should be adjusted up toward a maximum limit. To compensate for 3883 shifting internetwork time delays, a strategy must be employed to 3884 increase the time-out when it expires. A simple formula called 3885 Karn's Algorithm is used in TCP implementations and may be used in 3886 implementing the backoff timers for the LNS or the LAC. Notice that 3887 in addition to increasing the time-out, we also shrink the size of 3888 the window as described in the next section. 3890 Karn's timer backoff algorithm, as used in TCP, is: 3892 NewTIMEOUT = delta * TIMEOUT 3894 Adapted to our time-out calculations, for an interval in which a 3895 time-out occurs, the new time-out interval ATO is calculated as: 3897 RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MIN (RTT[n] + 3898 (chi * DEV[n]), MaxTimeOut) 3900 In this modified calculation of ATO, only the two values that con- 3901 tribute to ATO and that are stored for the next iteration are calcu- 3902 lated. RTT is scaled by delta, and DEV is unmodified. DIFF is not 3903 carried forward and is not used in this scenario. A value of 2 for 3904 Delta, the time-out gain factor for RTT, is suggested. 3906 Appendix B: Acknowledgment Time-Out and Window Adjustment 3908 B.1 Initial Window Size 3910 Although each side has indicated the maximum size of its receive win- 3911 dow, it is recommended that a slow start method be used to begin 3912 transmitting data. The initial window size on the transmitter is set 3913 to half the maximum size the receiver requested, with a minimum size 3914 of one packet. The transmitter stops sending packets when the number 3915 of packets awaiting acknowledgment is equal to the current window 3916 size. As the receiver successfully digests each window, the window 3917 size on the transmitter is bumped up by one packet until the maximum 3918 is reached. This method prevents a system from flooding an already 3919 congested network because no history has been established. 3921 When for any reason an LAC or LNS receives more data than it can 3922 queue for the tunnel, a packet must be discarded. In this case, it 3923 is recommended that a "random early discard" algorithm [6] be used 3924 rather than the obvious "drop last" algorithm. 3926 B.2 Closing the Window 3928 When a time-out does occur on a packet, the sender adjusts the size 3929 of the transmit window down to one half its value when it failed. 3931 Fractions are rounded up, and the minimum window size is one. 3933 B.3 Opening the Window 3935 With every successful transmission of a window's worth of packets 3936 without a time-out, the transmit window size is increased by one 3937 packet until it reaches the maximum window size that was sent by the 3938 other side when the call was connected. As stated earlier, no 3939 retransmission is done on a time-out. After a time-out, the trans- 3940 mission resumes with the window starting at one half the size of the 3941 transmit window when the time-out occurred and adjusting upward by 3942 one each time the transmit window is filled with packets that are all 3943 acknowledged without time-outs. 3945 B.4 Window Overflow 3947 When a receiver's window overflows with too many incoming packets, 3948 excess packets are thrown away. This situation should not arise if 3949 the sliding window procedures are being properly followed by the 3950 transmitter and receiver. It is assumed that, on the transmit side, 3951 packets are buffered for transmission and are no longer accepted from 3952 the packet source when the transmit buffer fills. 3954 Appendix C: Handling of out-of-order packets 3956 When the Sequence Number and Acknowledgment Number fields are present 3957 in payload packets, they are used to manage packet rate. In addi- 3958 tion, they may be used to handle out-of-order arrival of packets. A 3959 simple L2TP client would simply discard any packet other than a 3960 packet with a sequence greater than that last received; if packets 1, 3961 2, 3 arrived as 1, 3, 2, this would result in packet 2 being dis- 3962 carded. 3964 Such behavior does not affect the L2TP protocol itself, but signifi- 3965 cantly improved throughput in such environments may be attained by 3966 queueing and reordering packets when they arrive out of order. The 3967 number of packets to be queued is a function of memory resources on 3968 the L2TP implementation, but should never be more than 1/4 of the 3969 total sequence number space (i.e., 16384 packets), to avoid aliasing. 3971 An implementation which queues packets in this way must also employ 3972 an algorithm for deciding that a given sequence number corresponds to 3973 a packet which is lost, rather than one which is out of order but 3974 still in transit. Such a decision would likely be based upon timing, 3975 buffering conditions, and packet arrival characteristics. The 3976 details of such a tradeoff are outside the scope of this specifica- 3977 tion, but it is recommended a packet should be afforded an interval 3978 at least twice the estimated RTT from the L2TP peer. 3980 Appendix D: Transport Layer Adaptive Time-outs and Window Adjustment 3982 Appendixes A, B, and C dealt with operation of the payload packet 3983 sessions of L2TP. This Appendix explains how these three algorithms 3984 pertain to the transport layer for L2TP control sessions. Appendix 3985 B, Time-out Window Management, directly applies to the Transport 3986 Layer except in the case where a window size of 1 is being used. 3987 Appendix C, does not really apply because, for the Control Session, 3988 control messages MUST always be processed by the receiver in order. 3989 Also, there are no lost control packets because they are retransmit- 3990 ted by the L2TP Transport Layer. Thus, the main topic of this 3991 Appendix is how to adapt the example adaptive time-out algorithm of 3992 Appendix A to the Control Session Transport Layer. 3994 There are two main differences between the Control Session and pay- 3995 load sessions: 1) Unlike lost payload packets, lost control messages 3996 are retransmitted and 2) There is no Packet Processing Delay value 3997 provided in the control session setup messages. The latter affects 3998 the manner in which the initial value of the RTT estimate is deter- 3999 mined. The former really doesn't affect the algorithm at all, except 4000 that upon a time-out, retransmission of unacknowledged control mes- 4001 sages should be attempted, up to the number that fit in the sliding 4002 window with size computed as in Appendix B. 4004 Using the symbol definitions of Appendix A, the calculation of the 4005 value for the PPD of the remote peer can be estimated as: 4007 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4008 + Fudge 4010 This is simply the number of bits in a full control session window 4011 divided by the average speed of the path between the LAC and LNS with 4012 a fudge factor added on to make it work. In cases where the average 4013 rate of the connection between LAC and LNS isn't known, it is sug- 4014 gested that some value be configured that is associated with each 4015 possible peer. Because Control Session windows will most likely be 4016 small and the connection speed will be quite high, fudge will be the 4017 dominant factor in this calculation. For this reason, just configur- 4018 ing a single fixed initial PPD estimate to be used for all possible 4019 peers will probably provide adequate results. This fudge factor 4020 should probably be at least 0.5 second.