idnits 2.17.1 draft-ietf-pppext-l2tp-07.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-27) 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 87 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 87 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 26 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 159: '... o MUST, SHALL, or MANDATORY --...' RFC 2119 keyword, line 162: '... o SHOULD or RECOMMEND -- This ...' RFC 2119 keyword, line 165: '... o MAY or OPTIONAL -- This item...' RFC 2119 keyword, line 708: '...e of 0 is thus special and MUST NOT be...' RFC 2119 keyword, line 772: '... The sending peer MAY send all payload...' (115 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1045 has weird spacing: '...MUST be prese...' == Line 1678 has weird spacing: '...d their tunne...' == Line 2884 has weird spacing: '...message encod...' == Line 3664 has weird spacing: '...e local wai...' == Line 3665 has weird spacing: '...ndicate tunne...' == (1 more instance...) == 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 360 -- Looks like a reference, but probably isn't: 'R' on line 362 -- Looks like a reference, but probably isn't: 'U' on line 363 -- Looks like a reference, but probably isn't: 'L' on line 361 -- Looks like a reference, but probably isn't: 'N' on line 364 -- 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 (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group K. Hamzeh, A. Rubens 3 INTERNET DRAFT Ascend Communications 4 Category: Internet Draft T. Kolar, M. Littlewood, 5 Title: draft-ietf-pppext-l2tp-07.txt B. Palter, A. Valencia 6 Date: October 1997 Cisco Systems 7 J. Taarud 8 Copper Mountain Networks 9 W. M. Townsley 10 IBM Corporation 11 G. S. Pall 12 Microsoft Corporation 13 W. Verthein 14 3COM Corporation 16 Layer Two Tunneling Protocol "L2TP" 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months. Internet-Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet- 28 Drafts as reference material or to cite them other than as a 29 ``working draft'' or ``work in progress.'' 31 To learn the current status of any Internet-Draft, please check the 32 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 33 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 34 munnari.oz.au. 36 Abstract 38 Virtual dial-up allows many separate and autonomous protocol domains 39 to share common access infrastructure including modems, Access 40 Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up 41 via PPP [1]. This document describes the Layer Two Tunneling 42 Protocol (L2TP) which permits the tunneling of the link layer (i.e., 43 HDLC, async HDLC) of PPP. Using such tunnels, it is possible to 44 divorce the location of the initial dial-up server from the location 45 at which the dial-up protocol connection is terminated and access to 46 the network provided. 48 Table of Contents 50 1.0 Introduction 51 1.1 Conventions 52 1.2 Terminology 53 2.0 Problem Space Overview 54 2.1 Initial Assumptions 55 2.2 Topology 56 2.3 Providing Virtual Dial-up Services--a walk-through 57 3.0 Service Model Issues 58 3.1 Security 59 3.2 Address Allocation 60 3.3 Authentication 61 3.4 Accounting 62 4.0 Protocol Overview 63 4.1 Control Message Overview 64 4.2 Payload Packet Overview 65 5.0 Message Format and Protocol Extensibility 66 5.1 AVP 67 5.2 Control Message Format 68 5.3 Payload Message Format 69 5.4 Control Message Types 70 5.5 AVP Summary 71 5.6 Result and Error Code Summary 72 5.7 Hiding of AVP values 73 6.0 Control Connection Protocol Specification 74 6.1 Start-Control-Connection-Request 75 6.2 Start-Control-Connection-Reply 76 6.3 Start-Control-Connection-Connected 77 6.4 Stop-Control-Connection-Notification 78 6.5 (reserved) 79 6.6 Hello 80 6.7 Outgoing-Call-Request 81 6.8 Outgoing-Call-Reply 82 6.9 Outgoing-Call-Connected 83 6.10 Incoming-Call-Request 84 6.11 Incoming-Call-Reply 85 6.12 Incoming-Call-Connected 86 6.13 (reserved) 87 6.14 Call-Disconnect-Notify 88 6.15 WAN-Error-Notify 89 6.16 Set-Link-Info 90 7.0 Control Connection State Machines 91 7.1 Control Connection Protocol Operation 92 7.2 Control Connection States 93 7.2.1 Control Connection Establishment 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 7.6 Tunnel Disconnection 102 8.0 L2TP Over Specific Media 103 8.1 IP/UDP 104 8.2 IP 105 9.0 Security Considerations 106 9.1 Tunnel Endpoint Security 107 9.2 Client Security 108 10.0 Acknowledgments 109 11.0 Contacts 110 12.0 References 111 Appendix A: Acknowledgment Time-Outs 112 Appendix B: Acknowledgment Time-Out and Window Adjustment 113 Appendix C: Handling of out-of-order packets 114 Appendix D: Transport Layer Adaptive Time-Outs and Window Adjustment 115 Appendix E: Examples of L2TP sequence numbering 116 E.1 Lock-step tunnel establishment 117 E.2 Multiple packets acknowledged 118 E.3 Lost packet with retransmission 119 E.4 Lost payload packet with ZLB congestion control 120 E.5 Lost payload packet with piggyback congestion control 122 1.0 Introduction 124 The traditional dial-up network service on the Internet is for 125 registered IP addresses only. A new class of virtual dial-up 126 application which allows multiple protocols and unregistered IP 127 addresses is also desired on the Internet. Examples of this class of 128 network application are support for privately addressed IP, IPX, and 129 AppleTalk dial-up via PPP across existing Internet infrastructure. 131 The support of these multiprotocol virtual dial-up applications is of 132 significant benefit to end users, enterprises, and Internet Service 133 providers as it allows the sharing of very large investments in 134 access and core infrastructure and allows local calls to be used. It 135 also allows existing investments in non-IP protocol applications to 136 be supported in a secure manner while still leveraging the access 137 infrastructure of the Internet. 139 It is the purpose of this draft to identify the issues encountered in 140 integrating multiprotocol dial-up services into an existing Internet 141 Service Provider's Point of Presence (hereafter referred to as ISP 142 and POP, respectively), and to describe the L2TP protocol which 143 permits the leveraging of existing access protocols. 145 This protocol may also be used to solve the "multilink hunt-group 146 splitting" problem. Multilink PPP [9], often used to aggregate ISDN B 147 channels, requires that all channels composing a multilink bundle be 148 grouped at a single NAS. Because L2TP makes a PPP session terminate 149 at a location other than the point at which the session was 150 physically received, it can be used to make all channels terminate at 151 a single NAS, allowing multilink operation even when the physical 152 calls are spread across distinct physical NAS's. 154 1.1 Conventions 156 The following language conventions are used in the items of 157 specification in this document: 159 o MUST, SHALL, or MANDATORY -- This item is an absolute 160 requirement of the specification. 162 o SHOULD or RECOMMEND -- This item should generally be followed 163 for all but exceptional circumstances. 165 o MAY or OPTIONAL -- This item is truly optional and may be 166 followed or ignored according to the needs of the implementor. 168 1.2 Terminology 170 Analog Channel 172 A circuit-switched communication path which is intended to carry 173 3.1 Khz audio in each direction. 175 Control Connection 177 A control connection operates in-band over a tunnel to control the 178 establishment, release, and maintenance of sessions and of the 179 tunnel itself. 181 Digital Channel 183 A circuit-switched communication path which is intended to carry 184 digital information in each direction. 186 Call 188 A connection or attempted connection between two terminal 189 endpoints on a PSTN or ISDN--for example, a telephone call between 190 two modems. (See also: Session). 192 CHAP 194 Challenge Authentication Protocol, a PPP cryptographic 195 challenge/response authentication protocol in which the cleartext 196 password is not passed over the line. 198 CLID 200 Calling Line ID, an indication to the receiver of a call as to the 201 phone number of the caller. 203 Control Messages 204 Control messages are exchanged between LAC and LNS pairs, 205 operating in-band within the tunnel protocol. Control messages 206 govern aspects of the tunnel and sessions within the tunnel. 208 Dial User 210 An end-system or router attached to an on-demand PSTN or ISDN 211 which is either the initiator or recipient of a call. Also 212 referred to as a dial-up or Virtual dial-up client. 214 DNIS 215 Dialed Number Information String, an indication to the receiver of 216 a call as to what phone number the caller used to reach it. 218 EAP 220 Extensible Authentication Protocol, a framework for a family of 221 PPP authentication protocols, including cleartext, 222 challenge/response, and arbitrary dialog sequences. 224 L2TP Access Concentrator (LAC) 226 A device attached to one or more PSTN or ISDN lines capable of PPP 227 operation and of handling the L2TP protocol. The LAC needs only 228 implement the media over which L2TP is to operate to pass traffic 229 to one or more LNS's. It may tunnel any protocol carried within 230 PPP. 232 L2TP Network Server (LNS) 234 An LNS operates on any platform capable of PPP termination. The 235 LNS handles the server side of the L2TP protocol. Since L2TP 236 relies only on the single media over which L2TP tunnels arrive, 237 the LNS may have only a single LAN or WAN interface, yet still be 238 able to terminate calls arriving at any LAC's full range of PPP 239 interfaces (async, synchronous ISDN, V.120, etc.). 241 Network Access Server (NAS) 243 A device providing temporary, on-demand network access to users. 244 This access is point-to-point using PSTN or ISDN lines. A NAS may 245 also serve as an LAC, LNS or both. 247 PAP 249 Password Authentication Protocol, a simple PPP authentication 250 mechanism in which a cleartext username and password are 251 transmitted to prove identity. 253 POP 255 An Internet Service Provider's Point of Presence. 257 Quality of Service (QOS) 259 A given Quality of Service level is sometimes required for a given 260 user being tunneled between an LNS-LAC pair. For this scenario, a 261 unique L2TP tunnel is created (generally on top of a new SVC) and 262 encapsulated directly on top of the media providing the indicated 263 QOS. 265 Session 267 L2TP is connection-oriented. The LNS and LAC maintain state for 268 each user that is attached to an LAC. A session is created when 269 an end-to-end PPP connection is attempted between a dial user and 270 the LNS, or when a outbound call is initiated. The datagrams 271 related to a session are sent over the tunnel between the LAC and 272 LNS. (See also: Call). 274 Switched Virtual Circuit (SVC) 276 An L2TP-compatible media on top of which L2TP is directly 277 encapsulated. SVC's are dynamically created, permitting tunnel 278 media to be created dynamically in response to desired LNS-LAC 279 connectivity requirements. 281 Tunnel 283 A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP 284 datagrams between the LAC and the LNS; many sessions can be 285 multiplexed over a single tunnel. A control connection operating 286 in-band over the same tunnel controls the establishment, release, 287 and maintenance of sessions and of the tunnel itself. A tunnel is 288 sometimes referred to as a control connection. 290 Zero-Length Body (ZLB) Message 292 A control or payload packet with only an L2TP header, and no 293 control message information or PPP payload. ZLB messages are used 294 for explicitly acking packets on the control or data channel. 296 2.0 Problem Space Overview 298 In this section we describe in high level terms the scope of the 299 problem that will be explored in more detail in later sections. 301 2.1 Initial Assumptions 303 We begin by assuming that Internet access is provided by an ISP and 304 that the ISP wishes to offer services other than traditional 305 registered IP address based services to dial-up users of the network. 307 We also assume that the user of such a service wants all of the 308 security facilities that are available to him or her in a dedicated 309 dial-up configuration. In particular, the end user requires: 311 + End System transparency: Neither the remote end system nor his 312 home site hosts should require any special software to use this 313 service in a secure manner. 315 + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or 316 through other dialogs, for instance, a textual exchange on V.120 317 before starting PPP. This will include TACACS+ [7] and RADIUS [8] 318 solutions as well as support for smart cards and one-time passwords. 319 The authentication should be manageable by the user independently of 320 the ISP. 322 + Addressing should be as manageable as dedicated dial-up solutions. 324 The address should be assigned by the home site and not the ISP. 326 + Authorization should be managed by the home site as it would in a 327 direct dial-up solution. 329 + Accounting should be performed both by the ISP (for billing 330 purposes) and by the user (for charge-back and auditing). 332 2.2 Topology 334 Shown below is a generic Internet with Public switched Telephone 335 Network (PSTN) access (i.e., async PPP via modems) and Integrated 336 Services Digital Network (ISDN) access (i.e., synchronous PPP 337 access). Remote users (either async or ISDN PPP) will access the 338 Home LAN as if they were dialed into the L2TP Network Server (LNS), 339 although their physical dial-up is via the ISP Network Access Server 340 (acting as the LAC). 342 ...----[L]----+---[L]-----... 343 | 344 | 345 [H] 346 | 347 ________|________________________ 348 | | 349 ________|__ ______|________ 350 | | | | 351 | PSTN [R] [R] ISDN | 352 | Cloud | | Cloud [N]__[U] 353 | | Internet | | 354 | | [R] | 355 [N]______[R] |_____________| 356 | | | 357 | | | 358 [U] |________________________________| 360 [H] = LNS 361 [L] = Home LAN(s) 362 [R] = Router 363 [U] = Remote User 364 [N] = ISP Network Access Server (LAC) 366 2.3 Providing Virtual dial-up Services--a walk-through 368 To motivate the following discussion, this section walks through an 369 example of what might happen when a Virtual dial-up client initiates 370 access. 372 A Network Access Server (NAS) operating as a peer to an LNS is 373 referred to as an L2TP Access Concentrator, or "LAC". 375 The remote user initiates a PPP connection to an ISP via either the 376 PSTN or ISDN. The LAC accepts the connection and the PPP link is 377 established (L2TP also permits the LAC to check with an LNS after 378 call indication prior to accepting the call--this is useful where 379 DNIS or CLID information is available in the incoming call 380 notification). 382 The ISP may now undertake a partial authentication of the end 383 system/user. Only the username field would be interpreted to 384 determine whether the user requires a Virtual dial-up service. It is 385 expected--but not required--that usernames will be structured (e.g. 386 username@company.com). Alternatively, the ISP may maintain a 387 database mapping users to services. In the case of Virtual dial-up, 388 the mapping will name a specific endpoint, the LNS. 390 Alternatively, the ISP may have already determined the target LNS 391 from DNIS. If the LNS is willing to accept tunnel creation without 392 any authentication of the caller, the LAC may tunnel the PPP 393 connection without ever having communicated with the remote user. 395 If a virtual dial-up service is not required, standard access to the 396 Internet may be provided. 398 If no tunnel connection currently exists to the desired LNS, one is 399 initiated. L2TP is designed to be largely insulated from the details 400 of the media over which the tunnel is established; L2TP requires only 401 that the tunnel media provide packet oriented point-to-point 402 connectivity. Obvious examples of such media are UDP, Frame Relay 403 PVC's, or X.25 VC's. 405 Once the tunnel exists, an unused slot within the tunnel, a "Call 406 ID", is allocated, and a connect indication is sent to notify the LNS 407 of this new dial-up session. The LNS either accepts the connection, 408 or rejects it. Rejection may include a result or error indication, 409 which may be displayed to the dial-up user, after which the call 410 should be disconnected. 412 The initial connect notification may include the authentication 413 information required to allow the LNS to authenticate the user and 414 decide to accept or decline the connection. In the case of CHAP, the 415 set-up packet includes the challenge, username and raw response. For 416 PAP or text dialog, it includes username and clear text password. 417 The LNS may choose to use this information to complete its 418 authentication, avoiding an additional cycle of authentication. 420 If the LAC negotiated PPP LCP before initiating the tunnel, the 421 initial connect notification may also include a copy of the LCP 422 CONFREQ's sent in each direction which completed LCP negotiation. 423 The LNS may use this information to initialize its own PPP state 424 (thus avoiding an additional LCP negotiation), or it may choose to 425 initiate a new LCP CONFREQ exchange. 427 If the LNS accepts the connection, it creates a "virtual interface" 428 for PPP in a manner analogous to what it would use for a direct- 429 dialed connection. With this "virtual interface" in place, link 430 layer frames may now pass over this tunnel in both directions. 431 Frames from the remote user are received at the POP, stripped of CRC, 432 link framing, and transparency bytes, encapsulated in L2TP, and 433 forwarded over the appropriate tunnel. 435 The LNS accepts these frames, strips L2TP, and processes them as 436 normal incoming frames for the appropriate interface and protocol. 437 The "virtual interface" behaves very much like a hardware interface, 438 with the exception that the hardware in this case is physically 439 located at the ISP POP. The other direction behaves analogously, 440 with the LNS encapsulating the packet in L2TP, and the LAC stripping 441 L2TP before transmitting it out the physical interface to the remote 442 user. 444 At this point, the connectivity is a point-to-point PPP session whose 445 endpoints are the remote user's networking application on one end and 446 the termination of this connectivity into the LNS's PPP support on 447 the other. Because the remote user has become simply another dial-up 448 client of the LNS, client connectivity can now be managed using 449 traditional mechanisms with respect to further authorization, 450 protocol access, and packet filtering. 452 Accounting can be performed at both the LAC as well as the LNS. This 453 document illustrates some Accounting techniques which are possible 454 using L2TP, but the policies surrounding such Accounting are outside 455 the scope of this specification. 457 L2TP offers optional facilities which maximize compatibility with 458 legacy client requirements; L2TP connect notifications for PPP 459 clients can contain sufficient information for an LNS to authenticate 460 and initialize its LCP state machine. With these facilities, the 461 remote user need not be queried a second time for PPP authentication, 462 nor undergo multiple rounds of LCP negotiation and convergence. 463 These techniques are intended to optimize connection setup, and are 464 not intended to deprecate any functions required by the PPP 465 specification. 467 3.0 Service Model Issues 469 There are several significant differences between the standard 470 Internet access service and the Virtual dial-up service with respect 471 to authentication, address allocation, authorization and accounting. 472 The details of the differences between these services and the 473 problems presented by these differences are described below. The 474 mechanisms used for Virtual Dial-up service are intended to coexist 475 with more traditional mechanisms; it is intended that an ISP's POP 476 can simultaneously service ISP clients as well as Virtual dial-up 477 clients. 479 3.1 Security 481 For the Virtual dial-up service, the ISP pursues authentication only 482 to the extent required to discover the user's apparent identity (and 483 by implication, their desired LNS). This may involve no more than 484 detecting DNIS information when a call arrives, or may involve full 485 LCP negotiation and initiation of PPP authentication. As soon as the 486 apparent identity is determined, a connection to the LNS is initiated 487 with any authentication information gathered by the ISP. The LNS 488 completes the authentication by either accepting the connection, or 489 rejecting it. 491 The LNS may need to protect against attempts by third parties to 492 establish tunnels to the LNS. Tunnel establishment can include 493 authentication to protect against such attacks. 495 3.2 Address Allocation 497 For an Internet service, the user accepts that the IP address may be 498 allocated dynamically from a pool of ISP addresses. This model often 499 means that the remote user has little or no access to their home 500 network's resources, due to firewalls and other security policies 501 applied by the home network to accesses from external IP addresses. 503 For the Virtual dial-up service, the LNS can exist behind the home 504 firewall, allocating addresses which are internal (and, in fact, can 505 be RFC1918 addresses, or non-IP addresses). Because L2TP tunnels 506 exclusively at the frame layer, the actual policies of such address 507 management are irrelevant to correct Virtual dial-up service; for all 508 purposes of PPP protocol handling, the dial-in user appears to have 509 connected at the LNS. 511 3.3 Authentication 513 The authentication of the user occurs in three phases; the first at 514 the ISP, and the second and optional third at the LNS. 516 The ISP uses DNIS, CLID, or username to determine that a Virtual 517 dial-up service is required and initiates the tunnel connection to 518 the appropriate LNS. Once a tunnel is established, The ISP NAS 519 allocates a new Call ID and initiates a session by forwarding the 520 gathered authentication information. 522 The LNS undertakes the second phase by deciding whether or not to 523 accept the connection. The connection indication may include CHAP, 524 PAP, EAP, or textual authentication information. Based on this 525 information, the LNS may accept the connection, or may reject it (for 526 instance, it was a PAP request and the username/password are found to 527 be incorrect). 529 Once the connection is accepted, the LNS is free to pursue a third 530 phase of authentication at the PPP layer. These activities are 531 outside the scope of this specification, but might include an 532 additional cycle of LCP authentication, proprietary PPP extensions, 533 or textual challenges carried via a TCP/IP telnet session. 535 3.4 Accounting 537 It is a requirement that both the LAC and the LNS be capable of 538 providing accounting data and hence both may count packets, octets 539 and connection start and stop times. 541 Since Virtual dial-up is an access service, accounting of connection 542 attempts (in particular, failed connection attempts) is of 543 significant interest. The LNS can reject new connections based on 544 the authentication information gathered by the LAC, with 545 corresponding logging. For cases where the LNS accepts the 546 connection and then continues with further authentication, the LNS 547 might subsequently disconnect the client. For such scenarios, the 548 disconnection indication back to the LAC may also include a reason. 550 Because the LNS can decline a connection based on the authentication 551 information collected by the LAC, accounting can easily draw a 552 distinction between a series of failed connection attempts and a 553 series of brief successful connections. Lacking this facility, the 554 LNS must always accept connection requests, and would need to 555 exchange a number of PPP packets with the remote system. Note that 556 the LNS could use this information to decide to accept the connection 557 (which protects against most invalid connection attempts) while still 558 insisting on running its own CHAP authentication (for instance, to 559 protect against CHAP replay attacks). 561 4.0 Protocol Overview 563 There are two parallel components of L2TP operating over a given 564 tunnel: control messages between each LAC-LNS pair, and payload 565 packets between the same LAC-LNS pair. The latter are used to 566 transport L2TP encapsulated PPP packets for user sessions between the 567 pair. 569 Two fields important to the operation of L2TP are the Nr (Next 570 Received) and Ns (Next Sent) fields which are always present in 571 control messages, and are optionally present in payload packets. A 572 single sequence number state is maintained for all control messages, 573 and a distinct state is maintained for the payload of each user 574 session within the tunnel. In this document, the sequence number 575 state for a control connection and each user session is represented 576 for clarity in the following discussions by distinct pairs of state 577 variables, Sr and Ss. Sr represents the value of the next in- 578 sequence message expected to be received for a given session by a 579 peer. Ss represents the sequence number to be placed in the Ns field 580 of the next message sent for a given session by the sending peer. 581 Each state is initialized such that the first message sent and the 582 first message expected to be received for each session has an Ns 583 value of 0. This corresponds to initializing Ss and Sr in both peers 584 to 0 for each new session. 586 As messages are sent for a given session, Nr is set in these messages 587 to reflect one more than the Ns value of the highest (modulo 2**16) 588 in-order message received for that session; if sent before any packet 589 is received Nr will be 0, indicating that the peer expects the next 590 new Ns value received to be 0. When a non-zero-length message is 591 received with an Ns value that matches the session's current Sr 592 value, Sr is incremented by 1 (modulo 2**16). It is important to note 593 that, for both control and payload sessions, Sr is not modified if a 594 message is received with a value of Ns greater than the current Sr 595 value (exceptions to this rule being the permitted handling of out- 596 of-order payload packets by the "simple receiver" discussed in 597 Appendix C and handling of payload packets with the R-bit set). For 598 the control session, retransmission of outgoing messages should 599 eventually provide the receiving peer with the expected message. For 600 payload sessions, however, lost messages are never retransmitted so a 601 mechanism involving the use of the "Reset Sr" (R-bit) indicator in an 602 outgoing message is used to update the peer's value of Sr to the 603 value of Ns contained in the message. See Sec. 4.2 for details of 604 this mechanism. 606 Every time a peer sends a non-zero length message it increments its 607 corresponding Ss value for that session by 1 (modulo 2**16). This 608 increment takes place after the current Ss value is copied to Ns in 609 the message to be sent. Outgoing messages always include the current 610 value of Sr for the corresponding session in their Nr field. 612 A message (control or payload) with a zero-length body indicates that 613 the packet is only used to communicate Nr and Ns fields. The Nr and 614 Ns fields are filled in as above, but the sequence number state, Ss, 615 is not incremented. Thus a zero-length message sent after a non- 616 zero-length message will contain a new Ns value while a non-zero- 617 length message sent after a zero-length message will contain the same 618 value of Ns as the preceeding zero-length message. A peer receiving a 619 zero-length message does not increment its Sr variable. 621 Upon receipt of an in-order non-zero-length message, the receiving 622 peer must acknowledge the message by sending back the updated value 623 of Sr in the Nr field of the next outgoing message. This updated Sr 624 value can be piggybacked in the Nr field of any non-zero-length 625 outgoing messages that the peer may happen to send back. 627 If the peer does not have a non-zero-length message to transmit for a 628 period of 1/4 of the timeout interval after receiving a non-zero- 629 length message then it should send a zero-length message containing 630 the latest values of Sr and Ss, as described above. 632 If the peer does not have a message to transmit for a short period of 633 time after receiving a non-zero-length message then it should send a 634 zero-length message containing the latest values of Sr and Ss, as 635 described above. The suggested value for this time interval is 1/4 636 the receiving peer's value of Round-Trip-Time (RTT - see Appendix A), 637 if it computes RTT, or a maximum of 1/2 second otherwise. This 638 timeout should provide a reasonable opportunity for the receiving 639 peer to obtain a payload message destined for its peer, upon which 640 the ack of the received message can be piggybacked. 642 This timeout value should be treated as a suggested maximum; an 643 implementation could make this timeout quite small without adversely 644 affecting the protocol. To provide for better throughput, the 645 receiving peer should skip this timeout entirely and send a zero- 646 length message immediately in the case where its receive window fills 647 and it has no queued data to send for this connection or it can't 648 send queued data because the transmit window is closed. 650 A suggested implementation of this timer is as follows: Upon 651 receiving a non-zero-length message, the receiver starts a timer that 652 will expire in the recommended time interval. A variable, Lr (Last 653 Nr value sent), is used by the transmitter to store the last value 654 sent in the Nr field of a transmitted payload message for this 655 connection. Upon expiration of this timer, Sr is compared to Lr and, 656 if they are not equal, a zero-length ack is issued. If they are 657 equal, then no acks are outstanding and no action needs to be taken. 659 This timer should not be reinitialized if a new message is received 660 while it is active since such messages will be acked when the timer 661 expires. This ensures that periodic Acks are issued with a maximum 662 period equal to the recommended timeout interval. This interval 663 should be short enough to not cause false acknowledgment timeouts at 664 the transmitter when payload messages are being sent in one direction 665 only. Since such acks are being sent on what would otherwise be an 666 idle data path, their affect on performance should be small, if not 667 negligible. 669 See Appendix E for some examples of how sequence numbers progress. 671 4.1 Control Message Overview 673 Before PPP tunneling can occur between an LAC and LNS, control 674 messages must be exchanged between them. Control messages are 675 exchanged over the same tunnel which will be used to forward 676 payload data once L2TP call control and management information 677 have been passed. The control messages are responsible for 678 establishment, management, and release of sessions carried through 679 the tunnel, as well as status on the tunnel itself. It is the 680 means by which an LNS is notified of an incoming call at an 681 associated LAC, as well as the means by which an LAC is instructed 682 to place an outgoing call. 684 A tunnel may be established by either an LAC (for incoming calls) 685 or an LNS (for outgoing calls). Following the establishment of 686 the tunnel, the LNS and LAC configure the tunnel by exchanging 687 Start-Control-Connection-Request and -Reply messages. These 688 messages are also used to exchange information about basic 689 operating capabilities of the LAC and LNS. Once the control 690 message exchange is complete, the LAC may initiate sessions by 691 indicating inbound requests, or the LNS by requesting outbound 692 calls. If both ends of the tunnel have the ability to act as an 693 LAC and LNS concurrently, then nothing prohibits establishing 694 incoming or outgoing calls from both sides of the same tunnel. 695 Control messages may indicate changes in operating characteristics 696 of an individual user session with a Set-Link-Info message. 698 Individual sessions may be released by either the LAC or LNS, also 699 through control messages. 701 Independent Call ID values are established for each end of a user 702 session. The sender of a packet associated with a particular 703 session places the Call ID established by its peer in the Call ID 704 header field of all outgoing packets. For the cases where a Call 705 ID has not yet been assigned from the peer (i.e., during call 706 establishment of a new session), the Call ID field is sent as 0, 707 and further fields within the message are used to identify the 708 session. The Call ID value of 0 is thus special and MUST NOT be 709 used as an Assigned Call ID. 711 A mechanism for detection of tunnel connectivity problems is 712 provided by the reliable transport layer of L2TP. The transport 713 layer of L2TP performs control message retransmission. If the 714 number of retransmission attempts for a given control message 715 exceeds a configured maximum value, the tunnel is reset. This 716 retransmission mechanism exists in both the LNS and LAC ends of 717 the tunnel. 719 A keepalive mechanism is employed by the L2TP higher layer in 720 order to differentiate tunnel outages from extended periods of no 721 control or data activity on a tunnel. This is accomplished by the 722 higher layer injecting Hello control messages into the control 723 stream after a specified period of time elapses since the last 724 data or control was received on the tunnel. As for any other 725 control message, if the transport does not receive an ACK for the 726 Hello message after the normal number of retransmissions the 727 tunnel is declared down and is reset. The transport layer reset 728 mechanism along with the injection of Hello messages ensures that 729 a connectivity failure between the LNS and the LAC will be 730 detected at both ends of a tunnel in a timely manner. 732 It is intended that control messages will also carry management 733 related information in the future, such as a message allowing the 734 LNS to request the status of a given LAC; these message types are 735 not defined in this document. 737 4.2 Payload Packet Overview 739 Once a tunnel is established and control messages have completed 740 tunnel setup, the tunnel can be used to carry user session PPP 741 packets for sessions involving a given LNS-LAC pair. The "Call 742 ID" field in the L2TP header indicates to which session a 743 particular PPP packet belongs. In this manner, PPP packets are 744 multiplexed and demultiplexed over a single tunnel between a given 745 LNS-LAC pair. The "Call ID" field value is established during the 746 exchange of call setup control messages. 748 It is legal for multiple tunnels to exist between a given LNS-LAC 749 pair. This is useful where each tunnel is used for a single user 750 session, and the tunnel media (an SVC, for instance) has specific 751 QOS attributes dedicated to a given user. L2TP provides a tunnel 752 identifier so that individual tunnels can be identified, even when 753 arriving from a single source LAC or LNS. 755 The L2TP header also contains optional acknowledgment and 756 sequencing information that can be used to perform congestion and 757 flow control over the tunnel. Control messages are used to 758 determine rate and buffering parameters that are used to regulate 759 the flow of PPP packets for a particular session over the tunnel. 761 The receiving peer indicates whether flow-control is to be 762 performed for payload packets sent to it. If a peer issues a 763 Receive Window Size AVP with a non-zero value during session 764 establishment then the sending peer must abide by the indicated 765 window size value. If a receiving peer does not wish to flow 766 control the payload packets sent to it, it should not issue the 767 Receive Window Size AVP with a non-zero value. Issuing a Receive 768 Window Size AVP with a zero value has special significance. It 769 indicates that the receiver does not want to perform flow-control 770 but it does want the sending peer to provide Ns values in payload 771 packets so that it can detect (and perhaps reorder) packets 772 received out of order. The sending peer MAY send all payload 773 packets with the R-bit set (see below) to further indicate that 774 flow-control is not to be performed by the receiver. 776 In the case where neither peer issues a Receive Window Size AVP 777 during session establishment, the optional Nr and Ns fields are 778 absent in all payload packets for that session. In the case where 779 either peer wishes to perform flow-control or to detect out-of- 780 order receive messages (as indicated by the sending of the Receive 781 Window Size AVP with non-zero or zero value, respectively) the Nr 782 and Ns fields MUST be present in payload packets sent by both 783 peers. Both MUST provide proper Nr and Ns values in all messages 784 transmitted. A proper Ns value starts at 0 and increments by one 785 for each transmitted payload message and a proper Nr value is the 786 current value of the receive sequence number state variable, Sr. 788 If a receiving peer offers a non-zero receive window size to a 789 sending peer then the sending peer SHOULD abide by this window 790 size value. The sending peer should stop sending payload packets 791 when the window is full; i.e., x consecutive messages have been 792 sent but have not been acknowledged, where x is the value of the 793 Receive Window Size AVP. Implementors should take care to avoid 794 the situation where loss of an ACK by a sending peer with a full 795 transmit window causes a session to hang forever, due to the fact 796 there are no retransmissions of payload packets. Steps must be 797 taken to reopen the transmit window (at least to a value of 1) 798 upon expiration of an ACK wait timeout. See Appendix B for more 799 details. 801 When sending to a peer that has issued a non-zero receive window 802 size, the sending peer is responsible for resetting the receiver's 803 Sr value when a sent payload message is lost during transmission. 804 When a sent message is lost, the receiving peer's Sr value (and 805 hence the Nr value it sends) will "stick" at the Ns value of the 806 first missing payload message. The "Reset Sr" (R-bit) in the 807 payload message header (see Section 5.3) provides a mechanism for 808 the sending peer to indicate to the receiver that it (the sending 809 peer) recognizes that at least one payload message has been lost 810 and that the receiving peer should now reset its Sr value beyond 811 the lost message(s). If the sending peer is performing adaptive 812 window adjustment (see Appendix B.1) then it is this recognition 813 of a lost message that is used to indicate that a window 814 adjustment at the sending peer should be performed. 816 The sender may use a timer mechanism similar to that used to 817 retransmit lost control messages to determine when transmitted 818 messages have been lost. When the timer expires, a payload 819 message (zero or non-zero length) with the R-bit set can be issued 820 to indicate to the receiver that it needs to reset its Sr value. 821 Upon receipt of a payload message with the R-bit set, the receiver 822 resets its current Sr value using the value of Ns contained in the 823 message. 825 Upon receipt of a payload message with R-bit set, the receiver 826 takes the following actions: First, the receiver checks for the 827 presence of the R-bit in a received payload message before 828 comparing the message's Ns value to its Sr value. If the R-bit is 829 set, the receiver then sets its Sr value to the value of Ns 830 contained in the message and falls through to normal receive 831 message processing in which Sr will be incremented (modulo 2**16) 832 if the message is non-zero-length and will remain the same if it 833 is zero-length. Thus, the value of Nr sent after reception of a 834 packet with the R-bit set MUST be greater than (modulo 2**16) or 835 equal to the value of Ns in the R-bit packet just received. 837 In order to prevent an R-bit message received out of order from 838 setting Sr to an old value, the receiving peer should compare the 839 value of Ns in an R-bit message to its current value of Sr. The 840 receiving peer should reset its Sr value only if Ns is greater 841 than (modulo 2**16) its current value of Sr. 843 The sender of the R-bit can decide whether it wishes to advance 844 the receiver's Sr value to the value just past the highest (modulo 845 2**16) Nr value received (the Ns value of the first lost message) 846 or to its current value of Ss. Resetting it to that of the first 847 lost message enables the sender to determine if other messages in 848 the same transmit window were also lost. Setting it to the 849 current Ss value of the sender treats losses of multiple messages 850 in the same window the same as the loss of a single message. An 851 implementation may use either, or a combination of both methods. 853 Finally, it is also permissible for a sending peer to set the R- 854 bit in all transmitted payload packets. In this case, the 855 receiver will always update its value of Sr to the Ns value of 856 each packet received, effectively bypassing any congestion or 857 flow-control mechanisms normally imposed by the receiver. 859 L2TP does not specify the particular timeout algorithms to use for 860 congestion control. Suggested algorithms for the determination of 861 adaptive timeouts to recover from dropped data or acknowledgments 862 on the tunnel are included in Appendix A of this document. 863 Additional examples for sequencing and congestion control are 864 included in Appendix E. 866 5. Message Format and Protocol Extensibility 868 L2TP defines a set of control messages sent in packets over the 869 tunnel between an LNS and a given LAC. The exact technique for 870 initiating a tunnel between an LNS-LAC pair is specific to the tunnel 871 media, and specific media are described in section 8.0. 873 Once media-level connectivity is reached, L2TP message formats define 874 the protocol for an LAC and LNS to manage the tunnel and its 875 associated sessions. 877 In each case where a field is optional, if the field is not present, 878 its space does not exist in the packet. Existing fields are placed 879 back-to-back to form the packet. 881 5.1 AVP 883 To maximize extensibility while still permitting interoperability, 884 a uniform method for encoding message types and bodies is used 885 throughout L2TP. This encoding will be termed an AVP (Attribute- 886 Value Pair) in the remainder of this document. Each AVP is 887 encoded as: 889 0 1 2 3 890 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 |M|H|Z|Z|Z|Z| Overall Length | Vendor ID | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Attribute | Value... | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | [until Overall Length is reached]... | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 The first six bits are a bit mask, describing the general 900 attributes of the AVP. 902 The Z bits indicate reserved bit fields and MUST be set to 0. A 903 packet received with a reserved bit set to 1 MUST be silently 904 discarded, unless the bit is defined for an extension that is 905 known to the implementation. 907 The M bit, known as the "mandatory" bit, controls the behavior 908 required of an implementation which receives an AVP which it does 909 not recognize. If M is set on an unrecognized AVP associated with 910 call (session) management, any session associated with this AVP 911 MUST be terminated. If M is set on an unrecognized AVP associated 912 with the overall tunnel, the entire tunnel (and all sessions 913 within) MUST be terminated. If M is not set, an unrecognized AVP 914 should be ignored. 916 The H bit, known as the "hidden" bit, controls the hiding of the 917 data in the value field of an AVP. This capability can be used to 918 avoid the passing of sensitive data, such as user passwords, as 919 cleartext in an AVP. Section 5.7 describes the procedure for 920 performing AVP value hiding. 922 Overall Length encodes the number of octets (including the Overall 923 Length field itself) contained in this AVP. It is 10 bits, 924 permitting a maximum of 1024 octets of data in a single AVP. 926 Vendor ID is the IANA assigned "SMI Network Management Private 927 Enterprise Codes" value, encoded in network byte order. The value 928 0, reserved in this table, corresponds to IETF adopted Attribute 929 values, defined within this document. Any vendor wishing to 930 implement L2TP extensions can use their own Vendor ID along with 931 private Attribute values, guaranteeing that they will not collide 932 with any other vendor's extensions, nor with future IETF 933 extensions. 935 Attribute is the actual attribute, a 16-bit value with a unique 936 interpretation across all AVP's defined under a given Vendor ID. 938 Value follows immediately after the Attribute field, and runs for 939 the remaining octets indicated in the Overall Length (i.e., 940 Overall Length minus six octets of header). 942 AVP's should be kept compact; the combined AVP's within a control 943 message MUST NOT ever cause a control message's total length to 944 exceed 1500 bytes in length. 946 5.2 Control Message Format 948 Each L2TP control message begins with a 16 octet header portion 949 followed by zero or more AVP's. This header is formatted: 951 0 1 2 3 952 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 |T|L|Z|Z|F|Z|Z|Z|Z|Z|Z|Z|Z| Ver | Length | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Tunnel ID | Call ID | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Ns | Nr | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Message Type AVP... 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 ... (8 octets) | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 The Z bits indicate reserved bit fields and MUST be set to 0. A 966 packet received with a reserved bit set to 1 MUST be silently 967 discarded, unless the bit is defined for an extension that is 968 known to the implementation. 970 The L and F bits must be 1, indicating that the length, Ns and Nr 971 fields are present. 973 The T bit MUST be 1, indicating a control message. 975 Ver MUST be the value 2, indicating a version 1 L2TP message 976 (values 0 and 1 are reserved to permit detection of L2F [2] and 977 PPTP [3] packets if they arrive intermixed). 979 Length is the overall length of the message, including header, 980 message type AVP, plus any additional AVP's associated with a 981 given control message type. 983 Tunnel ID and Call ID identify the tunnel and user session within 984 the tunnel to which a control message applies. If a control 985 message does not apply to a single user session within the tunnel 986 (for instance, a Stop-Control-Connection-Notification message), 987 Call ID MUST be set to 0. If an Assigned Tunnel ID has not yet 988 been received from the peer, Tunnel ID MUST be set to 0. Once an 989 Assigned Tunnel ID is received, all further packets MUST be sent 990 with Tunnel ID set to the indicated value. 992 Ns is copied from the send sequence number state variable, Ss, at 993 the time the message is transmitted. Ss is incremented after 994 copying if the length of the control message is non-zero. Nr is 995 copied from the receive sequence number state variable, Sr, and 996 indicates the sequence number + 1 of the highest (modulo 2**16) 997 in-sequence message received. See section 4.0. 999 5.3 Payload Message Format 1001 PPP payload packets tunneled within L2TP have a smaller 1002 encapsulation than the L2TP control message header, reducing 1003 overhead of L2TP during the life of a tunneled PPP session. The 1004 LNS is expected to be able to process user data packets of at 1005 least the default MRU for PPP, not including L2TP and media 1006 encapsulation. The smallest L2TP encapsulation is 6 octets; the 1007 largest is 14 octets (plus padding bytes, if present). See 1008 section 8.1 for further MTU considerations. 1010 0 1 2 3 1011 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 |T|L|R|Z|F|Z|O|P|Z|Z|Z|Z|Z| Ver | Length (opt) | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Tunnel ID | Call ID | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Ns (opt) | Nr (opt) | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Offset Size (opt) | Offset pad... (opt) | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 The Z bits indicate reserved bit fields and MUST be set to 0. A 1023 packet received with a reserved bit set to 1 MUST be silently 1024 discarded, unless the bit is defined for an extension that is 1025 known to the implementation. 1027 The T bit MUST be 0, indicating payload. 1029 Ver MUST be 2, indicating version 1 of the L2TP protocol. 1031 If the L bit is set, the Length field is present, indicating the 1032 total length of the received packet. 1034 The R bit, "Reset Sr", indicates that the receiver MUST reset its 1035 receive state variable, Sr, for this session to the value 1036 contained in the Ns field of this message header. Sr is reset to 1037 the value of Ns only if Ns is greater than (modulo 2**16) the 1038 receiver's current value of Sr. Normal receive processing of the 1039 message is performed after the value of Sr is reset. Note that if 1040 the F bit is not set, then this bit MUST be 0. See section 4.2 1041 for a detailed discussion of the use of this bit for congestion 1042 control on the data channel. See Appendix E for examples of proper 1043 R bit usage. 1045 If the F bit is set, both the Nr and Ns fields MUST be present. 1046 Ns indicates the sequence number of the packet being sent. The Ns 1047 value of a message being transmitted is copied from the current 1048 value of the send sequence number state variable, Ss. Ss is 1049 incremented by one (modulo 2**16) after copying to the Ns field 1050 only if the payload size of the message being sent is non-zero. 1051 Nr indicates the sequence number of the next in-order message 1052 sequence number to be received (if the last in-order non-zero- 1053 length data packet had Ns set to 1, the Nr sent back would be 2). 1054 The value of Nr is copied from the current receive state variable, 1055 Sr. Together, Nr and Ns can be used to handle out-of-order 1056 packets, and to provide flow control for the connection. 1058 An L2TP peer setting the F bit, and placing Nr and Ns fields in 1059 its messages, MUST have previously received or sent a Receive 1060 Window Size AVP during establishment of the session. The Nr and 1061 Ns fields are present and updated as described in section 4.0 if 1062 either side has specified an intention to do payload flow control. 1064 The Offset Size field is present if the O bit is set in the header 1065 flags. This field specifies the number of octets past the L2TP 1066 header at which the payload data is expected to start. It is 1067 recommended that data thus skipped be initialized to 0's. If 1068 Offset Size is 0, or the O bit is not set, the first octet 1069 following the last octet of L2TP header is the first octet of 1070 payload data. 1072 If the P bit is set, this packet should receive preferential 1073 treatment at the LAC in its queueing for transmission to the 1074 client. LCP echo requests used as a keepalive for the link, for 1075 instance, should generally be sent from the LNS with this bit set. 1076 Without it, a temporary interval of congestion of the transmission 1077 queues could result in the interference with keepalive messages 1078 and unnecessary loss of the link. 1080 5.4 Control Message Types 1082 Control message and AVP types defined in this specification exist 1083 under Vendor ID 0, indicating IETF defined behavior. The actual 1084 message and AVP semantics are defined in the next section. This 1085 section includes tables that summarize all currently defined 1086 message and AVP types. 1088 Each message type entry in the table below indicates: the integer 1089 value assigned to the message type; the message type abbreviation 1090 used in the AVP Summary Table of Sec. 5.5; and the full name of 1091 the message type. 1093 The integer value assigned to each message type is placed in the 1094 Value field of the Message Type AVP. This AVP MUST be the first 1095 AVP in a message. The currently defined control message types, 1096 grouped by function, are: 1098 Control Connection Management 1100 1 (SCCRQ) Start-Control-Connection-Request 1101 2 (SCCRP) Start-Control-Connection-Reply 1102 3 (SCCCN) Start-Control-Connection-Connected 1103 4 (StopCCN) Stop-Control-Connection-Notification 1104 5 (reserved) 1105 6 Hello 1107 Call Management 1109 7 (OCRQ) Outgoing-Call-Request 1110 8 (OCRP) Outgoing-Call-Reply 1111 9 (OCCN) Outgoing-Call-Connected 1112 10 (ICRQ) Incoming-Call-Request 1113 11 (ICRP) Incoming-Call-Reply 1114 12 (ICCN) Incoming-Call-Connected 1115 13 (reserved) 1116 14 (CDN) Call-Disconnect-Notify 1118 Error Reporting 1120 15 (WEN) WAN-Error-Notify 1122 PPP Session Control 1124 16 (SLI) Set-Link-Info 1126 5.5 AVP Summary 1128 The following table lists all standard L2TP attributes currently 1129 defined. The "Attr" column indicates the integer value assigned to 1130 this attribute. The "M" column indicates the setting of the 1131 "Mandatory" bit of the AVP header for each attribute. The "Len" 1132 field indicates the size of the AVP including the AVP header. A 1133 "+" in this column indicates that the length varies depending upon 1134 the length of the actual contents of the value field. 1136 The "(usage)" list for each entry indicates the message types that 1137 utilize each AVP (See command table of Sec. 5.4). An abbreviation 1138 shown in mixed or upper case letters indicates that the 1139 corresponding AVP MUST be present in this message type; All lower 1140 case indicates that the AVP may optionally appear in this message 1141 type. 1143 A brief summary of the type and contents of the value field for 1144 each attribute is also given for each entry. Refer to the 1145 individual message type descriptions that appear in Section 6 for 1146 further details about the use of a particular AVP in a particular 1147 message type. 1149 Attr M Len Attribute Name (usage) 1151 0 1 8 Message Type (ALL MESSAGES) 1152 16 bit integer value indicating the message type, as defined in 1153 table above. MUST be the first AVP in each message 1155 1 1 10+ Result Code (CDN, StopCCN) 1156 16 bit Integer value indicating result of corresponding request 1157 or reason for issuing a request, 16 bit integer General Error 1158 code and an optional ASCII string error message. See Result 1159 and General Error code tables below. 1161 2 1 8 Protocol Version (SCCRP, SCCRQ) 1162 8 bit L2TP Protocol and Revision numbers 1164 3 1 10 Framing Capabilities (SCCRP, SCCRQ) 1165 32 bit bitmask indicating supported framing types (e.g., 1166 synchronous and asynchronous) 1168 4 1 10 Bearer Capabilities (SCCRP, SCCRQ) 1169 32 bit bitmask indicating supported bearer types (e.g., analog 1170 and digital) 1172 5 0 14 Tie Breaker (sccrq) 1173 8 octet value used to break control connection establishment 1174 collisions 1176 6 0 8 Firmware Revision (sccrp, sccrq) 1177 16 bit integer representing vendor's firmware revision 1179 7 0 6+ Host Name (sccrp, sccrq) 1180 ASCII string name (e.g., DNS name) of issuer 1182 8 1 6+ Vendor Name (SCCRP, SCCRQ) 1183 ASCII string describing issuing device 1185 9 1 8 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 1186 16 bit integer tunnel ID assigned by sender 1188 10 1 8 Receive Window Size (ICCN, ICRP, OCCN, OCRQ, SCCRP, 1189 SCCRQ) 1190 16 bit integer receive window size offered by sender for a 1191 given call or control session 1193 11 1 6+ Challenge (SCCRP, SCCRQ) 1194 1 or more octet value issued by sender wishing to authenticate 1195 control session peer 1197 12 0 9+ Q.931 Cause Code (cdn) 1198 16 bit cause code, 1 octet cause message, and optional ASCII 1199 advisory message 1201 13 1 22 Challenge Response (SCCCN, SCCRP) 1202 16 octet CHAP type response to peer's Challenge 1204 14 1 8 Assigned Call ID (CCRQ, CDN, ICRP, ICRQ, OCRP, OCRQ) 1205 16 bit integer ID assigned to a call by sender 1207 15 1 6+ Call Serial Number (ICRQ, OCRQ) 1208 1 or more octet identifier assigned to a call 1210 16 1 10 Minimum BPS (OCRQ) 1211 32 bit integer indicating lowest acceptable line speed for call 1213 17 1 10 Maximum BPS (OCRQ) 1214 32 bit integer indicating highest acceptable line speed for 1215 call 1217 18 1 10 Bearer Type (ICRQ, OCRQ) 1218 Indicates bearer type (i.e., analog or digital) for call 1220 19 1 10 Framing Type (ICCN, OCCN, OCRQ) 1221 Indicates framing type (i.e., synchronous or asynchronous) for 1222 call 1224 20 1 8 Packet Processing Delay (ICCN, ICRP, OCCN, OCRQ) 1225 16 bit integer estimate of processing time of full window of 1226 received packets by sender 1228 21 1 6+ Dialed Number (icrq, OCRQ) 1229 ASCII string phone number called or to be called 1231 22 1 6+ Dialing Number (icrq) 1232 ASCII string phone number of caller 1234 23 1 6+ Sub-Address (icrq, ocrq) 1235 ASCII string containing additional dialing information 1237 24 1 10 (Tx) Connect Speed (ICCN, OCCN, OCRP) 1238 32 bit integer representing actual (transmit) line speed of 1239 connection 1241 25 1 10 Physical Channel ID (ICRQ, OCRP) 1242 16 bit vendor specific physical device identifier used for call 1244 26 0 6+ Initial Received LCP Confreq (iccn) 1245 Octet string containing initial CONFREQ received from client 1247 27 0 6+ Last Sent LCP Confreq (iccn) 1248 Octet string containing final CONFREQ sent to client 1250 28 0 6+ Last Received LCP Confreq (iccn) 1251 Octet string containing final CONFREQ received from client 1253 29 1 8 Proxy Authen Type (ICCN) 1254 16 bit integer code indicating client authentication type 1255 negotiated (e.g., PAP, CHAP) 1257 30 0 6+ Proxy Authen Name (iccn) 1258 ASCII string containing name returned by client in 1259 authentication response 1261 31 0 6+ Proxy Authen Challenge (iccn) 1262 Octet string Challenge presented by LAC to client 1264 32 0 8 Proxy Authen ID (iccn) 1265 16 bit integer of which low order octet is ID presented to 1266 client with Challenge. High order octet must be 0. 1268 33 1 6+ Proxy Authen Response (iccn) 1269 Octet string CHAP response or ASCII string password depending 1270 on authentication type used 1272 34 1 32 Call Errors (WEN) 1273 A reserved 16 bit word set to 0 followed by 6 32 bit integer 1274 connection error counters 1276 35 1 16 ACCM (SLI) 1277 A reserved 16 bit word set to 0 followed by 2 32 bit bitmasks 1278 containing Send and Receive ACCM values respectively 1280 36 1 6+ Random Vector (all messages) 1281 Variable length octet string containing a random sequence of 1282 values used to accomplish the optional "hiding" of other AVP 1283 values (See "H" bit description in Sec. 5.7). 1285 37 1 6+ Private Group ID (iccn) 1286 Variable length octet value used by the LAC or LNS to indicate 1287 that this call is to be associated with a particular customer 1288 group. 1290 38 0 10 Rx Connect Speed (iccn, occn, ocrp) 1291 32 bit integer representing actual receive line speed of 1292 connection. Suggests possibility of asymmetric connection. 1294 5.6 Result and Error Code Summary 1296 The StopCCN and CDN message types contain a Result Code AVP which 1297 indicates the result of the previously requested operation. The 1298 Result Code can indicate that additional information pertaining to an 1299 error situation can be found in the Error Code field of the Result 1300 Code AVP. The meaning of the result code is tabulated under the 1301 specific type of message containing the result. Each 16-bit Result 1302 Code is immediately followed (in the same AVP) by a 16-bit General 1303 Error code value. 1305 General error codes pertain to types of errors which are not specific 1306 to any particular L2TP request, but rather to protocol or message 1307 format errors. If an L2TP reply indicates in its Result Code that a 1308 general error occurred, the General Error value should be examined to 1309 determine what the error was. The currently defined General Error 1310 codes and their meanings are: 1312 0 - No general error 1313 1 - No control connection exists yet for this LAC-LNS pair 1314 2 - Length is wrong 1315 3 - One of the field values was out of range or reserved field was 1316 non-zero 1317 4 - Insufficient resources to handle this operation now 1318 5 - The Call ID is invalid in this context 1319 6 - A generic vendor-specific error occurred in the LAC 1320 7 - Try another. If LAC is aware of other possible LNS 1321 destinations, it should try one of them. This can be used to 1322 guide an LAC based on LNS policy, for instance, the existence 1323 of multilink PPP bundles. 1325 If the length of the Result Code AVP specifies that the Value field 1326 is more than four octets in length, the remaining octets after the 1327 General Error Code field are an arbitrary string providing further 1328 (possibly human readable) text associated with the condition. 1330 Generally, when a General Error Code of 6 is used, additional 1331 information about the error will be included in the Optional Message 1332 field that follows the Error Code field in the Result Code AVP. 1334 5.7 Hiding of AVP values 1336 The H ("Hidden") bit in the header of each AVP in a control message 1337 provides a mechanism to indicate to the receiving peer whether the 1338 contents of the AVP are hidden or present in cleartext. This feature 1339 can be used to hide sensitive control message data such as user 1340 passwords or user ID's. The H bit MUST NOT be set in the Random 1341 Vector AVP. 1343 The H bit MUST only be set if a shared secret exists between the 1344 peers on either end of the tunnel. If the H bit is set in any AVP(s) 1345 in a given command message, a Random Vector AVP must also be present 1346 in the message and MUST precede the first AVP having an H-bit of 1. 1348 The length of the AVP value to be hidden is first encoded in the form 1349 of a Hidden AVP Subformat as follows: 1351 0 1 2 3 1352 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | Length of Original Value | Original Value ... 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 ... | Padding ... 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 Length 1360 This is length of the Original Value to be obscured in octets. 1362 Original Value 1363 Value of hidden AVP that is to be obscured. 1365 Padding 1366 Random additional octets used to obscure length of the Original 1367 Value. 1369 The resulting subformat MAY be padded to a multiple of 16 octets in 1370 length. For example, if the Original Value to be obscured is a string 1371 containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 1372 octects of padding would be applied. Padding does NOT alter the value 1373 placed in the Length of the Original Value, only the length of the 1374 AVP itself. 1376 Next, An MD5 hash is performed on the concatenation of: 1378 - the 2 octet Attribute number of the AVP 1379 - the shared authentication secret 1380 - and an arbitrary length random vector 1382 The value of the random vector used in this hash is passed in the 1383 value field of a Random Vector AVP. This Random Vector AVP must be 1384 placed in the message by the sender before any hidden AVPs. The same 1385 random vector may be used for more than one hidden AVP in the same 1386 message. If a different random vector is used for the hiding of 1387 subsequent AVPs then a new Random Vector AVP must be placed in the 1388 command message before the first AVP to which it applies. 1390 The MD5 hash value is then XORed with the first 16 octet or less 1391 segment of the Hidden AVP Subformat and placed in the Value field of 1392 the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, 1393 the Subformat is transformed as if the Value field had been padded to 1394 16 octets before the XOR, but only the actual octets present in the 1395 Subformat are modified, and the length of the AVP is not altered. 1397 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1398 is calculated over a stream of octets consisting of the shared secret 1399 followed by the result of the first XOR. That hash is XORed with the 1400 second 16 octet or less segment of the Subformat and placed in the 1401 corresponding octets of the Value field of the Hidden AVP. 1403 If necessary, this operation is repeated, with each XOR result being 1404 used along with the shared secret to generate the next hash to XOR 1405 the next segment of the value with. This technique results in the 1406 content of the AVP being obscured, although the length of the AVP is 1407 still known. 1409 On receipt, the random vector is taken from the last Random Vector 1410 AVP encountered in the message prior to the AVP to be unhidden. The 1411 above process is then reversed to yield the original value. For more 1412 details on this hiding method, consult the RADIUS [8] RFC. 1414 The Random Vector AVP has the following format: 1416 Random Vector 1418 0 1 2 3 1419 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 |1|0|0|0| 6 + String length | 0 | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | 36 | Random Octet String ... 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 The Random Vector AVP may be used in any message type. The Attribute 1427 value is 36 and it is marked mandatory. It is used to enable the 1428 hiding of the values of arbitrary AVPs. It MUST precede any AVP 1429 containing an AVP with the H-bit set but it MUST NOT itself have the 1430 H-bit set. More than one Random Vector AVP may appear in a message, 1431 in which case the one most closely preceding an AVP with the H-bit 1432 set pertains to that AVP. The Random Octet String is the random 1433 vector value to use in computing the MD5 hash to retrieve the 1434 original value of a hidden AVP. This string can be of arbitrary 1435 length, although a random vector of at least 16 octets is 1436 recommended. 1438 6.0 Control Connection Protocol Specification 1440 Control Connection messages are used to establish and clear user 1441 sessions. The first set of Control Connection messages are used to 1442 maintain the control connection itself. The control connection is 1443 initiated by an LAC or LNS after establishing the underlying tunnel- 1444 over-media connection. 1446 6.0.1 Control Connection Collision 1448 For the case where an LAC and LNS both initiate tunnels to each 1449 other concurrently, and where the LAC and LNS both determine that 1450 a single tunnel suffices (generally because of media 1451 characteristic considerations, for instance, whether individual 1452 tunnels are needed to gain QOS guarantees for each tunnel), a "tie 1453 breaker" may be undertaken. The details of breaking a tie are 1454 documented with the tunnel establishment messages (Sec. 6.1). 1456 6.0.2 Reliable Delivery of Control Messages 1458 Since L2TP may run across media where packets may be lost, an L2TP 1459 peer sending a control message will retransmit the control message 1460 after deciding that its remote peer has not received it. The 1461 reliable transport mechanism built into L2TP is essentially a 1462 lower layer transport service; the Nr and Ns fields of the control 1463 message header belong to this transport layer. The higher layer 1464 functions of L2TP are not concerned with retransmission or 1465 ordering of control messages. 1467 Each tunnel maintains a queue of control messages to be 1468 transmitted to the peer. The message at the front of the queue is 1469 sent with a given Ns value, and is held until a control message 1470 arrives from the peer in which the Nr field indicates receipt of 1471 this message. After a fixed (recommended default is 1 second) or 1472 adaptive (see Appendix D) timeout interval expires without 1473 receiving such an acknowledgment, the control message packet is 1474 retransmitted. The retransmitted packet contains the same Ns 1475 value, but the Nr value MUST be updated with the current value of 1476 Sr to reflect any packets received in the interim. 1478 If no peer response is detected after several retransmissions (a 1479 recommended default is 5, but may be altered due to media 1480 considerations), the tunnel and all sessions within MUST be 1481 cleared. 1483 When a tunnel is being shut down for reasons other than loss of 1484 connectivity, the state and reliable delivery mechanisms MUST be 1485 maintained and operated for the full retransmission interval after 1486 the final message exchange has occurred. This permits reliable 1487 delivery of closing messages in environments where these closing 1488 messages might be dropped. 1490 A peer MUST NOT withhold acknowledgment of packets as a technique 1491 for flow controlling control messages. An L2TP implementation is 1492 expected to be able to keep up with incoming control messages, 1493 possibly responding to some with errors reflecting an inability to 1494 honor the requested action. 1496 A sliding window mechanism is used, by default, for control 1497 message transmission. The default is to permit four control 1498 messages to be outstanding on a given tunnel. If a peer specifies 1499 a Receive Window Size AVP in the Start-Control-Connection-Request 1500 and -Reply packets, up to the indicated number of control messages 1501 may be sent and held outstanding. An implementation may only 1502 support a receive window of 1, but MUST accept at least a window 1503 of 4 from its peer. Unlike payload sessions, a value of 0 for the 1504 Receive Window Size AVP is invalid for a control session. 1506 The transport layer at a receiving peer is responsible for making 1507 sure that control messages are delivered in order to the higher 1508 layer and that duplicate messages are not delivered to the higher 1509 layer. Messages arriving out of order may be queued for in-order 1510 delivery when the missing messages are received or they may be 1511 discarded, requiring a retransmission. 1513 6.0.3 Control Message Format 1515 The following Control Connection messages are all sent as packets 1516 on the established tunnel connection between a given LNS-LAC pair. 1517 All data is sent in network order (high order octets first). Any 1518 "reserved" or "empty" fields MUST be sent as 0 values to allow for 1519 protocol extensibility. 1521 Each control message has a header, specified in section 5.2, 1522 including an AVP indicating the type of control message, followed 1523 by zero or more AVP's appropriate for the given type of control 1524 message. Each control message is described first at a block 1525 level, and then with details of each AVP. 1527 6.1 Start-Control-Connection-Request (SCCRQ) 1529 The Start-Control-Connection-Request is an L2TP control message used 1530 to initialize the tunnel between an LNS and an LAC. The tunnel must 1531 be initialized through the exchange of these control messages before 1532 any other L2TP messages can be issued. The establishment of the 1533 control connection is started by the initiator of the underlying 1534 tunnel. 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | L2TP Control Message Header | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Start-Control-Connection-Request | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Protocol Version | 1542 | Framing Capabilities | 1543 | Bearer Capabilities | 1544 | Tie Breaker | 1545 | Firmware Revision | 1546 | Host Name | 1547 | Vendor Name | 1548 | Assigned Tunnel ID | 1549 | Receive Window Size | 1550 | Challenge | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+ 1553 Start-Control-Connection-Request 1555 0 1 2 3 1556 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 |1|0|0|0| 8 | 0 | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | 0 | 1 | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 The Message Type AVP contains a Value of 1, indicating Start- 1564 Control-Connection-Request. The Flags indicate a mandatory 1565 option. Details associated with this tunneled session follow in 1566 additional AVP's within the packet. 1568 Protocol Version 1570 0 1 2 3 1571 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 |1|0|0|0| 8 | 0 | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | 2 | 0x01 | 0x00 | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 The Protocol Version AVP within a Start-Control-Connection-Request 1579 packet indicates the L2TP protocol version available. The 1580 Attribute value is 2, indicating Protocol Version, and is marked 1581 mandatory. This AVP MUST be present. The Value field is a 16-bit 1582 hexadecimal value 0x100, indicating L2TP protocol version 1, 1583 revision 0. 1585 Framing Capabilities 1587 0 1 2 3 1588 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 |1|0|0|0| 10 | 0 | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | 3 | 0x00 | 0x00 | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | 0x00 |0|0|0|0|0|0|A|S| 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 The Framing Capabilities AVP within a Start-Control-Connection- 1598 Request indicates the type of framing that the sender of this 1599 message can provide. The Attribute value is 3, indicating Framing 1600 Capabilities, and is marked mandatory. This AVP MUST be present. 1601 The Value field is a 32-bit quantity, with two bits defined. If 1602 bit A is set, asynchronous framing is supported. If bit S is set, 1603 synchronous framing is supported. 1605 This AVP provides the peer with an indication of the types of 1606 framing that will be accepted or initiated by the sender. A peer 1607 should not initiate an incoming or outgoing call with a Framing 1608 Type AVP specifying a value not advertised in the Framing 1609 Capabilities AVP it received during control connection 1610 establishment. Attempts to do so will result in the call being 1611 rejected. 1613 Bearer Capabilities 1615 0 1 2 3 1616 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 |1|0|0|0| 10 | 0 | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | 4 | 0x00 | 0x00 | 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 | 0x00 |0|0|0|0|0|0|A|D| 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 The Bearer Capabilities AVP within a Start-Control-Connection- 1626 Request indicates the bearer capabilities that the sender of this 1627 message can provide. The Attribute value is 4, indicating Bearer 1628 Capabilities, and is marked mandatory. This AVP MUST be present. 1629 The Value field is a 32-bit quantity with two bits defined. If 1630 bit A is set, analog access is supported. If bit D is set, 1631 digital access is supported. 1633 This AVP provides the peer with an indication of the bearer device 1634 types supported by the hardware interfaces of the sender. An LNS 1635 should not initiate an outgoing call specifying a value in the 1636 Bearer Type AVP for a device type not advertised in the Bearer 1637 Capabilities AVP it received from the LAC during control 1638 connection establishment. Attempts to do so will result in the 1639 call being rejected. A LAC should also not initiate incoming calls 1640 with a device type value in the Bearer Type AVP not present in the 1641 Bearer Capabilities AVP it issued during control connection 1642 establishment. 1644 Note that an LNS that cannot act as a LAC as well will not support 1645 hardware devices for handling incoming and outgoing calls and 1646 should therefore set the A and D bits in the Value field of this 1647 AVP to 0. An LNS that can also act as an LAC should set the 1648 appropriate bits in the Value field of this AVP. 1650 Tie Breaker 1651 0 1 2 3 1652 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 |0|0|0|0| 14 | 0 | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | 5 | Tie Break Value... | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Value... | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | ...(64 bits) | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 The Tie Breaker AVP within a Start-Control-Connection-Request 1664 contains a 64-bit Value used to break ties in tunnel establishment 1665 between an LAC-LNS pair. The Attribute value is 5, indicating Tie 1666 Breaker, and is marked optional. This AVP itself is optional. 1667 The 8 byte Value is used as a 64-bit tie breaker value. 1669 If present, it indicates the sender wishes a single tunnel to 1670 exist between the given LAC-LNS pair, and this value will be used 1671 to choose a single tunnel where both LAC and LNS initiate a tunnel 1672 concurrently. The recipient of a Start-Control-Connection-Request 1673 must check to see if a Start-Control-Connection-Request has been 1674 sent to the peer, and if so, must compare its Tie Breaker value 1675 with the received one. The lower value "wins", and the "loser" 1676 MUST sliently discard its tunnel. In the case where a tie breaker 1677 is present on both sides, and the value is equal, both sides MUST 1678 discard their tunnels. 1680 If a tie breaker is received, and the outstanding Start-Control- 1681 Connection-Request had no tie breaker value, the initiator which 1682 included the Tie Breaker AVP "wins". 1684 It is recommended that the Value be set to the MAC address of a 1685 LAN interface on the sender. If no MAC address is available, a 1686 64-bit random number should be used instead. 1688 Firmware Revision 1690 0 1 2 3 1691 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 |0|0|0|0| 8 | 0 | 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 | 6 | Firmware Revision | 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 The Firmware Revision AVP within a Start-Control-Connection- 1699 Request indicates the firmware revision of the issuing device. 1700 The Attribute value is 6, indicating Firmware Revision, and is 1701 marked optional. This AVP itself is optional. The Value field is 1702 a 16-bit integer encoded in a vendor specific format. For devices 1703 which do not have a firmware revision (general purpose computers 1704 running L2TP software modules, for instance), the revision of the 1705 L2TP software module may be reported instead. 1707 Host Name 1709 0 1 2 3 1710 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 |1|0|0|0| 6 + Host name length | 0 | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | 7 | Host name... 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 The Host Name AVP within a Start-Control-Connection-Request 1718 indicates the name of the issuing LAC or LNS. The Attribute value 1719 is 7, indicating Host Name, and is marked mandatory. This AVP 1720 itself MUST be present. This name should be as broadly unique as 1721 possible; for hosts participating in DNS [4], a hostname with 1722 fully qualified domain would be appropriate. 1724 Vendor Name 1726 0 1 2 3 1727 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 |0|0|0|0|6 + vendor name length | 0 | 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 | 8 | Vendor name... 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 The Vendor Name AVP within a Start-Control-Connection-Request 1735 contains a vendor specific string describing the type of LAC or 1736 LNS being used. The Attribute value is 8, indicating Vendor Name, 1737 and is marked optional. This AVP itself is optional. The Value 1738 is the indicated number of bytes representing the vendor string. 1740 Assigned Tunnel ID 1742 0 1 2 3 1743 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 |1|0|0|0| 8 | 0 | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 | 9 | Tunnel ID | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 The Assigned Tunnel ID AVP within a Start-Control-Connection- 1751 Request specifies the Tunnel ID which the receiving peer MUST use 1752 in the Tunnel ID field of all subsequent packets. The Attribute 1753 value is 9, indicating Assigned Tunnel ID, and is marked 1754 mandatory. This AVP MUST be present. Before the Assigned Tunnel 1755 ID AVP is received, packets MUST be sent with a Tunnel ID value of 1756 0. The Value is a 16-bit non-zero Tunnel ID value. 1758 Receive Window Size 1759 0 1 2 3 1760 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 |1|0|0|0| 8 | 0 | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | 10 | Size | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 The Receive Window Size AVP within a Start-Control-Connection- 1768 Request specifies the receive window size being offered to the 1769 remote peer. The Attribute value is 10, indicating Receive Window 1770 Size, and is mandatory. This AVP itself is optional. Value is a 1771 16-bit word indicating the offered window size. If absent, the 1772 peer must assume a value of 4 for its transmit window. The remote 1773 peer may send the specified number of control messages before it 1774 must wait for an acknowledgment. 1776 Challenge 1778 0 1 2 3 1779 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 |1|0|0|0| 6 + Challenge length | 0 | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | 11 | Challenge... 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 The Challenge AVP within a Start-Control-Connection-Request 1787 indicates that the issuing peer wishes to authenticate the tunnel 1788 endpoints using a CHAP-style authentication mechanism. The 1789 Attribute value is 11, indicating Challenge, and is marked 1790 mandatory. This AVP is optional. The Value is one or more octets 1791 of challenge value. 1793 6.2 Start-Control-Connection-Reply (SCCRP) 1795 The Start-Control-Connection-Reply is an L2TP control message sent in 1796 reply to a received Start-Control-Connection-Request message. Sending 1797 this message indicates that the request was successful. 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | L2TP Control Message Header | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | Start-Control-Connection-Reply | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Protocol Version | 1805 | Framing Capabilities | 1806 | Bearer Capabilities | 1807 | Firmware Revision | 1808 | Host Name | 1809 | Vendor Name | 1810 | Assigned Tunnel ID | 1811 | Receive Window Size | 1812 | Challenge | 1813 | Challenge Response | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+ 1816 Start-Control-Connection-Reply 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| 8 | 0 | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | 0 | 2 | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 The Message Type AVP contains a Value of 2, indicating Start- 1827 Control-Connection-Reply. The Flags indicate a mandatory option. 1829 Protocol Version 1831 0 1 2 3 1832 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 |1|0|0|0| 8 | 0 | 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | 2 | 0x01 | 0x00 | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 The Protocol Version AVP within a Start-Control-Connection-Reply 1840 packet indicates the L2TP protocol version available. The 1841 Attribute value is 2, indicating Protocol Version, and the Value 1842 field is a 16-bit hexadecimal value 0x100, indicating L2TP 1843 protocol version 1, revision 0. This AVP MUST be present. 1845 Framing Capabilities 1847 0 1 2 3 1848 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 |1|0|0|0| 10 | 0 | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | 3 | 0x00 | 0x00 | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | 0x00 |0|0|0|0|0|0|A|S| 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 The Framing Capabilities AVP within a Start-Control-Connection- 1858 Reply indicates the type of framing that the sender of this 1859 message can provide. The Attribute is 3, it is a mandatory AVP, 1860 the Value field is a 32-bit quantity, with two bits defined. If 1861 bit A is set, asynchronous framing is supported. If bit S is set, 1862 synchronous framing is supported. This AVP MUST be present. 1864 More details on the use of this AVP can be found in Sec. 6.1. 1866 Bearer Capabilities 1867 0 1 2 3 1868 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 |1|0|0|0| 10 | 0 | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | 4 | 0x00 | 0x00 | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | 0x00 |0|0|0|0|0|0|A|D| 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 The Bearer Capabilities AVP within a Start-Control-Connection- 1878 Reply indicates the bearer capabilities that the sender of this 1879 message can provide. The Attribute is 4, it is a mandatory AVP, 1880 the Value field is a 32-bit quantity with two bits defined. If 1881 bit A is set, analog access is supported. If bit D is set, 1882 digital access is supported. This AVP MUST be present. 1884 More details on the use of this AVP can be found in Sec. 6.1. 1886 Firmware Revision 1888 0 1 2 3 1889 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 |0|0|0|0| 8 | 0 | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | 6 | Firmware Revision | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 The Firmware Revision AVP within a Start-Control-Connection-Reply 1897 indicates the firmware revision of the issuing device. The 1898 Attribute is 6, it is not a mandatory AVP, the Value field is a 1899 16-bit integer encoded in a vendor specific format. For devices 1900 which do not have a firmware revision (general purposes computers 1901 running L2TP software modules, for instance), the revision of the 1902 L2TP software module may be reported instead. This AVP is 1903 optional. 1905 Host Name 1907 0 1 2 3 1908 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 |1|0|0|0| 6 + Host name length | 0 | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | 7 | Host name... 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 The Host Name AVP within a Start-Control-Connection-Reply 1916 indicates the name of the issuing LAC or LNS. See the notes in 1917 section 6.1 concerning Host Name contents. It is encoded as the 1918 Attribute 7, mandatory, with the indicated number of bytes 1919 representing the host name string. This AVP MUST be present. 1921 Vendor Name 1923 0 1 2 3 1924 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 |0|0|0|0|6 + Vendor name length | 0 | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | 8 |Vendor name... 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 The Vendor Name AVP within a Start-Control-Connection-Reply 1932 contains a vendor specific string describing the type of LAC or 1933 LNS being used. It is encoded as the Attribute 8, not mandatory, 1934 with the indicated number of bytes representing the vendor string. 1935 This AVP is optional. 1937 Assigned Tunnel ID 1939 0 1 2 3 1940 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 |1|0|0|0| 8 | 0 | 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | 9 | Tunnel ID | 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply 1948 specifies the Tunnel ID which the receiving peer MUST use in all 1949 subsequent packets. It is encoded as the Attribute 9, mandatory, 1950 with a 16-bit non-zero Tunnel ID value. This AVP MUST be present. 1952 Receive Window Size 1954 0 1 2 3 1955 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 |1|0|0|0| 8 | 0 | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | 10 | size | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 The Receive Window Size AVP within a Start-Control-Connection- 1963 Reply specifies the receive window size being offered to the 1964 remote peer. The Attribute value is 10, indicating Receive Window 1965 Size, and is mandatory. This AVP itself is optional. Value is a 1966 16-bit word indicating the offered window size. If absent, the 1967 peer must assume a value of 4 for its transmit window. The remote 1968 peer may send the specified number of control messages before it 1969 must wait for an acknowledgment. 1971 Challenge 1973 0 1 2 3 1974 0 1 2 3 4 5 6 7 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 + Challenge length | 0 | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | 11 | Challenge... 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 The Challenge AVP within a Start-Control-Connection-Reply 1983 indicates that the peer wishes to authenticate the tunnel 1984 initiator using a CHAP-style authentication mechanism. It is 1985 encoded as the Attribute 11, mandatory, with at least one byte of 1986 challenge value embedded. If this AVP is not present, it 1987 indicates to the receiving peer that the sender does not wish to 1988 authenticate that peer. 1990 Challenge Response 1992 0 1 2 3 1993 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 |1|0|0|0| 22 | 0 | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 | 13 | Response... | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | Response... (128 bits) | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 The Response AVP within a Start-Control-Connection-Reply packet 2003 provides a response to a challenge received. The Attribute value 2004 is 13, indicating Response, and the Value field is a 128-bit value 2005 reflecting the CHAP-style response to the challenge. This AVP 2006 marked mandatory, and MUST be present if a challenge was received 2007 and this Start-Control-Connection-Reply indicates success. For 2008 purposes of the ID value in the CHAP response calculation, the 2009 value 2 (corresponding to the Value field of the Start-Control- 2010 Connection-Reply AVP) MUST be used. 2012 6.3 Start-Control-Connection-Connected (SCCCN) 2014 The Start-Control-Connection-Connected message is an L2TP control 2015 message sent in reply to a received Start-Control-Connection-Reply 2016 message. This message provides closure to the tunnel establishment 2017 process, and includes a challenge response if the peer sent a 2018 challenge in the Start-Control-Connection-Reply message. 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 | L2TP Control Message Header | 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 | Start-Control-Connection-Connected | 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 | Challenge Response | 2026 +-+-+-+-+-+-+-+-+-+-+-+-+ 2028 Start-Control-Connection-Connected 2029 0 1 2 3 2030 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 |1|0|0|0| 8 | 0 | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | 0 | 3 | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 The Message Type AVP contains a Value of 3, indicating Start- 2038 Control-Connection-Connected. The Flags indicate a mandatory 2039 option. 2041 Challenge Response 2043 0 1 2 3 2044 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 |1|0|0|0| 22 | 0 | 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | 13 | Response... | 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | Response... (128 bits) | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 The Challenge Response AVP within a Start-Control-Connection- 2054 Connected packet provides a response to a challenge received. The 2055 Attribute value is 13, indicating Response, and the Value field is 2056 a 128-bit value reflecting the CHAP-style response to the 2057 challenge. This AVP is marked mandatory, and MUST be present if a 2058 challenge was received, otherwise MUST be omitted. For purposes 2059 of the ID value in the CHAP response calculation, the value 3 2060 (corresponding to the Value field of the Start-Control- 2061 Connection-Connected AVP) MUST be used. 2063 6.4 Stop-Control-Connection-Notification (StopCCN) 2065 The Stop-Control-Connection-Notification is an L2TP control message 2066 sent by one peer of an LAC-LNS control connection to inform the other 2067 peer that the control connection should be closed. In addition to 2068 closing the control connection, all active user calls are implicitly 2069 cleared. The reason for issuing this request is indicated in the 2070 Result Code AVP. 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | L2TP Control Message Header | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 | Stop-Control-Connection-Notification| 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | Assigned Tunnel ID | 2078 | Result Code | 2079 +-+-+-+-+-+-+-+-+-+-+-+-+ 2081 Stop-Control-Connection-Notification AVP 2082 0 1 2 3 2083 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 |1|0|0|0| 8 | 0 | 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 | 0 | 4 | 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 The Message Type AVP contains a Value of 4, indicating Stop- 2091 Control-Connection-Notification. The Flags indicate a mandatory 2092 option. 2094 Assigned Tunnel ID 2096 0 1 2 3 2097 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 |1|0|0|0| 8 | 0 | 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | 9 | Tunnel ID | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 The Attribute value is 9, indicating Assigned Tunnel ID, and is 2105 marked mandatory. This AVP MUST be present. The Value MUST be 2106 the same Assigned Tunnel ID first sent to the receiving peer. 2107 This AVP permits the peer to identify the appropriate tunnel even 2108 if Stop-Control-Connection-Notification must be sent before an 2109 Assigned Tunnel ID is received. 2111 Result Code 2113 0 1 2 3 2114 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 |1|0|0|0| 10 + Message length | 0 | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | 1 | Result Code | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 | Error Code | Optional Message ... 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 The Result Code AVP within a Stop-Control-Connection-Notification 2124 packet indicates the reason for terminating the control channel. 2125 It is encoded as Attribute 1, indicating a Result Code AVP. This 2126 AVP is mandatory and MUST be present. The Result Code is a 16-bit 2127 word. The 16-bit word following the Result Code field contains 2128 the Error Code value, which for a Stop-Control-Connection- 2129 Notification is always 0. An optional message can follow the 2130 Error Code field. Its presence and length is indicated by the 2131 value of the AVP length field. Defined Result Code values are: 2133 1 - General request to clear control connection 2134 2 - General error--Error Code indicates the problem 2135 3 - Control channel already exists 2136 4 - Requester is not authorized to establish a control channel 2137 5 - The protocol version of the requester is not supported 2138 Error Code indicates highest version supported 2139 6 - Requester is being shut down 2140 7 - Finite State Machine error 2142 6.5 Hello 2144 The Hello message is an L2TP control message sent by either peer of a 2145 LAC-LNS control connection. This control message is used as a 2146 "keepalive" for the tunnel. 2148 Keepalives may be implemented by sending a Hello once every 60 2149 seconds if 60 seconds have passed without receiving any message 2150 (payload or control, including zero-length messages) from the peer. 2151 The sending of keepalives and the policy for sending them are left up 2152 to the implementation. 2154 When a Hello is received, it MUST be silently discarded (after 2155 updating any effects of the indicated Nr/Ns values). 2157 Because a Hello is a control message, and control messages are 2158 reliably sent by the lower level transport, this keepalive function 2159 operates by causing the transport level to reliably deliver a 2160 message. If a media interruption has occurred, the reliable 2161 transport will be unable to deliver the Hello across, and will clean 2162 up the tunnel. 2164 Hello messages are global to the tunnel; the Call ID field of these 2165 control messages MUST be 0. 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | L2TP Control Message Header | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | Hello | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 Hello 2175 0 1 2 3 2176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 |1|0|0|0| 8 | 0 | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 | 0 | 6 | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 The Message Type AVP contains a Value of 6, indicating Hello The 2184 Flags indicate a mandatory option. 2186 6.6 Outgoing-Call-Request (OCRQ) 2188 The Outgoing-Call-Request is an L2TP control message sent by the LNS 2189 to the LAC to indicate that an outbound call from the LNS is to be 2190 established. This request provides the LAC with information required 2191 to make the call. It also provides information to the LAC that is 2192 used to regulate the transmission of data to the LNS for this session 2193 once it is established. 2195 This message is the first in the "three-way handshake" used by L2TP 2196 for establishing outgoing calls. The first message requests the 2197 call; the second indicates that the call was successfully initiated. 2198 The third and final message indicates that the call was established. 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | L2TP Control Message Header | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | Outgoing-Call-Request | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | Assigned Call ID | 2206 | Call Serial Number | 2207 | Minimum BPS | 2208 | Maximum BPS | 2209 | Bearer Type | 2210 | Framing Type | 2211 | Receive Window Size | 2212 | Packet Processing Delay | 2213 | Dialed Number | 2214 | Sub-Address | 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 Outgoing-Call-Request 2219 0 1 2 3 2220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 |1|0|0|0| 8 | 0 | 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | 0 | 7 | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 The Message Type AVP contains a Value of 7, indicating Outgoing- 2228 Call-Request. The Outgoing-Call-Request encodes a request to an 2229 LAC to establish an outgoing call. The flags indicate a mandatory 2230 option. 2232 Assigned Call ID 2234 0 1 2 3 2235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 |1|0|0|0| 8 | 0 | 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | 14 | Call ID | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 The Assigned Call ID AVP encodes the ID being assigned to this 2243 call by the LNS. The Attribute value is 14, indicating Assigned 2244 Call ID, and is marked mandatory. This AVP MUST be present. The 2245 LAC places this value in the Call ID header field of all command 2246 and payload packets that it subsequently transmits over the tunnel 2247 that belong to this call. The Call ID value is an identifier 2248 assigned by the LNS to this session. It is used to multiplex and 2249 demultiplex data sent over that tunnel between the LNS and LAC. 2251 Call Serial Number 2253 0 1 2 3 2254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 |1|0|0|0| 6 + Number length | 0 | 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | 15 | CSN (H) | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 | CSN (L) | 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 Call Serial Number AVP encodes an identifier assigned by the LNS to 2264 this call. 2265 Attribute is 15, indicating Call Serial Number, and is marked mandatory. 2266 This AVP MUST be present. 2267 The Call Serial Number is intended 2268 to be an easy reference for administrators on both ends of a tunnel to use 2269 when investigating call failure problems. Call Serial Numbers should 2270 be set to progressively increasing values, which are likely to be unique for 2271 a significant period of time across all interconnected LNS and LACs. Other 2272 identification information may also be prepended. 2274 Minimum BPS 2276 0 1 2 3 2277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 |1|0|0|0| 10 | 0 | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | 16 | BPS (H) | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | BPS (L) | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 Minimum BPS AVP encodes the lowest acceptable line speed for this 2287 call. Attribute is 16, Minimum BPS, and is marked mandatory. 2288 This AVP MUST be present. The BPS value indicates the speed in 2289 bits/second. 2291 Maximum BPS 2293 0 1 2 3 2294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 |1|0|0|0| 10 | 0 | 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 | 17 | BPS (H) | 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | BPS (L) | 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 Maximum BPS AVP encodes the highest acceptable line speed for this 2304 call. Attribute is 17, indicating Maximum BPS, and is marked 2305 mandatory. This AVP MUST be present. The BPS value indicates the 2306 speed in bits/second. 2308 Bearer Type 2310 0 1 2 3 2311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 |1|0|0|0| 10 | 0 | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 Bearer Type AVP encodes the bearer type for the requested call. 2321 The Attribute is 18, indicating Bearer Type, and is marked 2322 mandatory. This AVP MUST be present. The Value is a 32-bit 2323 quantity indicating the bearer capability required for this 2324 outgoing call. If set, bit A indicates that the call should be on 2325 an analog channel. If set, bit D indicates that the call should 2326 be on a digital channel. Both may be set, indicating that the 2327 call can be of either type. 2329 A particular bit in the Value field of this AVP MAY only be set by 2330 the LNS if it was set in the Bearer Capabilities AVP received from 2331 the LAC during control session establishment. 2333 Framing Type 2335 0 1 2 3 2336 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 |1|0|0|0| 10 | 0 | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 Framing Type AVP encodes the framing type for the requested call. 2346 Attribute is 19, indicating Framing Type, and is marked mandatory. 2347 This AVP MUST be present. The 32-bit field indicates the type of 2348 PPP framing to be used for the outgoing call. Bit A if set 2349 indicates that asynchronous framing should be used. Bit S is set 2350 indicates that synchronous framing should be used. Both may be 2351 set, indicating that either type of framing may be used for the 2352 call. 2354 A particular bit in the Value field of this AVP MAY only be set by 2355 the LNS if it was set in the Framing Capabilities AVP received 2356 from the LAC during control session establishment. 2358 Receive Window Size 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| 8 | 0 | 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 | 10 | Size | 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 Receive Window Size AVP encodes the window size being advertised 2369 by the LNS for this call. Attribute is 10, indicating Receive 2370 Window Size, and is marked mandatory. This AVP is optional. The 2371 Size value indicates the number of received data packets the LNS 2372 will buffer for this call, which is also the maximum number of 2373 data packets the LAC should send before waiting for an 2374 acknowledgment. The absence of this AVP indicates that Sequence 2375 and Acknowledgment Numbers are not to be used in the payload 2376 session for this call. 2378 Packet Processing Delay 2380 0 1 2 3 2381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 |1|0|0|0| 8 | 0 | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | 20 | Delay | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 The Packet Processing Delay AVP encodes the delay LNS has for 2389 processing a window full of packets sent by the LAC. Attribute is 2390 20, indicating Packet Processing Delay, and is marked mandatory. 2391 This AVP is optional. The Delay value is specified in units of 2392 1/10 seconds. Refer to Appendix A for a description of how this 2393 value is determined and used. 2395 Dialed Number 2397 0 1 2 3 2398 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 |1|0|0|0|6 + Phone Number length| 0 | 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 | 21 | Phone Number.. 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 Phone Number AVP encodes the phone number to be called. Attribute 2406 is 21, indicating Phone Number, and is marked mandatory. This AVP 2407 MUST be present. The Phone Number value is an ASCII string. 2409 Sub-Address 2411 0 1 2 3 2412 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2414 |1|0|0|0|6 + Sub-Address length | 0 | 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 | 23 |Sub-Address ... 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 Sub-Address AVP encodes additional dialing information. Attribute 2420 is 23, indicating Sub-Address, and is marked mandatory. This AVP 2421 is optional. The Sub-Address value is an ASCII string. 2423 6.7 Outgoing-Call-Reply (OCRP) 2425 The Outgoing-Call-Reply is an L2TP control message sent by the LAC to 2426 the LNS in response to a received Outgoing-Call-Request message. The 2427 reply indicates that the LAC is able to attempt the outbound call and 2428 also returns certain parameters regarding the call attempt. 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 | L2TP Control Message Header | 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2433 | Outgoing-Call-Reply | 2434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2435 | Assigned Call ID | 2436 | (Tx) Connect Speed | 2437 | Physical Channel Id | 2438 | Rx Connect Speed | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 Outgoing-Call-Reply 2443 0 1 2 3 2444 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 |1|0|0|0| 8 | 0 | 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | 0 | 8 | 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 The Message Type AVP contains a Value of 8, indicating Outgoing- 2452 Call-Reply. The Outgoing-Call-Reply message encodes the immediate 2453 result of attempting an outgoing call request. The flags indicate a 2454 mandatory option. 2456 Assigned Call ID 2458 0 1 2 3 2459 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 |1|0|0|0| 8 | 0 | 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 | 14 | Call ID | 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2467 The Assigned Call ID AVP encodes the ID being assigned to this call 2468 by the LAC. Attribute is 14, indicating Assigned Call ID, and is 2469 marked mandatory. This AVP MUST be present. Call ID value is an 2470 identifier, unique within the tunnel, assigned by the sender to this 2471 session. The remote peer MUST place this Call ID in the Call ID 2472 portion of all future packets it sends associated with this session. 2473 It is used to multiplex and demultiplex data sent over that tunnel 2474 between the LNS and LAC. 2476 (Tx) Connect Speed 2478 0 1 2 3 2479 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 |1|0|0|0| 10 | 0 | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 | 24 | BPS (H) | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | BPS (L) | 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen 2489 for the connection attempt. The Attribute value is 24, indicating 2490 (Tx) Connect Speed, and is marked mandatory. This AVP MUST be 2491 present. The BPS is a 32-bit value indicating the speed in 2492 bits/second. 2494 When the optional Rx Connect Speed AVP is present, the value in this 2495 AVP represents the transmit connect speed, from the perspective of 2496 the LAC (e.g. data flowing from the LAC to the client). When the 2497 optional Rx Connect Speed AVP is NOT present, the connection speed 2498 between the client and LAC is assumed to be symmetric and is 2499 represented by the single value in this AVP. 2501 Physical Channel ID 2503 0 1 2 3 2504 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 |1|0|0|0| 10 | 0 | 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 | 25 | ID (H) | 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | ID (L) | 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 Physical Channel ID AVP encodes the vendor specific physical channel 2514 number used for the call. The Attribute value is 25, indicating 2515 Physical Channel ID, and is marked optional. This AVP itself is 2516 optional. ID is a 32-bit value in network byte order. The value is 2517 used for logging purposes only. 2519 Rx Connect Speed 2521 0 1 2 3 2522 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 |0|0|0|0| 10 | 0 | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 | 38 | BPS (H) | 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 | BPS (L) | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 Rx Connect Speed BPS AVP encodes the receive speed of the facility 2532 chosen for the connection attempt. The Attribute value is 38, 2533 indicating Rx Connect Speed, and is marked optional. The Rx Connect 2534 Speed represents the speed of the connection from the perspective of 2535 the LAC (e.g. data flowing from the client to the LAC). Presence of 2536 this AVP implies that the connection speed may be asymmetric, with 2537 the transmit connect speed given in the (Tx) Connect Speed AVP. The 2538 BPS is a 32-bit value indicating the speed in bits/second. 2540 6.8 Outgoing-Call-Connected (OCCN) 2542 Outgoing-Call-Connected is an L2TP control message sent by the LAC to 2543 the LNS to indicate that the result of a requested outgoing call was 2544 successful. The LAC MUST send the corresponding Outgoing-Call-Reply 2545 to the LNS before sending this message. This message provides 2546 information to the LNS about the particular parameters used for the 2547 call. It provides information to allow the LNS to regulate the 2548 transmission of data to the LAC for this session. 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | L2TP Control Message Header | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Outgoing-Call-Connected | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 | (Tx) Connect Speed | 2556 | Framing Type | 2557 | Receive Window Size | 2558 | Packet Processing Delay | 2559 | Rx Connect Speed | 2560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 Outgoing-Call-Connected 2564 0 1 2 3 2565 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 |1|0|0|0| 8 | 0 | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | 0 | 9 | 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 The Message Type AVP contains a Value of 9, indicating Outgoing- 2573 Call-Connected. The Outgoing-Call-Connected message encodes the 2574 final result of an outgoing call request. The flags indicate a 2575 mandatory option. 2577 (Tx) Connect Speed 2579 0 1 2 3 2580 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 |1|0|0|0| 10 | 0 | 2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 | 24 | BPS (H) | 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 | BPS (L) | 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen 2590 for the connection attempt. The Attribute value is 24, indicating 2591 (Tx) Connect Speed, and is marked mandatory. This AVP MUST be 2592 present. The BPS is a 32-bit value indicating the speed in 2593 bits/second. 2595 When the optional Rx Connect Speed AVP is present, the value in this 2596 AVP represents the transmit connect speed, from the perspective of 2597 the LAC (e.g. data flowing from the LAC to the client). When the 2598 optional Rx Connect Speed AVP is NOT present, the connection speed 2599 between the client and LAC is assumed to be symmetric and is 2600 represented by the single value in this AVP. 2602 Framing Type 2604 0 1 2 3 2605 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 |1|0|0|0| 10 | 0 | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 Framing Type AVP encodes the framing type for the call. The 2615 Attribute value is 19, indicating Framing Type, and is marked 2616 mandatory. This AVP MUST be present. The bit field indicates the 2617 type of PPP framing used for the call. If set, bit A indicates that 2618 asynchronous framing is being used. If set, bit S indicates that 2619 synchronous framing is being used. A particular type of framing may 2620 be used only if it was specified in the Framing Type AVP of the 2621 Outgoing-Call-Request issued by the LNS. 2623 Receive Window Size 2625 0 1 2 3 2626 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2628 |1|0|0|0| 8 | 0 | 2629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2630 | 10 | Size | 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 Receive Window Size AVP encodes the window size being offered by the 2634 LNS for this call. The Attribute value is 10, indicating Receive 2635 Window Size, and is marked mandatory. The Size is a 16-bit value 2636 indicating the number of received data packets the LAC will buffer 2637 for this call, which is also the maximum number of data packets the 2638 LNS should send before waiting for an acknowledgment. This AVP is 2639 present only if Sequence and Acknowledgment Numbers are to be used in 2640 the payload session for this call. 2642 Packet Processing Delay 2644 0 1 2 3 2645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 |1|0|0|0| 8 | 0 | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2649 | 20 | Delay | 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2652 Packet Processing Delay AVP encodes the delay the LAC expects for 2653 processing a window full of packets sent by the LNS. The Attribute 2654 value is 20, indicating Packet Processing Delay, and is marked 2655 mandatory. This AVP is optional. The Delay value is specified in 2656 units of 1/10 seconds. Refer to Appendix A to see a description of 2657 how this value is determined and used. 2659 Rx Connect Speed 2661 0 1 2 3 2662 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 |0|0|0|0| 10 | 0 | 2665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2666 | 38 | BPS (H) | 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 | BPS (L) | 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 Rx Connect Speed BPS AVP encodes the receive speed of the facility 2672 chosen for the connection attempt. The Attribute value is 38, 2673 indicating Rx Connect Speed, and is marked optional. The Rx Connect 2674 Speed represents the speed of the connection from the perspective of 2675 the LAC (e.g. data flowing from the client to the LAC). Presence of 2676 this AVP implies that the connection speed may be asymmetric, with 2677 the transmit connect speed given in the (Tx) Connect Speed AVP. The 2678 BPS is a 32-bit value indicating the speed in bits/second. 2680 6.9 Incoming-Call-Request (ICRQ) 2682 Incoming-Call-Request is an L2TP control message sent by the LAC to 2683 the LNS to indicate that an inbound call is to be established from 2684 the LAC. This request provides the LNS with parameter information 2685 for the incoming call. 2687 This message is the first in the "three-way handshake" used by L2TP 2688 for establishing incoming calls. The LAC may defer answering the 2689 call until it has received an Incoming-Call-Reply from the LNS 2690 indicating that the call should be established. This mechanism 2691 allows the LNS to obtain sufficient information about the call before 2692 it is answered to determine whether the call should be answered or 2693 not. Alternatively, the LAC may answer the call, negotiate LCP and 2694 PPP authentication, and use the information gained to choose the LNS. 2695 In this case, the call has already been answered by the time the 2696 Incoming-Call-Reply message is received; the LAC simply spoofs the 2697 "call indication/answer call" phase in this case. 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 | L2TP Control Message Header | 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 | Incoming-Call-Request | 2703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 | Assigned Call ID | 2705 | Call Serial Number | 2706 | Bearer Type | 2707 | Physical Channel ID | 2708 | Dialed Number | 2709 | Dialing Number | 2710 | Sub-Address | 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 Incoming-Call-Request 2715 0 1 2 3 2716 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 |1|0|0|0| 8 | 0 | 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 | 0 | 10 | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 The Message Type AVP contains a Value of 10, indicating Incoming- 2724 Call-Request. The Incoming-Call-Request message encodes an incoming 2725 call being indicated by the LAC. The flags indicate a mandatory 2726 option. 2728 Assigned Call ID 2730 0 1 2 3 2731 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 |1|0|0|0| 8 | 0 | 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 | 14 | Call ID | 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 The Assigned Call ID AVP encodes the ID being assigned to this call 2739 by the LAC. The Attribute value is 14, indicating Assigned Call ID, 2740 and is marked mandatory. This AVP MUST be present. The LNS places 2741 this value in the Call ID header field of all command and payload 2742 packets that it subsequently transmits over the tunnel that belong to 2743 this call. The Call ID value is an identifier assigned by the LAC to 2744 this session. It is used to multiplex and demultiplex data sent over 2745 that tunnel between the LNS and LAC. 2747 Call Serial Number 2749 0 1 2 3 2750 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 |1|0|0|0| 6 + Number length | 0 | 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2754 | 15 | CSN (H) | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 | CSN (L) | 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2759 Call Serial Number AVP encodes an identifier assigned by the LAC to 2760 this call. The Attribute value is 15, Call Serial Number, and is 2761 marked mandatory. This AVP MUST be present. Please refer to the 2762 description of this field from section 6.7. 2764 Bearer Type 2766 0 1 2 3 2767 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 |1|0|0|0| 10 | 0 | 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 Bearer Type AVP encodes the bearer type for the incoming call. The 2777 Attribute value is 18, Bearer Type, and is marked mandatory. This 2778 AVP MUST be present. The Value is a 32-bit field indicating the 2779 bearer capability being used by the incoming call. If set, bit A 2780 indicates that the call is on an analog channel. If set, bit D 2781 indicates that the call is on a digital channel. 2783 A particular bit in the Value field of this AVP should only be set by 2784 the LAC if it was set in the Bearer Capabilities AVP sent to the LNS 2785 during control session establishment. 2787 Physical Channel ID 2789 0 1 2 3 2790 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 |1|0|0|0| 10 | 0 | 2793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 | 25 | ID (H) | 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 | ID (L) | 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 Physical Channel ID AVP encodes the vendor specific physical channel 2800 number used for the call. The Attribute value is 25, Physical 2801 Channel ID, and is marked mandatory. The presence of this AVP is 2802 optional. ID is a 32-bit value in network byte order. The value is 2803 used for logging purposes only. 2805 Dialed Number 2807 0 1 2 3 2808 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 |1|0|0|0|6 + Phone Number length| 0 | 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 | 21 | Phone Number.. 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2815 Dialed Number AVP encodes the dialed number for the incoming call, 2816 that is, DNIS. The Attribute value is 21, Dialed Number, and is 2817 marked mandatory. The presence of this AVP is optional. The value 2818 is an ASCII string. 2820 Dialing Number 2822 0 1 2 3 2823 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 |1|0|0|0|6 + Phone Number length| 0 | 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 | 22 |Phone Number... 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2830 Dialing Number AVP encodes the originating number for the incoming 2831 call, that is, CLID. The Attribute value is 22, Dialing Number, and 2832 is marked mandatory. The presence of this AVP is optional. The 2833 value is an ASCII string. 2835 Sub-Address 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 2840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2841 |1|0|0|0|6 + Sub-Address length | 0 | 2842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 | 23 |Sub-Address ... 2844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 Sub-Address AVP encodes additional dialing information. The 2847 Attribute value is 23, Sub-Address, and is marked mandatory. The 2848 presence of this AVP is optional. The Sub-Address value is an ASCII 2849 string. 2851 6.10 Incoming-Call-Reply (ICRP) 2853 The Incoming-Call-Reply is an L2TP control message sent by the LNS to 2854 the LAC in response to a received Incoming-Call-Request message. The 2855 reply indicates that the request was successful. It also provides 2856 information to allow the LAC to regulate the transmission of data to 2857 the LNS for this session. 2859 This message is the second in the three-way handshake used by L2TP 2860 for establishing incoming calls. It indicates to the LAC that the 2861 call should be answered. 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2864 | L2TP Control Message Header | 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2866 | Incoming-Call-Reply | 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 | Assigned Call ID | 2869 | Receive Window Size | 2870 | Packet Processing Delay | 2871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2873 Incoming-Call-Reply 2875 0 1 2 3 2876 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 |1|0|0|0| 8 | 0 | 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2880 | 0 | 11 | 2881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2883 The Message Type AVP contains a Value of 11, indicating Incoming- 2884 Call-Reply. The Incoming-Call-Reply message encodes a response by 2885 the LNS to the incoming call indication given by the LAC. The flags 2886 indicate a mandatory option. 2888 Assigned Call ID 2890 0 1 2 3 2891 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 |1|0|0|0| 8 | 0 | 2894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2895 | 14 | Call ID | 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2898 The Assigned Call ID AVP encodes the ID being assigned to this call 2899 by the LNS. The Attribute value is 14, indicating Assigned Call ID, 2900 and is marked mandatory. This AVP MUST be present. The LAC places 2901 this value in the Call ID header field of all command and payload 2902 packets that it subsequently transmits over the tunnel that belong to 2903 this call. The Call ID value is an identifier assigned by the LNS to 2904 this session. It is used to multiplex and demultiplex data sent over 2905 that tunnel between the LNS and LAC. 2907 Receive Window Size 2909 0 1 2 3 2910 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 |1|0|0|0| 8 | 0 | 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 | 10 | Size | 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2916 | Optional Message... | 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 Receive Window Size AVP encodes the receive window size being offered 2920 by the LNS for this call. The Attribute value is 10, Receive Window 2921 Size, and is marked mandatory. The Size value indicates the number 2922 of received data packets the LNS will buffer for this call, which is 2923 also the maximum number of data packets the LAC should send before 2924 waiting for an acknowledgment. This AVP is present only if Sequence 2925 and Acknowledgment Numbers are to be used in the payload session for 2926 this call. 2928 Packet Processing Delay 2930 0 1 2 3 2931 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 |1|0|0|0| 8 | 0 | 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2935 | 20 | Delay | 2936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2938 Packet Processing Delay AVP encodes the delay the LNS expects for 2939 processing a window full of packets sent by the LAC. The Attribute 2940 value is 20, Packet Processing Delay AVP, and is marked mandatory. 2941 The presence of this AVP is optional. The Delay value is specified 2942 in units of 1/10 seconds. Refer to Appendix A to see a description 2943 of how this value is determined and used. 2945 6.11 Incoming-Call-Connected (ICCN) 2947 The Incoming-Call-Connected message is an L2TP control message sent 2948 by the LAC to the LNS in response to a received Incoming-Call-Reply. 2949 It provides information to the LNS about particular parameters used 2950 for the call. It also provides information to allow the LNS to 2951 regulate the transmission of data to the LAC for this session. 2953 This message is the third in the three-way handshake used by L2TP for 2954 establishing incoming calls. It provides a mechanism for providing 2955 the LNS with additional information about the call that cannot, in 2956 general, be obtained at the time the Incoming-Call-Request is issued 2957 by the LAC. 2959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 | L2TP Control Message Header | 2961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2962 | Incoming-Call-Connected | 2963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2964 | (Tx) Connect Speed | 2965 | Framing Type | 2966 | Receive Window Size | 2967 | Packet Processing Delay | 2968 | Initial Reveived LCP Confreq | 2969 | Last Sent LCP Confreq | 2970 | Last Received LCP Confreq | 2971 | Proxy authen type | 2972 | Proxy authen name | 2973 | Proxy authen challenge | 2974 | Proxy authen ID | 2975 | Proxy authen response | 2976 | Private Group ID | 2977 | Rx Connect Speed | 2978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2980 Incoming-Call-Connected 2982 0 1 2 3 2983 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2985 |1|0|0|0| 8 | 0 | 2986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2987 | 0 | 12 | 2988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2990 The Message Type AVP contains a Value of 12, indicating Incoming- 2991 Call-Connected. The Incoming-Call-Connected message encodes a 2992 response by the LAC to the Incoming-Call-Reply message sent by the 2993 LAC. The flags indicate a mandatory option. 2995 (Tx) Connect Speed 2997 0 1 2 3 2998 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3000 |1|0|0|0| 10 | 0 | 3001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3002 | 24 | BPS (H) | 3003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3004 | BPS (L) | 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3007 (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen 3008 for the connection attempt. The Attribute value is 24, indicating 3009 (Tx) Connect Speed, and is marked mandatory. This AVP MUST be 3010 present. The BPS is a 32-bit value indicating the speed in 3011 bits/second. 3013 When the optional Rx Connect Speed AVP is present, the value in this 3014 AVP represents the transmit connect speed, from the perspective of 3015 the LAC (e.g. data flowing from the LAC to the client). When the 3016 optional Rx Connect Speed AVP is NOT present, the connection speed 3017 between the client and LAC is assumed to be symmetric and is 3018 represented by the single value in this AVP. 3020 Framing Type 3022 0 1 2 3 3023 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3025 |1|0|0|0| 10 | 0 | 3026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3027 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 3028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3029 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 3030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3032 Framing Type AVP encodes the framing type for the call. The 3033 Attribute value is 19, Framing Type, and is marked mandatory. This 3034 AVP MUST be present. The value is a 32-bit bit field indicating the 3035 type of PPP framing used for the call. If set, bit A indicates that 3036 asynchronous framing is being used. If set, bit S indicates that 3037 synchronous framing is being used. A particular type of framing may 3038 be used only if was specified in the Value field of the Framing 3039 Capabilities AVP received from the LNS during control session 3040 establishment. 3042 Receive Window Size 3044 0 1 2 3 3045 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3047 |1|0|0|0| 8 | 0 | 3048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3049 | 10 | Size | 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3052 Receive Window Size AVP encodes the window size being offered by the 3053 LAC for this call. The Attribute value is 10, Receive Window Size, 3054 and is marked mandatory. This AVP is present only if Sequence and 3055 Acknowledgment Numbers are to be used in the payload session for this 3056 call. The 16-bit Size value indicates the number of received data 3057 packets the LAC will buffer for this call, which is also the maximum 3058 number of data packets the LNS should send before waiting for an 3059 acknowledgment. 3061 Packet Processing Delay 3063 0 1 2 3 3064 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3066 |1|0|0|0| 8 | 0 | 3067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3068 | 20 | Delay | 3069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3071 Packet Processing Delay AVP encodes the delay the LAC expects for 3072 processing a window full of packets sent by the LNS. The Attribute 3073 value is 20, Packet Processing Delay, and is marked mandatory. The 3074 presence of this AVP is optional. The 16-bit Delay value is 3075 specified in units of 1/10 seconds. Refer to Appendix A to see a 3076 description of how this value is determined and used. 3078 Initial Received LCP Confreq 3080 0 1 2 3 3081 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3083 |0|0|0|0|6 + LCP confreq length | 0 | 3084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3085 | 26 | LCP confreq... 3086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 The LAC may have answered the phone call and negotiated LCP with the 3089 dial-in client in order to establish the client's apparent identity. 3090 In this case, this option may be included to indicate the link 3091 properties the client requested in its initial LCP CONFREQ request. 3092 The Attribute value is 26, Initial Received LCP Confreq, and is 3093 marked optional. The presence of this AVP is optional. The Value 3094 field is a copy of the body of the initial CONFREQ received, starting 3095 at the first option within this packet's body. 3097 Last Sent LCP Confreq 3099 0 1 2 3 3100 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3102 |0|0|0|0|6 + LCP confreq length | 0 | 3103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 | 27 | LCP confreq... 3105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3107 See Initial Received LCP Confreq above for rationale. The Attribute 3108 value is 27, Last Sent LCP Confreq, and is marked optional. The 3109 presence of this AVP is optional. The Value field is a copy of the 3110 body of the final CONFREQ sent to the client to complete LCP 3111 negotiation, starting at the first option within this packet's body. 3113 Last Received LCP Confreq 3115 0 1 2 3 3116 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3118 |0|0|0|0|6 + LCP confreq length | 0 | 3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3120 | 28 | LCP confreq... 3121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3123 See Initial Received LCP Confreq above for rationale. The Attribute 3124 value is 28, Last Received LCP Confreq, and is marked optional. The 3125 presence of this AVP is optional. The Value field is a copy of the 3126 body of the final CONFREQ received from the client to complete LCP 3127 negotiation, starting at the first option within this packet's body. 3129 Proxy Authen Type 3131 0 1 2 3 3132 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3134 |0|0|0|0| 8 | 0 | 3135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3136 | 29 | Type | 3137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 The Attribute value is 29, Proxy Authen Type, and is optional. This 3140 AVP MUST be present if proxy authentication is to be utilized. If it 3141 is not present, then it is assumed that this peer cannot perform 3142 proxy authentication, perhaps requiring a restart of the 3143 authentication phase at the LNS if the client has already entered 3144 this phase with the LAC. The value Type is a 16-bit word, holding a 3145 value: 3147 1 - Textual username/password exchange 3148 2 - PPP CHAP 3149 3 - PPP PAP 3150 4 - None 3152 Associated AVP's for each type of authentication follow. 3154 Proxy Authen Name 3156 0 1 2 3 3157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3159 |0|0|0|0| 6 + Name length | 0 | 3160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 | 30 | Name... 3162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3163 The Attribute value is 30, Proxy Authen Name, and is marked optional. 3164 This AVP MUST be present for Proxy Authen Type values 1, 2, and 3. 3165 The Name field contains the name specified in the client's 3166 authentication response. Note that the AVP H bit may be desirable 3167 for obscuring the cleartext name. 3169 Proxy Authen Challenge 3171 0 1 2 3 3172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3174 |0|0|0|0| 6 + Challenge length | 0 | 3175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3176 | 31 | Challenge... 3177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3179 The Attribute value is 31, Proxy Authen Challenge, and is marked 3180 optional. The AVP itself MUST be present for Proxy authen type 2. 3181 The Challenge field contains the value presented to the client by the 3182 LAC. 3184 Proxy Authen ID 3186 0 1 2 3 3187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 |0|0|0|0| 8 | 0 | 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3191 | 32 | ID | 3192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3194 The Attribute value is 32, Proxy Authen ID, and is marked optional. 3195 The AVP itself MUST be present for Proxy authen types 2 and 3. For 3196 CHAP, the ID field contains the byte ID value presented to the client 3197 by the LAC in its Challenge. For PAP, it is the Identifier value of 3198 the Authenticate-Request. The most significant 8 bits of ID MUST be 3199 0, and are reserved. 3201 Proxy Authen Response 3203 0 1 2 3 3204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3206 |1|0|0|0| 6 + Response length | 0 | 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 | 33 | Response... 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3211 The Attribute value is 33, Proxy Authen Response, and is marked 3212 mandatory. The AVP itself MUST be present for Proxy authen types 1, 3213 2, and 3. The Response field contains the client's response to the 3214 challenge. For Proxy authen type 2, this field contains the response 3215 value received by the LAC. For types 1 or 3, it contains the clear 3216 text password received from the client by the LAC. In the case of 3217 cleartext passwords, use of the AVP H bit is recommended. 3219 Private Group ID 3221 0 1 2 3 3222 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3224 |0|0|0|0| 6 + Private Group ID | 0 | 3225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3226 | 37 | Private Group ID ... 3227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 PrivateGroup ID AVP is used by the LAC to indicate that this call is 3230 to be associated with a particular customer group. The Attribute is 3231 37, Private Group ID, and is marked optional. The presence of this 3232 AVP is optional. The LNS MAY treat the PPP session as well as 3233 network traffic through this session specially in a manner determined 3234 by the peer. For example, if the LNS is individually connected to 3235 several private networks using unregistered addresses, this AVP may 3236 be included by the LAC to indicate that a given call should be 3237 associated with one of the private networks. 3239 The Private Group ID is a string corresponding to a table in the LNS 3240 that defines the particular characteristics of the selected group. A 3241 LAC MAY determine the Private Group ID from a RADIUS response 3242 containing the PrivateGroupID attribute. 3244 Rx Connect Speed 3246 0 1 2 3 3247 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 |0|0|0|0| 10 | 0 | 3250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3251 | 38 | BPS (H) | 3252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3253 | BPS (L) | 3254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3256 Rx Connect Speed BPS AVP encodes the receive speed of the facility 3257 chosen for the connection attempt. The Attribute value is 38, 3258 indicating Rx Connect Speed, and is marked optional. The Rx Connect 3259 Speed represents the speed of the connection from the perspective of 3260 the LAC (e.g. data flowing from the client to the LAC). Presence of 3261 this AVP implies that the connection speed may be asymmetric, with 3262 the transmit connect speed given in the (Tx) Connect Speed AVP. The 3263 BPS is a 32-bit value indicating the speed in bits/second. 3265 6.12 Call-Disconnect-Notify (CDN) 3267 The Call-Disconnect-Notify message is an L2TP control message sent to 3268 request disconnection of a specific call within the tunnel. Its 3269 purpose is to inform the peer of the disconnection and the reason why 3270 the disconnection occurred. The peer MUST clean up any resources, 3271 and does not send back any indication of success or failure for such 3272 cleanup. 3274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3275 | L2TP Control Message Header | 3276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3277 | Call-Disconnect-Notify | 3278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3279 | Result Code | 3280 | Q.931 Cause Code | 3281 | Assigned Call ID | 3282 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3284 Call-Disconnect-Notify 3286 0 1 2 3 3287 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3289 |1|0|0|0| 8 | 0 | 3290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3291 | 0 | 14 | 3292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3294 The Message Type AVP contains a Value of 14, indicating Call- 3295 Disconnect-Notify. The Call-Disconnect-Notify message encodes a 3296 disconnect indication for a specific call within the tunnel. The 3297 flags indicate a mandatory option. 3299 Result Code 3301 0 1 2 3 3302 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3304 |1|0|0|0| 10 + Message length | 0 | 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 | 1 | Result Code | 3307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3308 | Error Code | Optional Message ... 3309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3311 The Result Code AVP within a Call-Disconnect-Notify message 3312 indicates the reason for the call disconnect. It is encoded as 3313 Attribute 1, indicating a Result Code AVP. This AVP is mandatory 3314 and MUST be present. The Result Code is a 16-bit word. The 16- 3315 bit word following the Result Code field contains the Error Code 3316 value. The Result Code value indicates whether the Error Code 3317 value is meaningful or not. If Error Code is not meaningful it 3318 MUST be set to 0. An optional error message can follow the Error 3319 Code field; its presence and length is indicated by the value of 3320 the AVP length field. Defined Result Code values are: 3322 1 - Call disconnected due to loss of carrier 3323 2 - Call disconnected for the reason indicated in Error Code. 3324 3 - Call disconnected for administrative reasons 3325 4 - Call failed due to no appropriate facilities being 3326 available (temporary condition) 3327 5 - Call failed due to no appropriate facilities being 3328 available (permanent condition) 3329 6 - Invalid destination 3330 7 - Call failed due to no carrier detected 3331 8 - Call failed due to detection of a busy signal 3332 9 - Call failed due to lack of a dial tone 3333 10 - Call was not established within time allotted by LAC 3334 11 - Call was connected but no appropriate framing was detected 3336 Q.931 Cause Code 3338 0 1 2 3 3339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 |0|0|0|0|9 + Advisory Msg length| 0 | 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | 12 | Cause Code | 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | Cause Msg |Advisory Msg...| 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3348 The Q.931 Cause Code AVP is used to give additional information in 3349 case of unsolicited call disconnection. The Attribute value is 3350 12, Cause Code, and is marked mandatory. The presence of this AVP 3351 is optional. The Cause Code AVP is used to give additional 3352 information about the reason for disconnecting. It is only 3353 relevant when the LAC is using Q.931/DSS1 for the call. This AVP 3354 is optional. Cause Code is the returned Q.931 Cause code and 3355 Cause Msg is the returned Q.931 message code (e.g., DISCONNECT) 3356 associated with the Cause Code. Both values are returned in their 3357 native ITU encodings. An additional Ascii text Advisory Message 3358 may also be included (presence indicated by the AVP length) to 3359 further explain the reason for disconnecting. 3361 Assigned Call ID 3363 0 1 2 3 3364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3366 |1|0|0|0| 8 | 0 | 3367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3368 | 14 | Call ID | 3369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3371 The Assigned Call ID which was provided to the LNS from this LAC 3372 is included in the Call-Disconnect-Notify message. This permits a 3373 connection to be terminated even before the LNS has provided its 3374 own Assigned Call ID to this LAC (the Call ID field in the control 3375 message header is 0). The Attribute value is 14, Assigned Call 3376 ID, and is marked mandatory. This AVP MUST be present. 3378 6.13 WAN-Error-Notify (WEN) 3379 The WAN-Error-Notify message is an L2TP control message sent by the 3380 LAC to the LNS to indicate WAN error conditions (conditions that 3381 occur on the interface supporting PPP). The counters in this message 3382 are cumulative. This message should only be sent when an error 3383 occurs, and not more than once every 60 seconds. The counters are 3384 reset when a new call is established. 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3387 | L2TP Control Message Header | 3388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3389 | WAN-Error-Notify | 3390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3391 | Call Errors | 3392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3394 WAN-Error-Notify 3396 0 1 2 3 3397 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3399 |1|0|0|0| 8 | 0 | 3400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3401 | 0 | 15 | 3402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3404 The Message Type AVP contains a Value of 15, indicating WAN-Error- 3405 Notify. The WAN-Error-Notify message encodes information about line 3406 and other errors detected on the LAC's physical interface to the 3407 client. This message is sent by the LAC to the LNS. The flags 3408 indicate a mandatory option. 3410 Call Errors 3412 0 1 2 3 3413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3415 |1|0|0|0| 32 | 0 | 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3417 | 34 | Reserved | 3418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3419 | CRC Errors | 3420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3421 | Framing Errors | 3422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3423 | Hardware Overruns | 3424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3425 | Buffer Overruns | 3426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3427 | Time-out Errors | 3428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3429 | Alignment Errors | 3430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3432 The Call Errors AVP is used by the LAC to send error information to 3433 the LNS. The Attribute value is 34, WAN-Error-Notify, and is marked 3434 mandatory. This AVP MUST be present. The value contains the 3435 following fields: 3437 Reserved - Not used, MUST be 0 3438 CRC Errors - Number of PPP frames received with CRC errors since 3439 session was established 3440 Framing Errors - Number of improperly framed PPP packets received 3441 Hardware Overruns - Number of receive buffer over-runs since 3442 session was established 3443 Buffer Overruns - Number of buffer over-runs detected since 3444 session was established 3445 Time-out Errors - Number of time-outs since call was established 3446 Alignment Errors - Number of alignment errors since call was 3447 established 3449 6.14 Set-Link-Info (SLI) 3451 The Set-Link-Info message is an L2TP control message sent by the LNS 3452 to the LAC to set PPP-negotiated options. Because these options can 3453 change at any time during the life of the call, the LAC MUST be able 3454 to update its internal call information dynamically and update its 3455 behavior on an active PPP session. 3457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3458 | L2TP Control Message Header | 3459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3460 | Set-Link-Info | 3461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3462 | ACCM | 3463 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3465 Set-Link-Info 3467 0 1 2 3 3468 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3470 |1|0|0|0| 8 | 0 | 3471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3472 | 0 | 16 | 3473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3475 The Message Type AVP contains a Value of 16, indicating Set-Link- 3476 Info. The Set-Link-Info message encodes ACCM information sent from 3477 the LNS to the LAC after it is negotiated in LCP. The flags indicate 3478 a mandatory option. 3480 ACCM 3482 0 1 2 3 3483 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3485 |1|0|0|0| 32 | 0 | 3486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3487 | 35 | Reserved | 3488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3489 | Send ACCM | 3490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3491 | Receive ACCM | 3492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3494 The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. 3495 The Attribute value is 35, ACCM, and is marked mandatory. This 3496 attribute MUST be present. The value contains Send ACCM and Receive 3497 ACCM fields. The send ACCM value should be used by the LAC to 3498 process packets it is sends on the connection. The receive ACCM 3499 value should be used by the LAC to process incoming packets on the 3500 connection. The default values used by the LAC for both these fields 3501 are 0xFFFFFFFF. The LAC should honor these fields unless it has 3502 specific configuration information to indicate that the requested 3503 mask must be modified to permit operation. 3505 7.0 Control Connection State Machines 3507 The control messages defined in section 6 are exchanged by way of state 3508 tables defined in this section. Tables are defined for incoming call 3509 placement, outgoing call placement, as well as for initiation of the 3510 tunnel itself. The state tables do not encode timeout and 3511 retransmission behavior, as this is handled in the underlying semantics 3512 defined in 6.0.2. 3514 7.1 Control Connection Protocol Operation 3516 This section describes the operation of various L2TP control 3517 connection functions and the Control Connection messages which are 3518 used to support them. 3520 Receipt of an invalid or malformed Control Connection message should 3521 be logged appropriately, and the control connection should be closed 3522 and restarted to ensure recovery into a known state. 3524 In several cases in the following tables, a protocol message is sent, 3525 and then a "clean up" occurs. Note that regardless of the initiator 3526 of the tunnel destruction, the reliable delivery mechanism must be 3527 allowed to run (see 6.0.2) before destroying the tunnel. This 3528 permits the tunnel management messages to be reliably delivered to 3529 the peer. 3531 7.2 Control Connection States 3533 Control messages are carried over the same media as the payload 3534 messages which are carried following successful connection 3535 establishment. The L2TP control connection protocol is not 3536 distinguishable between the LNS and LAC, but is distinguishable 3537 between the originator and receiver. The originating peer is the one 3538 which first establishes the tunnel. Since either LAC or LNS can be 3539 the originator, a collision can occur. See Section 6.0.1 for a 3540 description of this and its resolution. 3542 7.2.1 Control Connection Establishment 3544 State Event Action New State 3545 ----- ----- ------ --------- 3546 idle Local Send SCCRQ wait-ctl-reply 3547 Open request 3549 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3550 acceptable 3552 idle Receive SCCRQ, Send StopCCN, idle 3553 not acceptable Clean up 3555 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3556 acceptable Send tunnel-open 3557 event to waiting 3558 sessions 3560 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3561 not acceptable Clean up 3563 wait-ctl-reply Receive SCCRQ, Clean up, idle 3564 lose tie-breaker Re-queue SCCRQ 3565 for idle state 3567 wait-ctl-conn Receive SCCCN, Send tunnel-open established 3568 acceptable event to waiting 3569 sessions 3571 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3572 not acceptable Clean up 3574 established Local Send tunnel-open established 3575 Open request event to waiting 3576 (new client) sessions 3578 established Admin Send StopCCN idle 3579 Tunnel Close Clean up 3581 wait-ctl-reply, 3582 wait-ctl-conn, 3583 established Receive StopCCN Clean up idle 3585 idle 3586 Both initiator and recipient start from this state. An initiator 3587 transmits a SCCRQ, while a recipient remains in the idle state 3588 until receiving a SCCRQ. 3590 wait-ctl-reply 3591 The originator checks to see if another connection has been 3592 requested from the same peer, and if so, handles the collision 3593 situation described in Section 6.0.1. 3595 When a SCCRP is received, it is examined for a compatible version. 3596 If the version of the reply is lower than the version sent in the 3597 request, the older (lower) version should be used provided it is 3598 supported. If the version in the reply is earlier and supported, 3599 the originator moves to the established state. If the version is 3600 earlier and not supported, a StopCCN MUST be sent to the peer and 3601 the originator cleans up and terminates the tunnel. 3603 wait-ctl-conn 3604 This is where an SCCCN is awaited; upon receipt, protocol version 3605 compatibility is checked. The tunnel is either established, or is 3606 torn down if a protocol mismatch is detected. 3608 established 3609 An established connection may be terminated by either a local 3610 condition or the receipt of a Stop-Control-Connection- 3611 Notification. In the event of a local termination, the originator 3612 MUST send a Stop-Control-Connection-Notification and clean up the 3613 tunnel. 3615 If the originator receives a Stop-Control-Connection-Notification 3616 it MUST also clean up the tunnel. 3618 7.3 Timing considerations 3620 Because of the real-time nature of telephone signaling, both the LNS 3621 and LAC should be implemented with multi-threaded architectures such 3622 that messages related to multiple calls are not serialized and 3623 blocked. The call and connection state figures do not specify 3624 exceptions caused by timers. These are addressed in Section 6.0.2. 3626 7.4 Incoming calls 3628 An Incoming-Call-Request message is generated by the LAC when an 3629 associated telephone line rings. The LAC selects a Call ID and 3630 serial number and indicates the call bearer type. Modems should 3631 always indicate analog call type. ISDN calls should indicate digital 3632 when unrestricted digital service or rate adaption is used and analog 3633 if digital modems are involved. CLID, DNIS, and subaddress may be 3634 included in the message if they are available from the telephone 3635 network. 3637 Once the LAC sends the Incoming-Call-Request, it waits for a response 3638 from the LNS but it does not necessarily answer the call from the 3639 telephone network yet. The LNS may choose not to accept the call if: 3641 - No resources are available to handle more sessions 3642 - The dialed, dialing, or subaddress fields do not correspond to 3643 an authorized user 3644 - The bearer service is not authorized or supported 3646 If the LNS chooses to accept the call, it responds with an Incoming- 3647 Call-Reply which may also indicate window sizes (see Appendix B). 3648 When the LAC receives the Incoming-Call-Reply, it attempts to connect 3649 the call. A final call connected message from the LAC to the LNS 3650 indicates that the call states for both the LAC and the LNS should 3651 enter the established state. If the call terminated before the LNS 3652 could accept it, a Call-Disconnect-Notify is sent by the LAC to 3653 indicate this condition. 3655 When the dialed-in client hangs up, the call is cleared normally and 3656 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 3657 clear a call, it sends a Call-Disconnect-Notify message and cleans up 3658 its session. 3660 7.4.1 LAC Incoming Call States 3662 State Event Action New State 3663 ----- ----- ------ --------- 3664 idle Bearer Ring or Initiate local wait-tunnel 3665 Ready to indicate tunnel open 3666 incoming conn. 3668 wait-tunnel tunnel-open Send ICRQ wait-reply 3670 wait-reply Receive ICRP, Answer call, established 3671 acceptable Send ICCN 3673 wait-reply Receive ICRP, Send CDN, idle 3674 not acceptable Clean up 3676 wait-reply Receive CDN Clean up idle 3678 wait-reply Local Send CDN, idle 3679 Close request Clean up 3681 established Receive CDN Hang up bearer, idle 3682 Clean up 3684 established Local Hang up bearer, idle 3685 Close request Send CDN, 3686 Clean up 3688 established Bearer Send CDN, idle 3689 Line drop Clean up 3691 The states associated with the LAC for incoming calls are: 3693 idle 3694 The LAC detects an incoming call on one of its interfaces. Typically 3695 this means an analog line is ringing or an ISDN TE has detected an 3696 incoming Q.931 SETUP message. The LAC initiates its tunnel 3697 establishment state machine, and moves to a state waiting for 3698 confirmation of the existence of a tunnel. 3700 wait-tunnel 3701 In this state the session is waiting for either the control tunnel to 3702 be opened or for verification that the tunnel is already open. Once 3703 an indication that the tunnel has/was opened, session control 3704 messages may be exchanged. The first of these is the Incoming-Call- 3705 Request. 3707 wait-reply 3708 The LAC receives an Incoming-Call-Reply message indicating non- 3709 willingness to accept the call (general error or don't accept) and 3710 moves back into the idle state. If the reply message indicates that 3711 the call is accepted, the LAC sends an Incoming-Call-Connected 3712 message and enters the established state. 3714 established 3715 Data is exchanged over the tunnel. The call may be cleared 3716 following: 3717 An event on the connected interface. The LAC sends a Call- 3718 Disconnect-Notify message 3719 Receipt of a Call-disconnect-Notify message. The LAC cleans up, 3720 disconnecting the call. 3721 A local reason. The LAC sends a Call-Disconnect-Notify message. 3723 7.4.2 LNS Incoming Call States 3725 State Event Action New State 3726 ----- ----- ------ --------- 3727 idle Receive ICRQ, Send ICRP wait-connect 3728 acceptable 3730 idle Receive ICRQ, Send CDN, idle 3731 not acceptable Clean up 3733 wait-connect Receive ICCN Prepare for established 3734 acceptable data 3736 wait-connect Receive ICCN Send CDN, idle 3737 not acceptable Clean up 3739 wait-connect, 3740 established Receive CDN Clean up idle 3742 established Local Send CDN, idle 3743 Close request Clean up 3745 The states associated with the LNS for incoming calls are: 3747 idle 3748 An Incoming-Call-Request message is received. If the request is 3749 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 3750 and the LNS remains in the idle state. If the Incoming-Call- 3751 Request message is acceptable, an Incoming-Call-Reply is sent. 3752 The session moves to the wait-connect state. 3754 wait-connect 3755 If the session is still connected on the LAC, the LAC sends an 3756 Incoming-Call-Connected message to the LNS which then moves into 3757 established state. The LAC may send a Call-Disconnect-Notify to 3758 indicate that the incoming caller could not be connected. This 3759 could happen, for example, if a telephone user accidentally places 3760 a standard voice call to an LAC resulting in a handshake failure 3761 on the called modem. 3763 established 3764 The session is terminated either by receipt of a Call-Disconnect- 3765 Notify message from the LAC or by sending a Call-Disconnect- 3766 Notify. Clean up follows on both sides regardless of the 3767 initiator. 3769 7.5 Outgoing calls 3771 Outgoing calls are initiated by an LNS and instruct an LAC to place a 3772 call. There are three messages for outgoing calls: Outgoing-Call- 3773 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 3774 sends an Outgoing-Call-Request specifying the dialed party phone 3775 number and subaddress as well as speed and window parameters. The 3776 LAC MUST respond to the Outgoing-Call-Request message with an 3777 Outgoing-Call-Reply message once the LAC determines that the proper 3778 facilities exist to place the call and the call is administratively 3779 authorized. For example, is this LNS allowed to dial an 3780 international call? Once the outbound call is connected the LAC 3781 sends an Outgoing-Call-Connected message to the LNS indicating the 3782 final result of the call attempt: 3784 7.5.1 LAC Outgoing Call States 3786 State Event Action New State 3787 ----- ----- ------ --------- 3788 idle Receive OCRQ, Send OCRP, wait-cs-answer 3789 acceptable Open bearer 3791 idle Receive OCRQ, Send CDN, idle 3792 not acceptable Clean up 3794 wait-cs-answer Bearer answer, Send OCCN established 3795 framing detected 3797 wait-cs-answer Bearer failure Send CDN, idle 3798 Clean up 3800 wait-cs-answer, 3801 established Receive CDN Hang up bearer, idle 3802 Clean up 3804 The states associated with the LAC for outgoing calls are: 3806 idle 3807 Received Outgoing-Call-Request. If this is received in error, 3808 respond with a Call-Disconnect-Notify. Otherwise, allocate a 3809 physical channel and send an Outgoing-Call-Reply. Place the 3810 outbound call and move to the wait-cs-answer state. 3812 wait-cs-answer 3813 If the call is not completed or a timer expires waiting for the 3814 call to complete, send a Call-Disconnect-Notify with the 3815 appropriate error condition set and go to idle state. If a 3816 circuit switched connection is established and framing is 3817 detected, send an Outgoing-Call-Connected indicating success and 3818 go to established state. 3820 established 3821 If a Call-Disconnect-Notify is received, the telco call MUST be 3822 released via appropriate mechanisms and the session cleaned up. 3823 If the call is disconnected by the client or the called interface, 3824 a Call-Disconnect-Notify message MUST be sent to the LNS. Return 3825 to idle state after sending the Call-Disconnect-Notify. 3827 7.5.2 LNS Outgoing Call States 3829 State Event Action New State 3830 ----- ----- ------ --------- 3831 idle Local Initiate local wait-tunnel 3832 Open request tunnel-open 3834 wait-tunnel tunnel-open Send OCRQ wait-reply 3836 wait-reply Receive OCRP, none wait-connect 3837 acceptable 3839 wait-reply Receive OCRP, Send CDN idle 3840 not acceptable 3842 wait-connect Receive OCCN none established 3844 established, 3845 wait-connect Receive CDN Clean up idle 3847 wait-reply, 3848 wait-connect, 3849 established Local Send CDN idle 3850 Close request 3852 The states associated with the LNS for outgoing calls are: 3854 idle, wait-tunnel 3855 When an outgoing call is initiated, a tunnel is first created, 3856 much as the idle and wait-tunnel states for an LAC incoming call. 3857 Once a tunnel is established, an Outgoing-Call-Request message is 3858 sent to the LAC and the session moves into the wait-reply state. 3860 wait-reply 3861 If a Call-Disconnect-Notify is received, an error occurred, and 3862 the session is cleaned up and returns to idle. If an Outgoing- 3863 Call-Reply is received, the call is in progress and the session 3864 moves to the wait-connect state. 3866 wait-connect 3867 If a Call-Disconnect-Notify is received, the call failed; the 3868 session is cleaned up and returns to idle. If an Outgoing-Call- 3869 Connected is received, the call has succeeded and the session may 3870 now exchange data. 3872 established 3873 If a Call-Disconnect-Notify is received, the call has been 3874 terminated for the reason indicated in the Result and Cause Codes; 3875 the session moves back to the idle state. If the LNS chooses to 3876 terminate the session, it sends a Call-Disconnect-Notify to the 3877 LAC and then cleans up and idles its session. 3879 7.6 Tunnel Disconnection 3881 The disconnection of a tunnel consists of either peer issuing a 3882 Stop-Control-Connection-Notification. The sender of this 3883 Notification should wait a finite period of time for the 3884 acknowledgment of this message before releasing the control 3885 information associated with the tunnel. The recipient of this 3886 Notification should send an acknowledgment of the Notification and 3887 then release the associated control information. 3889 When to release a tunnel is an implementation issue and is not 3890 specified in this document. A particular implementation may use 3891 whatever policy is appropriate for determining when to release a 3892 control connection. Some implementations may leave a tunnel open for 3893 a period of time or perhaps indefinitely after the last user session 3894 for that tunnel is cleared. Others may choose to disconnect the 3895 tunnel immediately after the last user connection on the tunnel 3896 disconnects. 3898 8.0 L2TP Over Specific Media 3900 L2TP tries to be self-describing, operating at a level above the 3901 particular media over which it is carried. However, some details of 3902 its connection to media are required to permit interoperable 3903 implementations. The following sections describe details needed to 3904 permit interoperability over specific media. 3906 8.1 IP/UDP 3908 L2TP uses the well-known UDP port 1701 [3]. The entire L2TP packet, 3909 including payload and L2TP header, is sent within a UDP datagram. 3910 The initiator of an L2TP tunnel picks an available source UDP port, 3911 and sends to the desired destination at port 1701. The recipient 3912 picks a free port on its own system, and sends its reply to the 3913 initiator's UDP port, setting its own UDP source port set to the free 3914 port it found. All subsequent packets exchanged will use these UDP 3915 ports. It is legal for a peer's IP address used for a given tunnel 3916 to change over the life of a connection; this may correspond to a 3917 peer with multiple IP interfaces responding to a network topology 3918 change. Responses should reflect the last source IP address for that 3919 Tunnel ID. 3921 IP fragmentation may occur as the L2TP packet travels over the IP 3922 substrate. L2TP makes no special efforts to optimize this. A LAC 3923 implementation MAY cause its LCP to negotiate for a specific MRU, 3924 which could optimize for LAC environments in which the MTUs of the 3925 path over which the L2TP packets are likely to travel have a 3926 consistent value. 3928 The default for any L2TP implementation is that UDP checksums MUST be 3929 enabled for both control and payload messages. An L2TP 3930 implementation MAY provide an option to disable UDP checksums for 3931 payload packets. It is recommended that UDP checksums always be 3932 enabled on control packets. 3934 Port 1701 is used for both L2F [5] and L2TP packets. The two types 3935 of packets may be detected by their headers; L2TP has a Vers field of 3936 2, L2F has a 1 in this field instead. An L2TP implementation running 3937 on a system which does not support L2F MUST silently discard all 3938 packets whose Vers field is set to 1. 3940 8.2 IP 3942 When operating in IP environments, L2TP MUST offer the UDP 3943 encapsulation described in 8.1 as its default configuration for IP 3944 operation. Other configurations (perhaps corresponding to a 3945 compressed header format) may be defined, and made available as a 3946 configurable option. 3948 9.0 Security Considerations 3950 L2TP encounters several security issues in its operation. The 3951 general approach of L2TP to these issues is documented here. 3953 9.1 Tunnel Endpoint Security 3954 The tunnel endpoints may authenticate each other during tunnel 3955 establishment. This authentication has the same security 3956 attributes as CHAP, and has reasonable protection against replay 3957 and snooping. In environments where some L2TP peers will be 3958 authenticated, but others not, a mechanism should be provided to 3959 control when tunnel endpoint authentication will be active. 3961 The LAC and LNS MUST share a single secret for authentication of 3962 both ends of the tunnel. Each side uses this same secret when 3963 acting as authenticatee as well as authenticator. Since a single 3964 secret it used, the tunnel authentication AVPs include 3965 differentiating values in the CHAP ID fields for each message 3966 digest calculation to guard against replay attacks. 3968 For L2TP tunnels over IP, IP-level packet security provides very 3969 strong protection of the tunnel. This requires no modification to 3970 the L2TP protocol, and leverages extensive IETF work in this area. 3972 For L2TP tunnels over Frame Relay or other switched networks, 3973 current practice indicates that these media are much less likely 3974 to experience attacks of in-transit data. If these attacks became 3975 prevalent, either the media or the L2TP packets would have to be 3976 encrypted. 3978 Because the shared secret used for endpoint authentication is the 3979 same shared secret used to obscure AVP contents using the H 3980 (Hidden) bit, tunnel authentication must be used in all cases 3981 where the H bit will be used. Proxy authentication involving PAP 3982 may be usable without the H bit if PAP is only carrying one-time 3983 passwords; if clear text passwords are carried in the proxy 3984 authentication, the H bit (and, by implication, tunnel 3985 authentication) should be used. 3987 To protect against exhaustive attack during tunnel authentication, 3988 no tunnel authentication response should ever be accepted if it 3989 corresponds to a challenge more than one minute old. 3991 9.2 Client Security 3993 A more systematic method of protection in tunneled PPP 3994 environments may be achieved through client security. PPP layer 3995 encryption would provide end-to-end security for both direct 3996 dial-in clients as well as PPP clients carried within a tunnel. 3997 With this level of client security, sessions are protected against 3998 attacks against the carrying tunnel, as well as attacks on the LAC 3999 itself. Because both encryption and compression can occur at the 4000 PPP layer, the two can be coordinated, permitting compression to 4001 precede encryption. 4003 9.3 Proxy Authentication 4005 The optional proxy CHAP function of L2TP can permit an entirely 4006 transparent PPP tunnel, with a single LCP and CHAP sequence being 4007 seen by the client. For cases where the LAC and the entire path 4008 to the LNS are operated by a single entity, this function may 4009 provide acceptable security. For cases where LNS-initiated 4010 authentication is required, proxy CHAP still permits an initial 4011 access decision to be made before accepting the tunnel, permitting 4012 the LNS in most cases to reject tunnel initiations rather than 4013 accept them and later disconnect. 4015 The optional proxy PAP may result in the cleartext password 4016 traversing the tunnel. Where PAP is being used in conjunction 4017 with static passwords, this may pose a significant security issue. 4018 Where PAP is only used to transport one-time passwords, such 4019 issues may be greatly mitigated. The H bit of the carrying AVP 4020 may be used to protect against this. 4022 All implementations MUST accept proxy authentication AVP's, but 4023 are free to silently discard them and initiate an entirely new 4024 authentication with the PPP client. 4026 10.0 Acknowledgments 4028 The AVP construct comes from Glen Zorn, who thought up the framework 4029 for permitting multiple vendors to contribute to a common attribute 4030 space in a relatively orderly fashion. 4032 Dory Leifer of Ascend Communications made valuable refinements to the 4033 protocol definition of L2TP and contributed to the editing of this 4034 document. 4036 Steve Cobb and Evan Caves redesigned the state machine tables. 4038 Barney Wolff provided a great deal of design input on the endpoint 4039 authentication mechanism. 4041 11.0 Contacts 4043 Kory Hamzeh, Allan Rubens 4044 Ascend Communications 4045 1275 Harbor Bay Parkway 4046 Alameda, CA 94502 4047 kory@ascend.com 4048 acr@del.com 4050 Tim Kolar, Morgan Littlewood, Bill Palter, Andrew J. Valencia 4051 Cisco Systems 4052 170 West Tasman Drive 4053 San Jose CA 95134-1706 4054 tkolar@cisco.com 4055 littlewo@cisco.com 4056 palter@cisco.com 4057 vandys@cisco.com 4059 Gurdeep Singh Pall 4060 Microsoft Corporation 4061 Redmond, WA 4062 gurdeep@microsoft.com 4064 Jeff Taarud 4065 Copper Mountain Networks 4066 jtaarud@coppermountain.com 4068 W. Mark Townsley 4069 IBM Corporation 4070 700 Park Office Dr. 4071 Raleigh, NC 27709 4072 wmt@raleigh.ibm.com 4074 William Verthein 4075 3COM Corporation 4076 wverthei@usr.com 4078 12.0 References 4080 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 4081 07/21/1994 4083 [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet 4084 draft, April 1996 4086 [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point 4087 Tunneling Protocol", Internet draft, June 1996 4089 [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC1034, 4090 November 1987 4092 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, 4093 USC/Information Sciences Institute, July 1992. 4095 [6] Sally Floyd, Van Jacobson, "Random Early Detection Gateways for 4096 Congestion Avoidance", IEEE/ACM Transactions on Networking, 4097 August 1993 4099 [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, 4100 October 1996 4102 [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authentication 4103 Dial In User Service (RADIUS)." draft-ietf-radius-radius-05.txt, 4104 Livingston, Merit, Daydreamer, July 1996. 4106 [9] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, RFC 1990, 4107 "The PPP Multilink Protocol (MP)", August 1996. 4109 Appendix A: Acknowledgment Timeouts 4111 L2TP uses sliding windows and timeouts to provide session and control 4112 flow-control across the underlying medium (which may be an 4113 internetwork) and to perform efficient data buffering to keep the 4114 LAC-LNS data channels full without causing receive buffer overflow. 4116 L2TP requires that a timeout be used to recover from dropped data or 4117 acknowledgment packets for both control and data messages. The only 4118 real difference between the flow-control mechanism used for the two 4119 message types is that control messages are retransmitted upon 4120 expiration of the acknowledgment timeout in order to assure reliable 4121 transport while payload messages are never retransmitted. Because 4122 payload messages are not retransmitted, the action taken upon 4123 expiration of the acknowledgment timeout for each message type also 4124 differs. 4126 When the timeout for a control session expires the previously 4127 transmitted control message with Ns value equal to the highest in- 4128 sequence value of Nr received from the peer is retransmitted. The 4129 receiving peer does not advance its value for the receive sequence 4130 number state, Sr, for either a control session or payload session 4131 until it receives a message with Ns equal to its current value of Sr 4132 (except for the simple receiver described in Appendix C and payload 4133 packets with the R-bit set). This rule assures that all subsequent 4134 acknowledgments for this session will contain an Nr value equal to 4135 the Ns value of the first missing message until a message with the 4136 missing Ns value is received. This rule also assures that when a 4137 payload message is lost anywhere within the current transmit window, 4138 the payload session acknowledgment timeout will expire, allowing the 4139 transmitter to adjust transmission parameters such as those suggested 4140 in this appendix. 4142 According to the above rule for updating of the receiving peer's Sr 4143 value, the loss of a transmitted payload message (due to non- 4144 retransmission of payload messages) will cause Sr to remain at the 4145 value of the first lost payload message. In order to cause the 4146 receiving peer to advance its value of Sr beyond that of a lost 4147 message's Ns value, upon expiration of a payload session 4148 acknowledgment timeout, the sending peer MUST transmit a payload 4149 message with R-bit set and Ns value greater than or equal to Ns of 4150 the lost message. Refer to Section 4 for more details on the use of 4151 the R-bit. 4153 The exact implementation of the acknowledgment timeout is vendor- 4154 specific. It is suggested that an adaptive timeout be implemented 4155 with backoff for congestion control. The timeout mechanism proposed 4156 here has the following properties: 4158 Independent timeouts for each session. A device (LAC or LNS) will 4159 have to maintain and calculate timeouts for every active session. 4161 An administrator-adjustable maximum timeout, MaxTimeOut, unique to 4162 each device. 4164 An adaptive timeout mechanism that compensates for changing 4165 throughput. To reduce packet processing overhead, vendors may 4166 choose not to recompute the adaptive timeout for every received 4167 acknowledgment. The result of this overhead reduction is that the 4168 timeout will not respond as quickly to rapid network changes. 4170 Timer backoff on timeout to reduce congestion. The backed-off 4171 timer value is limited by the configurable maximum timeout value. 4172 Timer backoff is done every time an acknowledgment timeout occurs. 4174 In general, this mechanism has the desirable behavior of quickly 4175 backing off upon a timeout and of slowly decreasing the timeout value 4176 as packets are delivered without timeouts. 4178 Some definitions: 4180 Packet Processing Delay, "PPD", is the amount of time required for 4181 each peer to process the maximum amount of data buffered in its 4182 offered receive packet window. The PPD is the value exchanged 4183 between the LAC and LNS when a call is established. For the LNS, 4184 this number should be small. For an LAC supporting modem 4185 connections, this number could be significant. 4187 "Sample" is the actual amount of time incurred receiving an 4188 acknowledgment for a packet. The Sample is measured, not 4189 calculated. 4191 Round-Trip Time, "RTT", is the estimated round-trip time for an 4192 Acknowledgment to be received for a given transmitted packet. 4193 When the network link is a local network, this delay will be 4194 minimal (if not zero). When the network link is the Internet, 4195 this delay could be substantial and vary widely. RTT is adaptive: 4196 it will adjust to include the PPD and whatever shifting network 4197 delays contribute to the time between a packet being transmitted 4198 and receiving its acknowledgment. 4200 Adaptive Timeout, "ATO", is the time that must elapse before an 4201 acknowledgment is considered lost. After a timeout, the sliding 4202 window is partially closed and the ATO is backed off. 4204 Packet Processing Delay (PPD) 4206 The PPD parameter is a 16-bit time value exchanged during the Call 4207 Control phase expressed in units of tenths of a second (64 means 6.4 4208 seconds). The protocol only specifies that the parameter is 4209 exchanged, it does not specify how it is calculated. The way values 4210 for ATO are calculated is implementation-dependent and need not be 4211 variable (static timeouts are allowed). IF adaptive timeouts are to 4212 be used then the PPD should be exchanged in the call connect 4213 sequences. A possible way to calculate the PPD is: 4215 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 4216 + LACFudge (for an LAC) 4217 or 4218 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4219 + LNSFudge (for an LNS) 4221 Header is the total size of the L2TP and media dependent headers. 4222 MTU is the overall MTU for the link between the LAC and LNS. 4223 WindowSize represents the number of packets in the sliding window, 4224 and is implementation-dependent. The latency of the underlying 4225 connection path between the LAC and LNS could be used to pick a 4226 window size sufficient to keep the current session's pipe full. The 4227 constant 8 converts octets to bits (assuming ConnectRate is in bits 4228 per second). If ConnectRate is in bytes per second, omit the 8. 4229 LACFudge and LNSFudge are not required but can be used to take 4230 overall processing overhead of the LAC or LNS into account. 4232 In the case of the computed PPD for an LNS, AvePathRate is the 4233 average bit rate of the path between the LNS and LAC. Given that 4234 this number is probably very large and WindowSize is relatively 4235 small, LNSFudge will be the dominant factor in the computation of 4236 PPD. It is recommended that the minimum value of PPD be on the order 4237 of 0.5 second. 4239 The value of PPD is used to seed the adaptive algorithm with the 4240 initial RTT[n-1] value. 4242 A.1 Calculating Adaptive Acknowledgment Timeout 4244 We still must decide how much time to allow for acknowledgments to 4245 return. If the timeout is set too high, we may wait an unnecessarily 4246 long time for dropped packets. If the timeout is too short, we may 4247 time out just before the acknowledgment arrives. The acknowledgment 4248 timeout should also be reasonable and responsive to changing network 4249 conditions. 4251 The suggested adaptive algorithm detailed below is based on the TCP 4252 1989 implementation and is explained in Richard Steven's book TCP/IP 4253 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 4254 calculation, and 'n-1' refers to values from the last calculation. 4256 DIFF[n] = SAMPLE[n] - RTT[n-1] 4257 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 4258 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 4259 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 4261 DIFF represents the error between the last estimated round-trip 4262 time and the measured time. DIFF is calculated on each iteration. 4264 DEV is the estimated mean deviation. This approximates the 4265 standard deviation. DEV is calculated on each iteration and 4266 stored for use in the next iteration. Initially, it is set to 0. 4268 RTT is the estimated round-trip time of an average packet. RTT is 4269 calculated on each iteration and stored for use in the next 4270 iteration. Initially, it is set to PPD. 4272 ATO is the adaptive timeout for the next transmitted packet. ATO 4273 is calculated on each iteration. Its value is limited, by the MIN 4274 function, to be a maximum of the configured MaxTimeOut value. 4276 Alpha is the gain for the average and is typically 1/8 (0.125). 4278 Beta is the gain for the deviation and is typically 1/4 (0.250). 4280 Chi is the gain for the timeout and is typically set to 4. 4282 To eliminate division operations for fractional gain elements, the 4283 entire set of equations can be scaled. With the suggested gain 4284 constants, they should be scaled by 8 to eliminate all division. To 4285 simplify calculations, all gain values are kept to powers of two so 4286 that shift operations can be used in place of multiplication or 4287 division. The above calculations are carried out each time an 4288 acknowledgment is received for a packet that was not retransmitted 4289 (no timeout occurs). 4291 A.2 Congestion Control: Adjusting for Timeout 4293 This section describes how the calculation of ATO is modified in the 4294 case where a timeout does occur. When a timeout occurs, the timeout 4295 value should be adjusted rapidly upward. Although L2TP payload 4296 packets are not retransmitted when a timeout occurs, the timeout 4297 should be adjusted up toward a maximum limit. To compensate for 4298 shifting internetwork time delays, a strategy must be employed to 4299 increase the timeout when it expires. A simple formula called Karn's 4300 Algorithm is used in TCP implementations and may be used in 4301 implementing the backoff timers for the LNS or the LAC. Notice that 4302 in addition to increasing the timeout, we also shrink the size of the 4303 window as described in the next section. 4305 Karn's timer backoff algorithm, as used in TCP, is: 4307 NewTIMEOUT = delta * TIMEOUT 4309 Adapted to our timeout calculations, for an interval in which a 4310 timeout occurs, the new timeout interval ATO is calculated as: 4312 RTT[n] = delta * RTT[n-1] 4313 DEV[n] = DEV[n-1] 4314 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 4316 In this modified calculation of ATO, only the two values that 4317 contribute to ATO and that are stored for the next iteration are 4318 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 4319 not carried forward and is not used in this scenario. A value of 2 4320 for Delta, the timeout gain factor for RTT, is suggested. 4322 Appendix B: Acknowledgment Timeout and Window Adjustment 4324 B.1 Initial Window Size 4326 Although each side has indicated the maximum size of its receive 4327 window, it is recommended that a slow start method be used to begin 4328 transmitting data. The initial maximum window size on the 4329 transmitter is set to half the maximum size the receiver requested, 4330 with a minimum size of one packet. The transmitter stops sending 4331 packets when the number of packets awaiting acknowledgment is equal 4332 to the current maximum window size. As the receiver successfully 4333 digests each window, the maximum window size on the transmitter is 4334 bumped up by one packet until the maximum specified by the receiver 4335 is reached. This method prevents a system from flooding an already 4336 congested network because no history has been established. 4338 When for any reason an LAC or LNS receives more data than it can 4339 queue for the tunnel, a packet must be discarded. In this case, it 4340 is recommended that a "random early discard" algorithm [6] be used 4341 rather than the obvious "drop last" algorithm. 4343 B.2 Closing the Window 4345 When a timeout does occur on a packet, the sender adjusts the size of 4346 the transmit window down to one half its maximum value when it 4347 failed. Fractions are rounded up, and the minimum window size is 4348 one. 4350 B.3 Opening the Window 4352 With every successful transmission of a window's worth of packets 4353 without a timeout, the maximum transmit window size is increased by 4354 one packet until it reaches the maximum window size that was sent by 4355 its peer when the call was connected. As stated earlier, no 4356 retransmission is done on a timeout. After a timeout, transmission 4357 resumes with the maximum transmit window starting at one half the 4358 size of the maximum transmit window when the timeout occurred (with a 4359 minimum window size of 1) and adjusting upward by one each time the 4360 current maximum transmit window is filled with packets that are all 4361 acknowledged without timeouts. 4363 B.4 Window Overflow 4365 When a receiver's window overflows with too many incoming packets, 4366 excess packets are thrown away. This situation should not arise if 4367 the sliding window procedures are being properly followed by the 4368 transmitter and receiver. It is assumed that, on the transmit side, 4369 packets are buffered for transmission and are no longer accepted from 4370 the packet source when the transmit buffer fills. 4372 Appendix C: Handling of out-of-order packets 4374 When the Sequence Number and Acknowledgment Number fields are present 4375 in payload packets, they are used to manage packet rate. In 4376 addition, they may be used to handle out-of-order arrival of packets. 4377 A simple L2TP receiver may choose to skip the test for the Ns value 4378 of a received message being equal to Sr, simply updating Sr if Ns is 4379 greater than the current value of Sr. For example, if packets 1, 2, 4380 3 arrived as 1, 3, 2, this simple implementation would silently 4381 discard packet 2 without informing the sender in any way that packet 4382 2 was discarded. Even though packet 2 is dropped by the receiver, the 4383 transmitter will perceive all transmitted packets as being received 4384 without loss by its peer. 4386 Such behavior does not affect the L2TP protocol itself, but 4387 significantly improved throughput in such environments may be 4388 attained by queueing and reordering packets when they arrive out of 4389 order. The number of packets to be queued is a function of memory 4390 resources on the L2TP implementation, but should never be more than 4391 1/4 of the total sequence number space (i.e., 16384 packets), to 4392 avoid aliasing. 4394 It is suggested that receiving peer implementations implement the Sr 4395 state variable for payload sessions and that they update Sr only when 4396 receiving the next in-sequence Ns value or when receiving a message 4397 with the R-bit set. Doing so allows a mechanism for reporting of lost 4398 payload messages to the transmitter, which is necessary for the 4399 transmitter to implement algorithms such as those suggested in 4400 Appendix A and B. 4402 Note that while payload messages received out-of-order may either be 4403 queued, discarded, or delivered out-of-order, queueing is preferred. 4404 PPP does not expect to receive packets out-of-order so, if queueing 4405 is not provided by a receiver, it is preferable for it to discard 4406 out-of-order packets rather than deliver them to PPP. 4408 Appendix D: Transport Layer Adaptive Timeouts and Window Adjustment 4410 Appendixes A, B, and C deal primarily with operation of the payload 4411 packet sessions of L2TP. This Appendix explains how these three 4412 algorithms pertain to the transport layer for L2TP control sessions. 4413 Appendix B, Time-out Window Management, directly applies to the 4414 Transport Layer except in the case where a window size of 1 is being 4415 used. Appendix C, does not really apply because, for the Control 4416 Session, control messages MUST always be processed by the receiver in 4417 order. Also, there are no lost control packets because they are 4418 retransmitted by the L2TP Transport Layer. Thus, the main topic of 4419 this Appendix is how to adapt the example adaptive timeout algorithm 4420 of Appendix A to the Control Session Transport Layer. 4422 There are two main differences between the Control Session and 4423 payload sessions: 1) Unlike lost payload packets, lost control 4424 messages are retransmitted and 2) There is no Packet Processing Delay 4425 value provided in the control session setup messages. The latter 4426 affects the manner in which the initial value of the RTT estimate is 4427 determined. The former really doesn't affect the algorithm at all, 4428 except that upon a timeout, retransmission of unacknowledged control 4429 messages should be attempted, up to the number that fit in the 4430 sliding window with size computed as in Appendix B. 4432 Using the symbol definitions of Appendix A, the calculation of the 4433 value for the PPD of the remote peer can be estimated as: 4435 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4436 + Fudge 4438 This is simply the number of bits in a full control session window 4439 divided by the average speed of the path between the LAC and LNS with 4440 a fudge factor added on to make it work. In cases where the average 4441 rate of the connection between LAC and LNS isn't known, it is 4442 suggested that some value be configured that is associated with each 4443 possible peer. Because Control Session windows will most likely be 4444 small and the connection speed will be quite high, fudge will be the 4445 dominant factor in this calculation. For this reason, just 4446 configuring a single fixed initial PPD estimate to be used for all 4447 possible peers will probably provide adequate results. This fudge 4448 factor should probably be at least 0.5 second. 4450 Appendix E: Examples of L2TP sequence numbering 4452 Although sequence numbers serve distinct purposes for control and 4453 data messages, both types of messages use identical techniques for 4454 assigning sequence numbers. This appendix shows several common 4455 scenarios, and illustrates how sequence number state progresses and 4456 is interpreted. 4458 E.1: Lock-step tunnel establishment 4460 In this example, an LAC establishes a tunnel, with the exchange 4461 involving each side alternating in sending messages. This example 4462 is contrived, in that the final acknowledgment in the example is 4463 explicitly sent within a zero-length message, although most 4464 typically the acknowledgment would have been included in the 4465 processing of the Incoming-Call-Request which had prompted the LAC 4466 to initiate the tunnel in the first place. 4468 LAC LNS 4469 -> Start-Control-Connection-Request 4470 Nr: 0, Ns: 0 4472 Start-Control-Connection-Reply <- 4473 Nr: 1, Ns: 0 4475 -> Start-Control-Connection-Connected 4476 Nr: 1, Ns: 1 4478 (delay) 4480 (zero-length) <- 4481 Nr: 2, Ns: 1 4483 E.2: Multiple packets acknowledged 4485 This example shows a flow of payload packets from the LNS to the 4486 LAC, with the LAC having no traffic of its own. The LAC is 4487 waiting 1/4 of its timeout interval, and then acknowledging all 4488 packets seen since the last interval. 4490 (previous packet flow precedes this) 4492 LAC LNS 4493 -> (zero-length) 4494 Nr: 7000, Ns: 1000 4495 (payload) <- 4496 Nr: 1000, Ns: 7000 4497 (payload) <- 4498 Nr: 1000, Ns: 7001 4499 (payload) <- 4500 Nr: 1000, Ns: 7002 4502 (LAC's timer indicates it should acknowledge pending traffic) 4504 -> (zero-length) 4505 Nr: 7003, Ns: 1000 4507 E.3: Lost packet with retransmission 4509 As a final example, an existing tunnel has a new session requested 4510 by the LAC. The Incoming-Call-Reply is lost and must be 4511 retransmitted by the LNS. This example continues from the 4512 sequence state reached at the end of example E.1. Note that loss 4513 of the -Reply has two impacts: not only does it keep the upper 4514 level state machine from progressive, but it also keeps the LAC 4515 from seeing a timely lower level acknowledgment of its -Request 4516 packet. 4518 LAC LNS 4519 -> Incoming-Call-Request 4520 Nr: 1, Ns: 2 4522 Incoming-Call-Reply <- 4523 Nr: 3, Ns: 1 4525 (pause; LAC's timer started first, so fires first) 4527 -> Incoming-Call-Request 4528 Nr: 1, Ns: 2 4530 (LNS realizes it has already seen this packet) 4531 (LNS might use this as a cue to retransmit, as in this example) 4533 Incoming-Call-Reply <- 4534 Nr: 3, Ns: 1 4535 -> Incoming-Call-Connected 4536 Nr: 2, Ns: 3 4538 (delay) 4540 (zero-length) <- 4541 Nr: 4, Ns: 2 4543 E.4: Lost payload packet with ZLB congestion control 4545 In this example, a packet sent from Peer A to Peer B is lost. Peer 4546 B's receive window is 4, so after Peer B realizes that it has 4547 filled Peer B's window, it waits. After timing out, it sends a ZLB 4548 with the R-bit set to reset Peer B, telling it to give up on 3001. 4549 If performing window adjustment, Peer A should now reduce its 4550 effective transmit window size until a full window is digested by 4551 Peer B. 4553 Peer A Peer B (RW=4) 4554 -> Payload Packet 4555 Nr: 7000, Ns: 3000 4557 Payload Packet <- 4558 Nr: 3001, Ns: 7000 4560 -> Payload packet (packet lost) 4561 Nr: 7001, Ns: 3001 4563 Payload Packet <- 4564 Nr: 3001, Ns: 7001 4566 -> Payload packet 4567 Nr: 7002, Ns: 3002 4568 -> Payload packet 4569 Nr: 7002, Ns: 3003 4570 -> Payload packet 4571 Nr: 7002, Ns: 3004 4573 (window full, waiting) 4575 -> Timeout, send ZLB w/R-bit set 4576 Nr: 7002 Ns: 3001 4578 Payload Packet <- 4579 Nr: 3005 Ns: 7002 4581 E.5: Lost payload packet with piggyback congestion control 4583 In this example, two packets sent from Peer A to Peer B are lost. 4584 Peer B's receive window is 4, so after Peer B realizes that it has 4585 filled Peer B's window, it waits. After timing out, it sends a 4586 payload packet with the R-bit set to reset Peer B, telling it to 4587 give up on 3001 and 3002. If performing window adjustment, Peer A 4588 should now reduce its effective transmit window size until a full 4589 window is digested by Peer B. Note that in this scenerio Peer A 4590 has no way of knowing that more than one packet was lost. 4592 Peer A Peer B (RW=4) 4593 -> Payload Packet 4594 Nr: 7000, Ns: 3000 4596 Payload Packet <- 4597 Nr: 3001, Ns: 7000 4599 -> Payload packet (packet lost) 4600 Nr: 7001, Ns: 3001 4601 -> Payload packet (packet lost) 4602 Nr: 7001, Ns: 3002 4604 Payload Packet <- 4605 Nr: 3001, Ns: 7001 4607 -> Payload packet 4608 Nr: 7002, Ns: 3003 4609 -> Payload packet 4610 Nr: 7002, Ns: 3004 4612 (window full, waiting) 4614 -> Timeout, send Payload w/R-bit set 4615 Nr: 7002 Ns: 3005 4617 Payload Packet <- 4618 Nr: 3006 Ns: 7002