idnits 2.17.1 draft-ietf-pppext-l2tp-05.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-23) 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 82 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 82 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 36 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 162: '... o MUST, SHALL, or MANDATORY --...' RFC 2119 keyword, line 165: '... o SHOULD or RECOMMEND -- This ...' RFC 2119 keyword, line 168: '... o MAY or OPTIONAL -- This item...' RFC 2119 keyword, line 617: '...e of 0 is thus special and MUST NOT be...' RFC 2119 keyword, line 690: '...Nr and Ns fields MUST be present in pa...' (121 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2782 has weird spacing: '...message encod...' == Line 3567 has weird spacing: '...e local wai...' == Line 3568 has weird spacing: '...ndicate tunne...' == Line 3734 has weird spacing: '...e local wai...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An implementation that does not support an extension which might make use of a particular reserved bit MUST not attempt to process a packet received with such reserved bit set. == 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 342 -- Looks like a reference, but probably isn't: 'R' on line 344 -- Looks like a reference, but probably isn't: 'U' on line 345 -- Looks like a reference, but probably isn't: 'L' on line 343 -- Looks like a reference, but probably isn't: 'N' on line 346 -- 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 (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group Kory Hamzeh 3 INTERNET DRAFT Ascend Communications 4 Category: Internet Draft Tim Kolar 5 Title: draft-ietf-pppext-l2tp-05.txt Cisco Systems 6 Date: August 1997 Morgan Littlewood 7 Cisco Systems 8 Gurdeep Singh Pall 9 Microsoft Corporation 10 Bill Palter 11 Cisco Systems 12 Jeff Taarud 13 Copper Mountain Networks 14 W. Mark Townsley 15 IBM 16 Andrew J. Valencia 17 Cisco Systems 18 William Verthein 19 U.S. Robotics 21 Layer Two Tunneling Protocol "L2TP" 23 Status of this Memo 25 This document is an Internet-Draft. Internet-Drafts are working 26 documents of the Internet Engineering Task Force (IETF), its areas, 27 and its working groups. Note that other groups may also distribute 28 working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months. Internet-Drafts may be updated, replaced, or obsoleted by 32 other documents at any time. It is not appropriate to use Internet- 33 Drafts as reference material or to cite them other than as a 34 ``working draft'' or ``work in progress.'' 36 To learn the current status of any Internet-Draft, please check the 37 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 38 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 39 munnari.oz.au. 41 Abstract 43 Virtual dial-up allows many separate and autonomous protocol domains 44 to share common access infrastructure including modems, Access 45 Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up 46 via PPP [1]. This document describes the Layer Two Tunneling 47 Protocol (L2TP) which permits the tunneling of the link layer (i.e., 48 HDLC, async HDLC) of PPP. Using such tunnels, it is possible to 49 divorce the location of the initial dial-up server from the location 50 at which the dial-up protocol connection is terminated and access to 51 the network provided. 53 Table of Contents 55 1.0 Introduction 56 1.1 Conventions 57 1.2 Terminology 58 2.0 Problem Space Overview 59 2.1 Initial Assumptions 60 2.2 Topology 61 2.3 Providing Virtual Dial-up Services--a walk-through 62 3.0 Service Model Issues 63 3.1 Security 64 3.2 Address Allocation 65 3.3 Authentication 66 3.4 Accounting 67 4.0 Protocol Overview 68 4.1 Control Message Overview 69 4.2 Payload Packet Overview 70 5.0 Message Format and Protocol Extensibility 71 5.1 AVP 72 5.2 Control Message Format 73 5.3 Payload Message Format 74 5.4 Control Message Types 75 5.5 AVP Summary 76 5.6 Result and Error Code Summary 77 5.7 Hiding of AVP values 78 6.0 Control Connection Protocol Specification 79 6.1 Start-Control-Connection-Request 80 6.2 Start-Control-Connection-Reply 81 6.3 Start-Control-Connection-Connected 82 6.4 Stop-Control-Connection-Request 83 6.5 (reserved) 84 6.6 Hello 85 6.7 Outgoing-Call-Request 86 6.8 Outgoing-Call-Reply 87 6.9 Outgoing-Call-Connected 88 6.10 Incoming-Call-Request 89 6.11 Incoming-Call-Reply 90 6.12 Incoming-Call-Connected 91 6.13 (reserved) 92 6.14 Call-Disconnect-Notify 93 6.15 WAN-Error-Notify 94 6.16 Set-Link-Info 95 7.0 Control Connection State Machines 96 7.1 Control Connection Protocol Operation 97 7.2 Control Connection States 98 7.2.1 Control Connection Originator 99 7.2.2 Control connection Receiver 100 7.3 Timing considerations 101 7.4 Incoming Calls 102 7.4.1 LAC Incoming Call States 103 7.4.2 LNS Incoming Call States 104 7.5 Outgoing calls 105 7.5.1 LAC Outgoing Call States 106 7.5.2 LNS Outgoing Call States 107 8.0 L2TP Over Specific Media 108 8.1 IP/UDP 109 8.2 IP 110 9.0 Security Considerations 111 9.1 Tunnel Endpoint Security 112 9.2 Client Security 113 10.0 Acknowledgments 114 11.0 Contacts 115 12.0 References 116 Appendix A: Acknowledgment Time-Outs 117 Appendix B: Acknowledgment Time-Out and Window Adjustment 118 Appendix C: Handling of out-of-order packets 119 Appendix D: Transport Layer Adaptive Time-Outs and Window Adjustment 120 Appendix E: Examples of L2TP sequence numbering 121 E.1 Lock-step tunnel establishment 122 E.2 Multiple packets acknowledged 123 E.3 Lost packet with retransmission 125 1.0 Introduction 127 The traditional dial-up network service on the Internet is for 128 registered IP addresses only. A new class of virtual dial-up 129 application which allows multiple protocols and unregistered IP 130 addresses is also desired on the Internet. Examples of this class of 131 network application are support for privately addressed IP, IPX, and 132 AppleTalk dial-up via PPP across existing Internet infrastructure. 134 The support of these multiprotocol virtual dial-up applications is of 135 significant benefit to end users, enterprises, and Internet Service 136 providers as it allows the sharing of very large investments in 137 access and core infrastructure and allows local calls to be used. It 138 also allows existing investments in non-IP protocol applications to 139 be supported in a secure manner while still leveraging the access 140 infrastructure of the Internet. 142 It is the purpose of this draft to identify the issues encountered in 143 integrating multiprotocol dial-up services into an existing Internet 144 Service Provider's Point of Presence (hereafter referred to as ISP 145 and POP, respectively), and to describe the L2TP protocol which 146 permits the leveraging of existing access protocols. 148 This protocol may also be used to solve the "multilink hunt-group 149 splitting" problem. Multilink PPP, often used to aggregate ISDN B 150 channels, requires that all channels composing a multilink bundle be 151 grouped at a single NAS. Because L2TP makes a PPP session appear at 152 a location other than the physical point at which the session was 153 physically received, it can be used to make all channels appear at a 154 single NAS, allowing multilink operation even when the physical calls 155 are spread across distinct physical NAS's. 157 1.1 Conventions 159 The following language conventions are used in the items of 160 specification in this document: 162 o MUST, SHALL, or MANDATORY -- This item is an absolute 163 requirement of the specification. 165 o SHOULD or RECOMMEND -- This item should generally be followed 166 for all but exceptional circumstances. 168 o MAY or OPTIONAL -- This item is truly optional and may be 169 followed or ignored according to the needs of the implementor. 171 1.2 Terminology 173 Analog Channel 175 A circuit-switched communication path which is intended to carry 176 3.1 Khz audio in each direction. 178 Digital Channel 180 A circuit-switched communication path which is intended to carry 181 digital information in each direction. 183 Call 185 A connection or attempted connection between two terminal 186 endpoints on a PSTN or ISDN--for example, a telephone call between 187 two modems. 189 CHAP 191 Challenge Authentication Protocol, a PPP cryptographic 192 challenge/response authentication protocol in which the cleartext 193 password is not passed in the clear over the line. 195 CLID 197 Calling Line ID, an indication to the receiver of a call as to the 198 phone number of the caller. 200 Control Messages 201 Control messages are exchanged between LAC, LNS pairs, and operate 202 in-band within the tunnel protocol. Control messages govern 203 aspects of the tunnel and sessions within the tunnel. 205 Dial User 207 An end-system or router attached to an on-demand PSTN or ISDN 208 which is either the initiator or recipient of a call. 210 DNIS 212 Dialed Number Information String, an indication to the receiver of 213 a call as to what phone number the caller used to reach it. 215 EAP 216 Extensible Authentication Protocol, a framework for a family of 217 PPP authentication protocols, including cleartext, 218 challenge/response, and arbitrary dialog sequences. 220 L2TP Access Concentrator (LAC) 222 A device attached to one or more PSTN or ISDN lines capable of PPP 223 operation and of handling the L2TP protocol. The LAC needs only 224 implement the media over which L2TP is to operate to pass traffic 225 to one or more LNS's. It may tunnel any protocol carried within 226 PPP. 228 L2TP Network Server (LNS) 230 An LNS operates on any platform capable of PPP termination. The 231 LNS handles the server side of the L2TP protocol. Since L2TP 232 relies only on the single media over which L2TP tunnels arrive, 233 the LNS may have only a single LAN or WAN interface, yet still be 234 able to terminate calls arriving at any LAC's full range of PPP 235 interfaces (async, synchronous ISDN, V.120, etc.). 237 Network Access Server (NAS) 239 A device providing temporary, on-demand network access to users. 240 This access is point-to-point using PSTN or ISDN lines. 242 PAP 244 Password Authentication Protocol, a simple PPP authentication 245 mechanism in which a cleartext username and password are 246 transmitted to prove identity. 248 Session 250 L2TP is connection-oriented. The LNS and LAC maintain state for 251 each user that is attached to an LAC. A session is created when 252 an end-to-end PPP connection is attempted between a dial user and 253 the LNS, or when a outbound call is initiated. The datagrams 254 related to a session are sent over the tunnel between the LAC and 255 LNS. 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 Switched Virtual Circuit (SVC) 267 An L2TP-compatible media on top of which L2TP is directly 268 encapsulated. SVC's are dynamically created, permitting tunnel 269 media to be created dynamically in response to desired LNS-LAC 270 connectivity requirements. 272 Tunnel 274 A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP 275 datagrams between the LAC and the LNS; many sessions can be 276 multiplexed over a single tunnel. A control connection operating 277 in-band over the same tunnel controls the establishment, release, 278 and maintenance of sessions and of the tunnel itself. 280 2.0 Problem Space Overview 282 In this section we describe in high level terms the scope of the 283 problem that will be explored in more detail in later sections. 285 2.1 Initial Assumptions 287 We begin by assuming that Internet access is provided by an ISP and 288 that the ISP wishes to offer services other than traditional 289 registered IP address based services to dial-up users of the network. 291 We also assume that the user of such a service wants all of the 292 security facilities that are available to him in a dedicated dial-up 293 configuration. In particular, the end user requires: 295 + End System transparency: Neither the remote end system nor his 296 home site hosts should require any special software to use this 297 service in a secure manner. 299 + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or 300 through other dialogs, for instance, a textual exchange on V.120 301 before starting PPP. This will include TACACS+ [7] and RADIUS [8] 302 solutions as well as support for smart cards and one-time passwords. 303 The authentication should be manageable by the user independently of 304 the ISP. 306 + Addressing should be as manageable as dedicated dial-up solutions. 307 The address should be assigned by the home site and not the ISP. 309 + Authorization should be managed by the home site as it would in a 310 direct dial-up solution. 312 + Accounting should be performed both by the ISP (for billing 313 purposes) and by the user (for charge-back and auditing). 315 2.2 Topology 317 Shown below is a generic Internet with Public switched Telephone 318 Network (PSTN) access (i.e., async PPP via modems) and Integrated 319 Services Digital Network (ISDN) access (i.e., synchronous PPP 320 access). Remote users (either async or ISDN PPP) will access the 321 Home LAN as if they were dialed into the L2TP Network Server (LNS), 322 although their physical dial-up is via the ISP Network Access Server. 324 ...----[L]----+---[L]-----... 325 | 326 | 327 [H] 328 | 329 ________|________________________ 330 | | 331 ________|__ ______|________ 332 | | | | 333 | PSTN [R] [R] ISDN | 334 | Cloud | | Cloud [N]__[U] 335 | | Internet | | 336 | | [R] | 337 [N]______[R] |_____________| 338 | | | 339 | | | 340 [U] |________________________________| 342 [H] = LNS 343 [L] = Home LAN(s) 344 [R] = Router 345 [U] = Remote User 346 [N] = ISP Network Access Server 348 2.3 Providing Virtual dial-up Services--a walk-through 350 To motivate the following discussion, this section walks through an 351 example of what might happen when a Virtual dial-up client initiates 352 access. 354 The remote user initiates a PPP connection to an ISP via either the 355 PSTN or ISDN. The Network Access Server (NAS) accepts the connection 356 and the PPP link is established (L2TP also permits the NAS to check 357 with an LNS after call indication prior to accepting the call--this 358 is useful where DNIS or CLID information is available in the incoming 359 call notification). 361 The ISP may now undertake a partial authentication of the end 362 system/user. Only the username field would be interpreted to 363 determine whether the user requires a Virtual dial-up service. It is 364 expected--but not required--that usernames will be structured (e.g. 365 username@company.com). Alternatively, the ISP may maintain a 366 database mapping users to services. In the case of Virtual dial-up, 367 the mapping will name a specific endpoint, the LNS. 369 Alternatively, the ISP may have already determined the target LNS 370 from DNIS. If the LNS is willing to accept tunnel creation without 371 any authentication of the caller, the NAS may tunnel the PPP 372 connection without ever having communicated with the remote user. 374 If a virtual dial-up service is not required, standard access to the 375 Internet may be provided. 377 If no tunnel connection currently exists to the desired LNS, one is 378 initiated. L2TP is designed to be largely insulated from the details 379 of the media over which the tunnel is established; L2TP requires only 380 that the tunnel media provide packet oriented point-to-point 381 connectivity. Obvious examples of such media are UDP, Frame Relay 382 PVC's, or X.25 VC's. 384 Once the tunnel exists, an unused slot within the tunnel, a "Call 385 ID", is allocated, and a connect indication is sent to notify the LNS 386 of this new dial-up session. The LNS either accepts the connection, 387 or rejects it. Rejection may include a reason indication, which may 388 be displayed to the dial-up user, after which the call should be 389 disconnected. 391 The initial setup notification may include the authentication 392 information required to allow the LNS to authenticate the user and 393 decide to accept or decline the connection. In the case of CHAP, the 394 set-up packet includes the challenge, username and raw response. For 395 PAP or text dialog, it includes username and clear text password. 396 The LNS may choose to use this information to complete its 397 authentication, avoiding an additional cycle of authentication. 399 If the LAC negotiated PPP LCP before initiating the tunnel, the 400 initial setup notification may also include a copy of the LCP 401 CONFREQ's sent in each direction which completed LCP negotiation. 402 The LNS may use this information to initialize its own PPP state 403 (thus avoiding an additional LCP negotiation), or it may choose to 404 initiate a new LCP CONFREQ exchange. 406 If the LNS accepts the connection, it creates a "virtual interface" 407 for PPP in a manner analogous to what it would use for a direct- 408 dialed connection. With this "virtual interface" in place, link 409 layer frames may now pass over this tunnel in both directions. 410 Frames from the remote user are received at the POP, stripped of CRC, 411 link framing, and transparency bytes, encapsulated in L2TP, and 412 forwarded over the appropriate tunnel. 414 The LNS accepts these frames, strips L2TP, and processes them as 415 normal incoming frames for the appropriate interface and protocol. 416 The "virtual interface" behaves very much like a hardware interface, 417 with the exception that the hardware in this case is physically 418 located at the ISP POP. The other direction behaves analogously, 419 with the LNS encapsulating the packet in L2TP, and the NAS stripping 420 L2TP before transmitting it out the physical interface to the remote 421 user. For the remainder of this document, a NAS operating as a peer 422 to an LNS will be referred to as an L2TP Access Concentrator, or 423 "LAC". 425 At this point, the connectivity is a point-to-point PPP session whose 426 endpoints are the remote user's networking application on one end and 427 the termination of this connectivity into the LNS's PPP support on 428 the other. Because the remote user has become simply another dial-up 429 client of the LNS, client connectivity can now be managed using 430 traditional mechanisms with respect to further authorization, 431 protocol access, and packet filtering. 433 Accounting can be performed at both the LAC as well as the LNS. This 434 document illustrates some Accounting techniques which are possible 435 using L2TP, but the policies surrounding such Accounting are outside 436 the scope of this specification. 438 L2TP offers optional facilities which maximize compatibility with 439 legacy client requirements; L2TP connect notifications for PPP 440 clients can contain sufficient information for an LNS to authenticate 441 and initialize its LCP state machine. With these facilities, the 442 remote user need not be queried a second time for PPP authentication, 443 nor undergo multiple rounds of LCP negotiation and convergence. 444 These techniques are intended to optimize connection setup, and are 445 not intended to deprecate any functions required by the PPP 446 specification. 448 3.0 Service Model Issues 450 There are several significant differences between the standard 451 Internet access service and the Virtual dial-up service with respect 452 to authentication, address allocation, authorization and accounting. 453 The details of the differences between these services and the 454 problems presented by these differences are described below. The 455 mechanisms used for Virtual Dial-up service are intended to coexist 456 with more traditional mechanisms; it is intended that an ISP's POP 457 can simultaneously service ISP clients as well as Virtual dial-up 458 clients. 460 3.1 Security 462 For the Virtual dial-up service, the ISP pursues authentication only 463 to the extent required to discover the user's apparent identity (and 464 by implication, their desired LNS). This may involve no more than 465 detecting DNIS information when a call arrives, or may involve full 466 LCP negotiation and initiation of PPP authentication. As soon as the 467 apparent identity is determined, a connection to the LNS is initiated 468 with any authentication information gathered by the ISP. The LNS 469 completes the authentication by either accepting the connection, or 470 rejecting it. 472 The LNS may need to protect against attempts by third parties to 473 establish tunnels to the LNS. Tunnel establishment can include 474 authentication to protect against such attacks. 476 3.2 Address Allocation 478 For an Internet service, the user accepts that the IP address may be 479 allocated dynamically from a pool of ISP addresses. This model often 480 means that the remote user has little or no access to their home 481 network's resources, due to firewalls and other security policies 482 applied by the home network to accesses from external IP addresses. 484 For the Virtual dial-up service, the LNS can exist behind the home 485 firewall, allocating addresses which are internal (and, in fact, can 486 be RFC1918 addresses, or non-IP addresses). Because L2TP tunnels 487 exclusively at the frame layer, the actual policies of such address 488 management are irrelevant to correct Virtual dial-up service; for all 489 purposes of PPP protocol handling, the dial-in user appears to have 490 connected at the LNS. 492 3.3 Authentication 494 The authentication of the user occurs in three phases; the first at 495 the ISP, and the second and optional third at the LNS. 497 The ISP uses DNIS, CLID, or username to determine that a Virtual 498 dial-up service is required and initiates the tunnel connection to 499 the appropriate LNS. Once a tunnel is established, The ISP NAS 500 allocates a new Call ID and initiates a session by forwarding the 501 gathered authentication information. 503 The LNS undertakes the second phase by deciding whether or not to 504 accept the connection. The connection indication may include CHAP, 505 PAP, EAP, or textual authentication information. Based on this 506 information, the LNS may accept the connection, or may reject it (for 507 instance, it was a PAP request and the username/password are found to 508 be incorrect). 510 Once the connection is accepted, the LNS is free to pursue a third 511 phase of authentication at the PPP layer. These activities are 512 outside the scope of this specification, but might include an 513 additional cycle of LCP authentication, proprietary PPP extensions, 514 or textual challenges carried via a TCP/IP telnet session. 516 3.4 Accounting 518 It is a requirement that both the LAC and the LNS be capable of 519 providing accounting data and hence both may count packets, octets 520 and connection start and stop times. 522 Since Virtual dial-up is an access service, accounting of connection 523 attempts (in particular, failed connection attempts) is of 524 significant interest. The LNS can reject new connections based on 525 the authentication information gathered by the LAC, with 526 corresponding logging. For cases where the LNS accepts the 527 connection and then continues with further authentication, the LNS 528 might subsequently disconnect the client. For such scenarios, the 529 disconnection indication back to the LAC may also include a reason. 531 Because the LNS can decline a connection based on the authentication 532 information collected by the LAC, accounting can easily draw a 533 distinction between a series of failed connection attempts and a 534 series of brief successful connections. Lacking this facility, the 535 LNS must always accept connection requests, and would need to 536 exchange a number of PPP packets with the remote system. Note that 537 the LNS could use this information to decide to accept the connection 538 (which protects against most invalid connection attempts) while still 539 insisting on running its own CHAP authentication (for instance, to 540 protect against CHAP replay attacks). 542 4.0 Protocol Overview 544 There are two parallel components of L2TP operating over a given 545 tunnel: control messages between each LAC-LNS pair, and payload 546 packets between the same LAC-LNS pair. The latter are used to 547 transport L2TP encapsulated PPP packets for user sessions between the 548 pair. 550 The Nr (Next Received) and Ns (Next Sent) fields are always present 551 in control messages, and are optionally present in payload messages. 552 A single sequence number state is maintained for all control 553 messages, and a distinct state is maintained for the payload of each 554 user session within the tunnel. Each state is initialized so the 555 first packet is sent with an Ns of 0. Nr is sent reflecting one more 556 than the last in-order received packet; if sent before any packet is 557 received it would be 0, indicating that it expects the next new Ns 558 value received to be 0. 560 The sequence number state is maintained and updated as packets are 561 sent. A message (control or payload) with a zero-length body 562 indicates that the packet is only used to communicate Nr and Ns 563 fields. The Nr and Ns fields are filled in as above, but the 564 sequence number state remains the same. For non-zero-length body 565 messages, the sequence number state is incremented (modulo 2**16) 566 after it is copied to the packet's Ns field. Thus a zero-length 567 message's Ns field will reflect one more than the Ns of the last 568 non-zero-length message sent. 570 Upon receipt of a non-zero-length message, the receiving peer must 571 acknowledge the message by sending back the latest Nr value. This 572 updated Nr value can be piggybacked in any non-zero-length outgoing 573 messages that the peer may happen to send back. However, if the peer 574 does not have a non-zero-length message to transmit for a period of 575 1/4 of the timeout interval after receiving a non-zero-length message 576 then it should send a zero-length message containing the latest 577 sequence number state, as described above. 579 See Appendix E for some examples of how sequence numbers progress. 581 4.1 Control Message Overview 583 Before PPP tunneling can occur between an LAC and LNS, control 584 messages must be exchanged between them. Control messages are 585 exchanged over the same tunnel which will be used to forward 586 payload data once L2TP call control and management information 587 have been passed. The control messages are responsible for 588 establishment, management, and release of sessions carried through 589 the tunnel, as well as status on the tunnel itself. It is the 590 means by which an LNS is notified of an incoming call at an 591 associated LAC, as well as the means by which an LAC is instructed 592 to place an outgoing call. 594 A tunnel may be established by either an LAC (for incoming calls) 595 or an LNS (for outgoing calls). Following the establishment of 596 the tunnel, the LNS and LAC configure the tunnel by exchanging 597 Start-Control-Connection-Request and -Reply messages. These 598 messages are also used to exchange information about basic 599 operating capabilities of the LAC and LNS. Once the control 600 message exchange is complete, the LAC may initiate sessions by 601 indicating inbound requests, or the LNS by requesting outbound 602 calls. If both ends of the tunnel have the ability to act as an 603 LAC and LNS concurrently, then nothing prohibits establishing 604 incoming or outgoing calls from both sides of the same tunnel. 605 Control messages may indicate changes in operating characteristics 606 of an individual user session with a Set-Link-Info message. 607 Individual sessions may be released by either the LAC or LNS, also 608 through control messages. 610 Independent Call ID values are established for each end of a user 611 session. The sender of a packet associated with a particular 612 session places the Call ID established by its peer in the Call ID 613 header field of all outgoing packets. For the cases where a Call 614 ID has not yet been assigned from the peer (i.e., during call 615 establishment of a new session), the Call ID field is sent as 0, 616 and further fields within the message are used to identify the 617 session. The Call ID value of 0 is thus special and MUST NOT be 618 used as an Assigned Call ID. 620 A mechanism for detection of tunnel connectivity problems is 621 provided by the reliable transport layer of L2TP. The transport 622 layer of L2TP performs control message retransmission. If the 623 number of retransmission attempts for a given control message 624 exceeds a configured maximum value, the tunnel is reset. This 625 retransmission mechanism exists in both the LNS and LAC ends of 626 the tunnel. 628 A keepalive mechanism is employed by the L2TP higher layer in 629 order to differentiate tunnel outages from extended periods of no 630 control or data activity on a tunnel. This is accomplished by the 631 higher injecting Hello control messages into the control stream 632 after a specified period of time elapses since the last data or 633 control was received on the tunnel. As for any other control 634 message, if the transport does not receive an ACK for the Hello 635 message after the normal number of retransmissions the tunnel is 636 declared down and is reset. The transport layer reset mechanism 637 along with the injection of Hello messages ensures that a 638 connectivity failure between the LNS and the LAC will be detected 639 at both ends of a tunnel in a timely manner. 641 It is intended that control messages will also carry management 642 related information in the future, such as a message allowing the 643 LNS to request the status of a given LAC; these message types are 644 not defined in this document. 646 4.2 Payload Packet Overview 647 Once a tunnel is established and control messages have completed 648 tunnel setup, the tunnel can be used to carry user session PPP 649 packets for sessions involving a given LNS-LAC pair. The "Call 650 ID" field in the L2TP header indicates to which session a 651 particular PPP packet belongs. In this manner, PPP packets are 652 multiplexed and demultiplexed over a single tunnel between a given 653 LNS-LAC pair. The "Call ID" field value is established during the 654 exchange of call setup control messages. 656 It is legal for multiple tunnels to exist between a given LNS-LAC 657 pair. This is useful where each tunnel is used for a single user 658 session, and the tunnel media (an SVC, for instance) has specific 659 QOS attributes dedicated to a given user. L2TP provides a tunnel 660 identifier so that individual tunnels can be identified, even when 661 arriving from a single source LAC or LNS. 663 The L2TP header also contains optional acknowledgment and 664 sequencing information that can be used to perform congestion and 665 flow control over the tunnel. Control messages are used to 666 determine rate and buffering parameters that are used to regulate 667 the flow 669 of PPP packets for a particular session over the tunnel. 671 The receiving peer indicates whether flow-control is to be 672 performed for payload packets sent to it. If a peer issues a 673 Receive Window Size AVP with a non-zero value during session 674 establishment then the sending peer must abide by the indicated 675 window size value. If a receiving peer does not wish to flow 676 control the payload messages sent to it, it should not issue the 677 Receive Window Size AVP with a non-zero value. Issuing a Receive 678 Window Size AVP with a zero value has special significance. It 679 indicates that the receiver does not want to perform flow-control 680 but it does want the sending peer to provide Ns values in payload 681 packets so that it can detect (and perhaps reorder) packets 682 received out of order. 684 In the case where neither peer issues a Receive Window Size AVP 685 during session establishment, the optional Nr and Ns fields are 686 absent in all payload messages for that session. In the case 687 where either peer wishes to perform flow-control or to detect 688 out-of-order receive messages (as indicated by the sending of the 689 Receive Window Size AVP with non-zero or zero value, respectively) 690 the Nr and Ns fields MUST be present in payload messages sent by 691 both peers. Both MUST provide proper Nr and Ns values in all 692 messages transmitted. A proper Ns value starts at 0 and 693 increments by one for each transmitted payload message and a 694 proper Nr value is the current value of the receive sequence 695 number state variable. 697 If a receiving peer offers a non-zero receive window size to a 698 sending peer then the sending peer SHOULD abide by this window 699 size value. The sending peer should stop sending payload messages 700 when the window is full; i.e., x consecutive messages have been 701 sent but have not been acknowledged, where x is the value of the 702 Receive Window Size AVP. Implementors should take care to avoid 703 the situation where loss of an ACK by a sending peer with a full 704 transmit window causes a session to hang forever, due to the fact 705 there are no retransmissions of payload messages. Steps must be 706 taken to reopen the transmit window (at least to a value of 1) 707 upon expiration of an ACK wait timeout. See Appendix B for more 708 details. 710 L2TP does not specify the particular algorithms to use for 711 congestion control. Suggested algorithms for the determination of 712 adaptive time-outs to recover from dropped data or acknowledgments 713 on the tunnel are included in Appendix A of this document. 715 L2TP does not include a "Receive-Not-Ready" function. It is 716 expected that the flow-control mechanism used will provide an 717 adequate "pacing" mechanism so that the sender does not overflow 718 the receiver's allotted receive window and receive buffers. It is 719 permissible for the receiving peer to withhold Acks if it is 720 unable to accept more data for a connection. Thus, unlike for the 721 Control Message session, the sending peer MUST NOT clear a session 722 (or the whole tunnel) as a result of not receiving timely 723 acknowledgments for transmitted packets. The job of detecting a 724 non-functioning tunnel lies solely with the Control Message 725 functions of L2TP. 727 5. Message Format and Protocol Extensibility 729 L2TP defines a set of control messages sent in packets over the 730 tunnel between an LNS and a given LAC. The exact technique for 731 initiating a tunnel between an LNS-LAC pair is specific to the tunnel 732 media, and specific media are described in section 8.0. 734 Once media-level connectivity is reached, L2TP message formats define 735 the protocol for an LAC and LNS to manage the tunnel and its 736 associated sessions. 738 In each case where a field is optional, if the field is not present, 739 its space does not exist in the packet. Existing fields are placed 740 back-to-back to form the packet. 742 5.1 AVP 744 To maximize extensibility while still permitting interoperability, 745 a uniform method for encoding message types and bodies is used 746 throughout L2TP. This encoding will be termed an AVP (Attribute- 747 Value Pair) in the remainder of this document. Each AVP is 748 encoded as: 750 0 1 2 3 751 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 |M|H|0|0|0|0| Overall Length | Vendor ID | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Attribute | Value... | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | [until Overall Length is reached]... | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 The first six bits are a bit mask, describing the general 761 attributes of the AVP. The M bit, known as the "mandatory" bit, 762 controls the behavior required of an implementation which receives 763 an AVP which it does not recognize. 765 If M is set on an AVP associated call management, any session 766 associated with this AVP MUST be terminated. If the AVP is 767 associated with the overall tunnel, the entire tunnel (and all 768 sessions within) MUST be terminated. If M is not set, an 769 unrecognized AVP should be ignored. 771 The H bit, known as the "hidden" bit, controls the hiding of the 772 data in the value field of an AVP. This capability can be used to 773 avoid the passing of sensitive data, such as user passwords, as 774 cleartext in an AVP. Section 5.7 describes the procedure for 775 performing AVP value hiding. 777 Overall Length encodes the number of octets (including the Overall 778 Length field itself) contained in this AVP. It is 10 bits, 779 permitting a maximum of 1024 bytes of data in a single AVP. 781 Vendor ID is the IANA assigned "SMI Network Management Private 782 Enterprise Codes" value, encoded in network byte order. The value 783 0, reserved in this table, corresponds to IETF adopted Attribute 784 values, defined within this document. Any vendor wishing to 785 implement L2TP extensions can use their own Vendor ID along with 786 private Attribute values, guaranteeing that they will not collide 787 with any other vendor's extensions, nor with future IETF 788 extensions. 790 Attribute is the actual attribute, a 16-bit value with a unique 791 interpretation across all AVP's defined under a given Vendor ID. 793 Value follows immediately after the Attribute field, and runs for 794 the remaining octets indicated in the Overall Length (i.e., 795 Overall Length minus six octets of header). 797 AVP's should be kept compact; the combined AVP's within a control 798 message MUST NOT ever cause a control message's total length to 799 exceed 1500 bytes in length. 801 5.2 Control Message Format 803 Each L2TP control message begins with a 16 octet header portion 804 followed by zero or more AVP's. This header is formatted: 806 0 1 2 3 807 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 |T|1|0|0|1|0|0|0| | Ver | Length | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Tunnel ID | Call ID | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Ns | Nr | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Message Type AVP... | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | ... (8 bytes) | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 The T bit MUST be 1, indicating a control message. The following 821 seven bits MUST be set to 1001000, making the header more 822 compatible in encoding with the payload message (defined in the 823 next section). 825 Ver MUST be the value 2, indicating a version 1 L2TP message 826 (values 0 and 1 are reserved to permit detection of L2F [2] and 827 PPTP [3] packets if they arrive intermixed). 829 Length is the overall length of the message, including header, 830 message type AVP, plus any additional AVP's associated with a 831 given control message type. 833 Tunnel ID and Call ID identify the tunnel and user session within 834 the tunnel to which a control message applies. If a control 835 message does not apply to a single user session within the tunnel 836 (for instance, a Stop-Control-Connection-Notification message), 837 Call ID MUST be set to 0. If an Assigned Tunnel ID has not yet 838 been received from the peer, Tunnel ID MUST be set to 0. Once an 839 Assigned Tunnel ID is received, all further packets MUST be sent 840 with Tunnel ID set to the indicated value. 842 Nr and Ns reflect the currently transmitted packet and latest 843 received packet respectively. See section 4.0. 845 5.3 Payload Message Format 847 PPP payload packets tunneled within L2TP have a smaller 848 encapsulation than the L2TP control message header, reducing 849 overhead of L2TP during the life of a tunneled PPP session. The 850 MTU for the user data packets encapsulated in L2TP is expected to 851 be 1500 octets, not including L2TP and media encapsulation. The 852 smallest L2TP encapsulation is 2 octets; the largest is 14 octets 853 (plus padding bytes, if present). See section 8.1 for further MTU 854 considerations. 856 0 1 2 3 857 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 |T|L|I|C|F|K|O|0|0|0|0|0|0| Ver | Length (opt) | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Tunnel ID | Call ID | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Ns (opt) | Nr (opt) | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Offset Size (opt) | Offset pad... (opt) | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 The T bit MUST be 0, indicating payload. 870 Ver MUST be 2, indicating version 1 of the L2TP protocol. 872 If the L bit is set, the Length field is present, indicating the 873 total length of the received packet. 875 The I and C bits are reserved and MUST be set to 0. These bit 876 positions represent options no longer present in L2TP. 878 If the F bit is set, both the Nr and Ns fields are present. Ns 879 indicates indicates the sequence number of the packet being sent. 880 The Ns value of a message being transmitted is copied from the 881 current value of the send sequence number state variable. The 882 send sequence number state variable is incremented by one after 883 copying to the Ns field only if the payload size of the message 884 being sent is non-zero. Nr indicates the next packet sequence 885 number to be received (if the last non-zero-length data packet had 886 Ns set to 1, the Nr sent back would be 2). Together, these fields 887 can be used to handle out-of-order packets, and to provide flow 888 control for the connection. 890 An L2TP peer setting the F bit, and placing Nr and Ns fields in 891 its messages, MUST have previously received or sent a Receive 892 Window Size AVP during establishment of the session. The Nr and 893 Ns fields are present and updated as described in section 4.0 if 894 either side has specified an intention to do payload flow control. 896 The K bit is reserved MUST be set to 0. This bit position 897 represents a function no longer present in L2TP. The bits 898 following the K bit MUST all be 0. 900 The Offset Size field is present if the O bit is set in the header 901 flags. This field specifies the number of bytes past the L2TP 902 header at which the payload data is expected to start. It is 903 recommended that data thus skipped be initialized to 0's. If 904 Offset Size is 0, or the O bit is not set, the first byte 905 following the last byte of L2TP header is the first byte of 906 payload data. 908 An implementation that does not support an extension which 909 might make use of a particular reserved bit MUST not 910 attempt to process a packet received with such 911 reserved bit set. 913 5.4 Control Message Types 915 Control message and AVP types defined in this specification exist 916 under Vendor ID 0, indicating IETF defined behavior. The actual 917 message and AVP semantics are defined in the next section. This 918 section includes tables that summarize all currently defined 919 message and AVP types. 921 Each message type entry in the table below indicates: the integer 922 value assigned to the message type; the message type abbreviation 923 used in the AVP Summary Table of Sec. 5.5; and the full name of 924 the message type. 926 The integer value assigned to each message type is placed in the 927 Value field of the Message Type AVP. This AVP MUST be the first 928 AVP in a message. The currently defined control message types, 929 grouped by function, are: 931 Control Connection Management 933 1 (SCCRQ) Start-Control-Connection-Request 934 2 (SCCRP) Start-Control-Connection-Reply 935 3 (SCCCN) Start-Control-Connection-Connected 936 4 (StopCCN) Stop-Control-Connection-Notification 937 5 (reserved) 938 6 Hello 940 Call Management 942 7 (OCRQ) Outgoing-Call-Request 943 8 (OCRP) Outgoing-Call-Reply 944 9 (OCCN) Outgoing-Call-Connected 945 10 (ICRQ) Incoming-Call-Request 946 11 (ICRP) Incoming-Call-Reply 947 12 (ICCN) Incoming-Call-Connected 948 13 (reserved) 949 14 (CDN) Call-Disconnect-Notify 951 Error Reporting 953 15 (WEN) WAN-Error-Notify 955 PPP Session Control 957 16 (SLI) Set-Link-Info 959 5.5 AVP Summary 961 The following table lists all standard L2TP attributes currently 962 defined. The "Attr" column indicates the integer value assigned to 963 this attribute. The "M" column indicates the setting of the 964 "Mandatory" bit of the AVP header for each attribute. The "Len" 965 field indicates the size of the AVP including the AVP header. A 966 "+" in this column indicates that the length varies depending upon 967 the length of the actual contents of the value field. 969 The "(usage)" list for each entry indicates the message types that 970 utilize each AVP (See command table of Sec. 5.4). An abbreviation 971 shown in mixed or upper case letters indicates that the 972 corresponding AVP MUST be present in this message type; All lower 973 case indicates that the AVP may optionally appear in this message 974 type. A "+" appended to a message type abbreviation indicates 975 that the AVP is only mandatory in a "positive" (non-error) 976 condition -- The AVP is optional in a message indicating an error 977 condition. 979 A brief summary of the type and contents of the value field for 980 each attribute is also given for each entry. Refer to the 981 individual message type descriptions that appear in Section 6 for 982 further details about the use of a particular AVP in a particular 983 message type. 985 Attr M Len Attribute Name (usage) 987 0 1 8 Message Type (ALL MESSAGES) 988 16 bit integer value indicating the message type, as defined in 989 table above. MUST be the first AVP in each message 991 1 1 10+ Result Code (CDN, ICRP, OCCN, OCRP, SCCRP, StopCCN) 992 16 bit Integer value indicating result of corresponding request 993 or reason for issuing a request, 16 bit integer General Error 994 code and an optional ASCII string error message. See Result 995 and General Error code tables below. 997 2 1 8 Protocol Version (SCCRP, SCCRQ) 998 8 bit L2TP Protocol and Revision numbers 1000 3 1 10 Framing Capabilities (SCCRP, SCCRQ) 1001 32 bit bitmask indicating supported framing types (e.g., 1002 synchronous and asynchronous) 1004 4 1 10 Bearer Capabilities (SCCRP, SCCRQ) 1005 32 bit bitmask indicating supported bearer types (e.g., analog 1006 and digital) 1008 5 0 14 Tie Breaker (sccrq) 1009 8 byte value used to break control connection establishment 1010 collisions 1012 6 0 8 Firmware Revision (SCCRP, SCCRQ) 1013 16 bit integer representing vendor's firmware revision 1015 7 0 6+ Host Name (SCCRP, SCCRQ) 1016 ASCII string name (e.g., DNS name) of issuer 1018 8 0 6+ Vendor Name (SCCRP, SCCRQ) 1019 ASCII string describing issuing device 1021 9 1 8 Assigned Tunnel ID (SCCRP+, SCCRQ, StopCCN) 1022 16 bit integer tunnel ID assigned by sender 1024 10 1 8 Receive Window Size (ICCN, ICRP, OCCN, OCRQ, SCCRP, 1025 SCCRQ) 1026 16 bit integer receive window size offered by sender for a 1027 given call or control session 1029 11 1 6+ Challenge (SCCRP, SCCRQ) 1030 1 or more octet value issued by sender wishing to authenticate 1031 control session peer 1033 12 0 9+ Q.931 Cause Code (CDN, OCCN) 1034 16 bit cause code, 1 octet cause message, and optional ASCII 1035 advisory message 1037 13 1 22 Challenge Response (SCCCN, SCCRP) 1038 16 octet CHAP type response to peer's Challenge 1040 14 1 8 Assigned Call ID (CCRQ, CDN, ICRP+, ICRQ, OCRP+, OCRQ) 1041 16 bit integer ID assigned to a call by sender 1043 15 1 6+ Call Serial Number (ICRQ, OCRQ) 1044 1 or more octet identifier assigned to a call 1046 16 1 10 Minimum BPS (OCRQ) 1047 32 bit integer indicating lowest acceptable line speed for call 1049 17 1 10 Maximum BPS (OCRQ) 1050 32 bit integer indicating highest acceptable line speed for 1051 call 1053 18 1 10 Bearer Type (ICRQ, OCRQ) 1054 Indicates bearer type (i.e., analog or digital) for call 1056 19 1 10 Framing Type (ICCN, OCCN+, OCRQ) 1057 Indicates framing type (i.e., synchronous or asynchronous) for 1058 call 1060 20 1 8 Packet Processing Delay (ICCN, ICRP, OCCN, OCRQ) 1061 16 bit integer estimate of processing time of full window of 1062 received packets by sender 1064 21 1 6+ Dialed Number (ICRQ, OCRQ) 1065 ASCII string phone number called or to be called 1067 22 1 6+ Dialing Number (ICRQ) 1068 ASCII string phone number of caller 1070 23 1 6+ Sub-Address (ICRQ, OCRQ) 1071 ASCII string containing additional dialing information 1073 24 1 10 Connect Speed (ICCN, OCCN+, OCRP+) 1074 16 bit integer actual line speed of connection 1076 25 1 10 Physical Channel ID (ICRQ, OCRP) 1077 16 bit vendor specific physical device identifier used for call 1079 26 0 6+ Initial LCP Confreq (ICCN) 1080 Octet string containing initial CONFREQ received from client 1082 27 0 6+ Last Sent LCP Confreq (ICCN) 1083 Octet string containing final CONFREQ sent to client 1085 28 0 6+ Last Received LCP Confreq (ICCN) 1086 Octet string containing final CONFREQ received from client 1088 29 1 8 Proxy Authen Type (ICCN) 1089 16 bit integer code indicating client authentication type 1090 negotiated (e.g., PAP, CHAP) 1092 30 0 6+ Proxy Authen Name (ICCN) 1093 ASCII string containing name returned by client in 1094 authentication response 1096 31 0 6+ Proxy Authen Challenge (ICCN) 1097 Octet string Challenge presented by LAC to client 1099 32 0 8 Proxy Authen ID (ICCN) 1100 16 bit integer of which low order octet is ID presented to 1101 client with Challenge. High order octet must be 0. 1103 33 1 6+ Proxy Authen Response (ICCN) 1104 Octet string CHAP response or ASCII string password depending 1105 on authentication type used 1107 34 1 32 Call Errors (WEN) 1108 A reserved 16 bit word set to 0 followed by 6 32 bit integer 1109 connection error counters 1111 35 1 16 ACCM (SLI) 1112 A reserved 16 bit word set to 0 followed by 2 32 bit bitmasks 1113 containing Send and Receive ACCM values respectively 1115 36 1 6+ Random Vector (all messages) 1116 Variable length octet string containing a random sequence of 1117 values used to accomplish the optional "hiding" of other AVP 1118 values (See "H" bit description in Sec. 5.7). 1120 37 1 6+ Private Group ID (ICRQ, ICCN, OCRQ) 1121 Variable length octet value used by the LAC or LNS to indicate 1122 that this call is to be associated with a particular customer 1123 group. 1125 5.6 Result and Error Code Summary 1126 In general, all Reply Message types contain a Result Code AVP which 1127 indicates the result of the requested operation. The Result Code can 1128 indicate that additional information pertaining to an error situation 1129 can be found in the Error Code field of the Result Code AVP. The 1130 meaning of the result code is tabulated under the specific type of 1131 message containing the result. Each 16-bit Result Code is 1132 immediately followed (in the same AVP) by a 16-bit General Error code 1133 value. 1135 General error codes pertain to types of errors which are not specific 1136 to any particular L2TP request, but rather to protocol or message 1137 format errors. If an L2TP reply indicates in its Result Code that a 1138 general error occurred, the General Error value should be examined to 1139 determine what the error was. The currently defined General Error 1140 codes and their meanings are: 1142 0 - No general error 1143 1 - No control connection exists yet for this LAC-LNS pair 1144 2 - Length is wrong 1145 3 - One of the field values was out of range or reserved field was 1146 non-zero 1147 4 - Insufficient resources to handle this operation now 1148 5 - The Call ID is invalid in this context 1149 6 - A generic vendor-specific error occurred in the LAC 1150 7 - Try another. If LAC is aware of other possible LNS 1151 destinations, it should try one of them. This can be used to 1152 guide an LAC based on LNS policy, for instance, the existence 1153 of multilink PPP bundles. 1155 If the length of the Result Code AVP specifies that the Value field 1156 is more than four octets in length, the remaining bytes after the 1157 General Error Code field are an arbitrary string providing further 1158 (possibly human readable) text associated with the condition. 1160 Generally, when a General Error Code of 6 is used, additional 1161 information about the error will be included in the Optional Message 1162 field that follows the Error Code field in the Result Code AVP. 1164 5.7 Hiding of AVP values 1166 The H ("Hidden") bit in the header of each AVP in a control message 1167 provides a mechanism to indicate to the receiving peer whether the 1168 contents of the AVP are hidden or present in cleartext. This feature 1169 can be used to hide sensitive control message data such as user 1170 passwords or user ID's. The H bit MUST NOT be set in the Random 1171 Vector AVP. 1173 The H bit MUST only be set if tunnel authentication was used and, 1174 therefore, a shared secret exists between the peers on either end of 1175 the tunnel. Therefore, the H bit MUST NOT be set in AVP's contained 1176 within the Start-Control-Connection-Request, -Reply, and -Connected 1177 messages. If the H bit is set in any AVP(s) in a given command 1178 message, a Random Vector AVP must also be present in the message and 1179 MUST precede the first AVP having an H-bit of 1. 1181 The following mechanism is applied to the contents of the value field 1182 of each AVP to which hiding is to be applied. An MD5 hash is 1183 performed on the concatenation of: 1185 - the 2 octet Attribute number of the AVP 1186 - the shared authentication secret 1187 - and an arbitrary length random vector 1189 The value of the random vector used in this hash is passed in the 1190 value field of a Random Vector AVP. This Random Vector AVP must be 1191 placed in the message by the sender before any hidden AVPs. The same 1192 random vector can be used for more than one hidden AVP in the same 1193 message. If a different random vector is used for the hiding of 1194 subsequent AVPs then a new Random Vector AVP must be placed in the 1195 command message before the first AVP to which it applies. 1197 A value to be hidden MAY be padded with additional octets to obscure 1198 its 1199 actual length. The subformat of the AVP's value is indicated below. 1200 0 1 2 3 1201 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Length | Value ... 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 ... | Padding ... 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 Length 1208 This is length of the Value to be obscured in octets. This is 1210 Value Value to be obscured 1212 Padding Random additional bytes used to obscure length of Value. 1214 The MD5 hash value is then XORed with the first 16 octet or less 1215 segment of the Value and placed in the Value field of the AVP. If 1216 the Value is less than 16 octets, the Value is transformed as if 1217 the Value field had been padded to 16 octets before the XOR, but 1218 only the actual bytes present in the Value are modified, and the 1219 length of the AVP is not altered. 1221 If the value is longer than 16 octets, a second one-way MD5 hash 1222 is calculated over a stream of octets consisting of the shared 1223 secret followed by the result of the first XOR. That hash is 1224 XORed with the second 16 octet or less segment of the value and 1225 placed in the corresponding octets of the Value field of the AVP. 1227 If necessary, this operation is repeated, with each XOR result 1228 being used along with the shared secret to generate the next hash 1229 to XOR the next segment of the value with. This technique results 1230 in the content of the AVP being obscured, although the length of 1231 the AVP is still known. 1233 On receipt, the random vector is taken from the last Random Vector 1234 AVP encountered in the message prior to the AVP to be unhidden. 1236 The above process is then reversed to yield the original value. 1237 For more details on this hiding method, consult the RADIUS [8] 1238 RFC. 1240 The Random Vector AVP has the following format: 1242 Random Vector 1244 0 1 2 3 1245 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 |1|0|0|0| 6 + String length | 0 | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | 36 | Random Octet String ... 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 The Random Vector AVP may be used in any message type. The Attribute 1253 value is 36 and it is marked mandatory. It is used to enable the 1254 hiding of the values of arbitrary AVPs. It MUST precede any AVP 1255 containing an AVP with the H-bit set but it MUST NOT itself have the 1256 H-bit set. More than one Random Vector AVP may appear in a message, 1257 in which case the one most closely preceding an AVP with the H-bit 1258 set pertains to that AVP. The Random Octet String is the random 1259 vector value to use in computing the MD5 hash to retrieve the 1260 original value of a hidden AVP. This string can be of arbitrary 1261 length, although a random vector of at least 16 octets is 1262 recommended. 1264 6.0 Control Connection Protocol Specification 1266 Control Connection messages are used to establish and clear user 1267 sessions. The first set of Control Connection messages are used to 1268 maintain the control connection itself. The control connection is 1269 initiated by an LAC or LNS after establishing the underlying tunnel- 1270 over-media connection. 1272 6.0.1 Control Connection Collision 1274 For the case where an LAC and LNS both initiate tunnels to each 1275 other concurrently, and where the LAC and LNS both determine that 1276 a single tunnel suffices (generally because of media 1277 characteristic considerations, for instance, whether individual 1278 tunnels are needed to gain QOS guarantees for each tunnel), a "tie 1279 breaker" may be undertaken. The details of breaking a tie are 1280 documented with the tunnel establishment messages (Sec. 6.1). 1282 6.0.2 Reliable Delivery of Control Messages 1284 Since L2TP may run across media where packets may be lost, an L2TP 1285 peer sending a control message will retransmit the control message 1286 after deciding that its remote peer has not received it. The 1287 reliable transport mechanism built into L2TP is essentially a 1288 lower layer transport service; the Nr and Ns fields of the control 1289 message header belong to this transport layer. The higher layer 1290 functions of L2TP are not concerned with retransmission or 1291 ordering of control messages. 1293 Each tunnel maintains a queue of control messages to be 1294 transmitted to the peer. The message at the front of the queue is 1295 sent with a given Ns value, and is held until a control message 1296 arrives from the peer in which the Nr field indicates receipt of 1297 this message. After a fixed (recommended default is 1 second) or 1298 adaptive (see Appendix D) timeout interval expires without 1299 receiving such an acknowledgment, the control message packet is 1300 retransmitted. The retransmitted packet contains the same Ns 1301 value, but the Nr value MUST be updated to reflect any packets 1302 received in the interim. 1304 If no peer response is detected after several retransmissions (a 1305 recommended default is 5, but may be altered due to media 1306 considerations), the tunnel and all sessions within MUST be 1307 cleared. 1309 When a tunnel is being shut down for reasons other than loss of 1310 connectivity, the state and reliable delivery mechanisms MUST be 1311 maintained and operated for the full retransmission interval after 1312 the final message exchange has occurred. This permits reliable 1313 delivery of closing messages in environments where these closing 1314 messages might be dropped. 1316 Unlike payload traffic, a peer MUST NOT withhold acknowledgment of 1317 packets as a technique for flow controlling control messages. An 1318 L2TP implementation is expected to be able to keep up with 1319 incoming control messages, possibly responding to some with errors 1320 reflecting an inability to honor the requested action. 1322 A sliding window mechanism is used, by default, for control 1323 message transmission. The default is to permit four control 1324 messages to be outstanding on a given tunnel. If a peer specifies 1325 a Receive Window Size AVP in the Start-Control-Connection-Request 1326 and -Reply packets, up to the indicated number of control messages 1327 may be sent and held outstanding. An implementation may only 1328 support a receive window of 1, but MUST accept at least a window 1329 of 4 from its peer. Unlike payload sessions, a value of 0 for the 1330 Receive Window Size AVP is invalid for a control session. 1332 The transport layer at a receiving peer is responsible for making 1333 sure that control messages are delivered in order to the higher 1334 layer and that duplicate messages are not delivered to the higher 1335 layer. Messages arriving out of order may be queued for in-order 1336 delivery when the missing messages are received or they may be 1337 discarded, requiring a retransmission. 1339 6.0.3 Control Message Format 1341 The following Control Connection messages are all sent as packets 1342 on the established tunnel connection between a given LNS-LAC pair. 1343 All data is sent in network order (high order octets first). Any 1344 "reserved" or "empty" fields MUST be sent as 0 values to allow for 1345 protocol extensibility. 1347 Each control message has a header, specified in section 5.2, 1348 including an AVP indicating the type of control message, followed 1349 by zero or more AVP's appropriate for the given type of control 1350 message. Each control message is described first at a block 1351 level, and then with details of each AVP. 1353 6.1 Start-Control-Connection-Request (SCCRQ) 1355 The Start-Control-Connection-Request is an L2TP control message used 1356 to initialize the tunnel between an LNS and an LAC. The tunnel must 1357 be initialized through the exchange of these control messages before 1358 any other L2TP messages can be issued. The establishment of the 1359 control connection is started by the initiator of the underlying 1360 tunnel. 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | L2TP Control Message Header | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Start-Control-Connection-Request | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Protocol Version | 1368 | Framing Capabilities | 1369 | Bearer Capabilities | 1370 | Tie Breaker | 1371 | Firmware Revision | 1372 | Host Name | 1373 | Vendor Name | 1374 | Assigned Tunnel ID | 1375 | Receive Window Size | 1376 | Challenge | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+ 1379 Start-Control-Connection-Request 1381 0 1 2 3 1382 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 |1|0|0|0| 8 | 0 | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | 0 | 1 | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 The Message Type AVP contains a Value of 1, indicating Start- 1390 Control-Connection-Request. The Flags indicate a mandatory 1391 option. Details associated with this tunneled session follow in 1392 additional AVP's within the packet. 1394 Protocol Version 1396 0 1 2 3 1397 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 |1|0|0|0| 8 | 0 | 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | 2 | 0x01 | 0x00 | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 The Protocol Version AVP within a Start-Control-Connection-Request 1405 packet indicates the L2TP protocol version available. The 1406 Attribute value is 2, indicating Protocol Version, and is marked 1407 mandatory. This AVP MUST be present. The Value field is a 16-bit 1408 hexadecimal value 0x100, indicating L2TP protocol version 1, 1409 revision 0. 1411 Framing Capabilities 1413 0 1 2 3 1414 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 |1|0|0|0| 10 | 0 | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | 3 | 0x00 | 0x00 | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | 0x00 |0|0|0|0|0|0|A|S| 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 The Framing Capabilities AVP within a Start-Control-Connection- 1424 Request indicates the type of framing that the sender of this 1425 message can provide. The Attribute value is 3, indicating Framing 1426 Capabilities, and is marked mandatory. This AVP MUST be present. 1427 The Value field is a 32-bit quantity, with two bits defined. If 1428 bit A is set, asynchronous framing is supported. If bit S is set, 1429 synchronous framing is supported. 1431 Bearer Capabilities 1433 0 1 2 3 1434 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 |1|0|0|0| 10 | 0 | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | 4 | 0x00 | 0x00 | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | 0x00 |0|0|0|0|0|0|A|D| 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 The Bearer Capabilities AVP within a Start-Control-Connection- 1444 Request indicates the bearer capabilities that the sender of this 1445 message can provide. The Attribute value is 4, indicating Bearer 1446 Capabilities, and is marked mandatory. This AVP MUST be present. 1447 The Value field is a 32-bit quantity with two bits defined. If 1448 bit A is set, analog access is supported. If bit D is set, 1449 digital access is supported. 1451 Tie Breaker 1453 0 1 2 3 1454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 |0|0|0|0| 14 | 0 | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | 5 | Tie Break Value... | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Value... | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | ...(64 bits) | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 The Tie Breaker AVP within a Start-Control-Connection-Request 1466 contains a 64-bit Value used to break ties in tunnel establishment 1467 between an LAC-LNS pair. The Attribute value is 5, indicating Tie 1468 Breaker, and is marked optional. This AVP itself is optional. 1469 The 8 byte Value is used as a 64-bit tie breaker value. 1471 If present, it indicates the sender wishes a single tunnel to 1472 exist between the given LAC-LNS pair, and this value will be used 1473 to choose a single tunnel where both LAC and LNS initiate a tunnel 1474 concurrently. The recipient of a Start-Control-Connection-Request 1475 must check to see if a Start-Control-Connection-Request has been 1476 sent to the peer, and if so, must compare its Tie Breaker value 1477 with the received one. The lower value "wins", and the "loser" 1478 MUST initiate a tunnel disconnect for their outstanding tunnel. 1479 In the case where a tie breaker is present on both sides, and the 1480 value is equal, both sides MUST initiate tunnel disconnects. 1482 If a tie breaker is received, and the outstanding Start-Control- 1483 Connection-Request had no tie breaker value, the initiator which 1484 included the Tie Breaker AVP "wins". 1486 It is recommended that the Value be set to the MAC address of a 1487 LAN interface on the sender. If no MAC address is available, a 1488 64-bit random number should be used instead. 1490 Firmware Revision 1492 0 1 2 3 1493 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 |0|0|0|0| 8 | 0 | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | 6 | Firmware Revision | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 The Firmware Revision AVP within a Start-Control-Connection- 1501 Request indicates the firmware revision of the issuing device. 1503 The Attribute value is 6, indicating Firmware Revision, and is 1504 marked optional. This AVP itself is optional. The Value field is 1505 a 16-bit integer encoded in a vendor specific format. For devices 1506 which do not have a firmware revision (general purpose computers 1507 running L2TP software modules, for instance), the revision of the 1508 L2TP software module may be reported instead. 1510 Host Name 1512 0 1 2 3 1513 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 |1|0|0|0| 6 + Host name length | 0 | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | 7 | Host name... 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 The Host Name AVP within a Start-Control-Connection-Request 1521 indicates the name of the issuing LAC or LNS. The Attribute value 1522 is 7, indicating Host Name, and is marked mandatory. This AVP 1523 itself MUST be present. This name should be as broadly unique as 1524 possible; for hosts participating in DNS [4], a hostname with 1525 fully qualified domain would be appropriate. 1527 Vendor Name 1529 0 1 2 3 1530 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 |0|0|0|0|6 + vendor name length | 0 | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | 8 | Vendor name... 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 The Vendor Name AVP within a Start-Control-Connection-Request 1538 contains a vendor specific string describing the type of LAC or 1539 LNS being used. The Attribute value is 8, indicating Vendor Name, 1540 and is marked optional. This AVP itself is optional. The Value 1541 is the indicated number of bytes representing the vendor string. 1543 Assigned Tunnel ID 1545 0 1 2 3 1546 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 |1|0|0|0| 8 | 0 | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | 9 | Tunnel ID | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 The Assigned Tunnel ID AVP within a Start-Control-Connection- 1554 Request specifies the Tunnel ID which the receiving peer MUST use 1555 in the Tunnel ID field of all subsequent packets. The Attribute 1556 value is 9, indicating Assigned Tunnel ID, and is marked 1557 mandatory. This AVP MUST be present. Before the Assigned Tunnel 1558 ID AVP is received, packets MUST be sent with a Tunnel ID value of 1559 0. The Value is a 16-bit non-zero Tunnel ID value. 1561 Receive Window Size 1563 0 1 2 3 1564 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 |1|0|0|0| 8 | 0 | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | 10 | Size | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 The Receive Window Size AVP within a Start-Control-Connection- 1572 Request specifies the receive window size being offered to the 1573 remote peer. The Attribute value is 10, indicating Receive Window 1574 Size, and is mandatory. This AVP itself is optional. Value is a 1575 16-bit word indicating the offered window size. If absent, the 1576 peer must assume a value of 4 for its transmit window. The remote 1577 peer may send the specified number of control messages before it 1578 must wait for an acknowledgment. 1580 Challenge 1582 0 1 2 3 1583 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 |1|0|0|0| 6 + Challenge length | 0 | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | 11 | Challenge... 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 The Challenge AVP within a Start-Control-Connection-Request 1591 indicates that the issuing peer wishes to authenticate the tunnel 1592 endpoints using a CHAP-style authentication mechanism. The 1593 Attribute value is 11, indicating Challenge, and is marked 1594 mandatory. This AVP is optional. The Value is one or more octets 1595 of challenge value. 1597 6.2 Start-Control-Connection-Reply (SCCRP) 1599 The Start-Control-Connection-Reply is an L2TP control message sent in 1600 reply to a received Start-Control-Connection-Request message. This 1601 message contains a result code indicating the result of the control 1602 connection establishment attempt. 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | L2TP Control Message Header | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Start-Control-Connection-Reply | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | Protocol Version | 1610 | Result Code | 1611 | Framing Capabilities | 1612 | Bearer Capabilities | 1613 | Firmware Revision | 1614 | Host Name | 1615 | Vendor Name | 1616 | Assigned Tunnel ID | 1617 | Receive Window Size | 1618 | Challenge | 1619 | Challenge Response | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+ 1622 Start-Control-Connection-Reply 1624 0 1 2 3 1625 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 |1|0|0|0| 8 | 0 | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | 0 | 2 | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 The Message Type AVP contains a Value of 2, indicating Start- 1633 Control-Connection-Reply. The Flags indicate a mandatory option. 1635 Protocol Version 1637 0 1 2 3 1638 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 |1|0|0|0| 8 | 0 | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | 2 | 0x01 | 0x00 | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 The Protocol Version AVP within a Start-Control-Connection-Reply 1646 packet indicates the L2TP protocol version available. The 1647 Attribute value is 2, indicating Protocol Version, and the Value 1648 field is a 16-bit hexadecimal value 0x100, indicating L2TP 1649 protocol version 1, revision 0. This AVP MUST be present. 1651 Framing Capabilities 1653 0 1 2 3 1654 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 |1|0|0|0| 10 | 0 | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | 3 | 0x00 | 0x00 | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | 0x00 |0|0|0|0|0|0|A|S| 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 The Framing Capabilities AVP within a Start-Control-Connection- 1664 Reply indicates the type of framing that the sender of this 1665 message can provide. The Attribute is 3, it is a mandatory AVP, 1666 the Value field is a 32-bit quantity, with two bits defined. If 1667 bit A is set, asynchronous framing is supported. If bit S is set, 1668 synchronous framing is supported. This AVP MUST be present if the 1669 Result AVP indicates success. 1671 Bearer Capabilities 1673 0 1 2 3 1674 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 |1|0|0|0| 10 | 0 | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | 4 | 0x00 | 0x00 | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | 0x00 |0|0|0|0|0|0|A|D| 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 The Bearer Capabilities AVP within a Start-Control-Connection- 1684 Reply indicates the bearer capabilities that the sender of this 1685 message can provide. The Attribute is 4, it is a mandatory AVP, 1686 the Value field is a 32-bit quantity with two bits defined. If 1687 bit A is set, analog access is supported. If bit D is set, 1688 digital access is supported. This AVP MUST be present if the 1689 Result AVP indicates success. 1691 Firmware Revision 1693 0 1 2 3 1694 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 |0|0|0|0| 8 | 0 | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | 6 | Firmware Revision | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 The Firmware Revision AVP within a Start-Control-Connection-Reply 1702 indicates the firmware revision of the issuing device. The 1703 Attribute is 6, it is not a mandatory AVP, the Value field is a 1704 16-bit integer encoded in a vendor specific format. For devices 1705 which do not have a firmware revision (general purposes computers 1706 running L2TP software modules, for instance), the revision of the 1707 L2TP software module may be reported instead. This AVP is 1708 optional. 1710 Host Name 1712 0 1 2 3 1713 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 |1|0|0|0| 6 + Host name length | 0 | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | 7 | Host name... 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 The Host Name AVP within a Start-Control-Connection-Reply 1720 indicates the name of the issuing LAC or LNS. See the notes in 1721 section 6.1 concerning Host Name contents. It is encoded as the 1722 Attribute 7, mandatory, with the indicated number of bytes 1723 representing the host name string. This AVP MUST be present. 1725 Vendor Name 1727 0 1 2 3 1728 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 |0|0|0|0|6 + Vendor name length | 0 | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | 8 |Vendor name... 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 The Vendor Name AVP within a Start-Control-Connection-Reply 1736 contains a vendor specific string describing the type of LAC or 1737 LNS being used. It is encoded as the Attribute 8, not mandatory, 1738 with the indicated number of bytes representing the vendor string. 1739 This AVP is optional. 1741 Assigned Tunnel ID 1743 0 1 2 3 1744 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 |1|0|0|0| 8 | 0 | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | 9 | Tunnel ID | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply 1752 specifies the Tunnel ID which the receiving peer MUST use in all 1753 subsequent packets. It is encoded as the Attribute 9, mandatory, 1754 with a 16-bit non-zero Tunnel ID value. This AVP MUST be present 1755 if the Result Code indicates "Successful channel establishment". 1757 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 Reply 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 Result Code 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| 10 + Message length | 0 | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | 1 | Result Code | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 | Error Code | Optional Message ... 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 The Result Code AVP within a Start-Control-Connection-Reply packet 1789 indicates the result of the control channel establishment attempt. 1790 It is encoded as Attribute 1, indicating a Result Code AVP. This 1791 AVP is mandatory and MUST be present. The Result Code is a 16-bit 1792 word. The 16-bit word following the Result Code field contains 1793 the Error Code value. The Result Code value indicates whether the 1794 Error Code value is meaningful or not. If it is not meaningful it 1795 MUST be set to a value of 0. An optional error message can follow 1796 the Error Code field. Its presence and length is indicated by the 1797 value of the AVP length field. 1799 Result code values are: 1800 1 - Successful channel establishment 1801 2 - General error--Error Code indicates the problem 1802 3 - Control channel already exists 1803 4 - Requester is not authorized to establish a control channel 1804 5 - The protocol version of the requester is not supported 1806 Challenge 1808 0 1 2 3 1809 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 |1|0|0|0| 6 + Challenge length | 0 | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | 11 | Challenge... 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 The Challenge AVP within a Start-Control-Connection-Reply 1817 indicates that the peer wishes to authenticate the tunnel 1818 initiator using a CHAP-style authentication mechanism. It is 1819 encoded as the Attribute 11, mandatory, with at least one byte of 1820 challenge value embedded. If this AVP is not present, it 1821 indicates to the receiving peer that the sender does not wish to 1822 authenticate that peer. 1824 Challenge Response 1826 0 1 2 3 1827 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 |1|0|0|0| 22 | 0 | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | 13 | Response... | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | Response... (128 bits) | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 The Response AVP within a Start-Control-Connection-Reply packet 1837 provides a response to a challenge received. The Attribute value 1838 is 13, indicating Response, and the Value field is a 128-bit value 1839 reflecting the CHAP-style response to the challenge. This AVP 1840 marked mandatory, and MUST be present if a challenge was received 1841 and this Start-Control-Connection-Reply indicates success. For 1842 purposes of the ID value in the CHAP response calculation, the 1843 value 2 (corresponding to the Value field of the Start-Control- 1844 Connection-Reply AVP) MUST be used. 1846 6.3 Start-Control-Connection-Connected (SCCCN) 1848 The Start-Control-Connection-Connected message is an L2TP control 1849 message sent in reply to a received Start-Control-Connection-Reply 1850 message. This message provides closure to the tunnel establishment 1851 process, and includes a challenge response if the peer sent a 1852 challenge in the Start-Control-Connection-Reply message. 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | L2TP Control Message Header | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Start-Control-Connection-Connected | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | Challenge Response | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+ 1862 Start-Control-Connection-Connected 1864 0 1 2 3 1865 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 |1|0|0|0| 8 | 0 | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | 0 | 3 | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 The Message Type AVP contains a Value of 3, indicating Start- 1873 Control-Connection-Connected. The Flags indicate a mandatory 1874 option. 1876 Challenge Response 1878 0 1 2 3 1879 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 |1|0|0|0| 22 | 0 | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | 13 | Response... | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | Response... (128 bits) | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 The Challenge Response AVP within a Start-Control-Connection- 1889 Connected packet provides a response to a challenge received. The 1890 Attribute value is 13, indicating Response, and the Value field is 1891 a 128-bit value reflecting the CHAP-style response to the 1892 challenge. This AVP is marked mandatory, and MUST be present if a 1893 challenge was received, otherwise MUST be omitted. For purposes 1894 of the ID value in the CHAP response calculation, the value 3 1895 (corresponding to the Value field of the Start-Control- 1896 Connection-Connected AVP) MUST be used. 1898 6.4 Stop-Control-Connection-Notification (StopCCN) 1900 The Stop-Control-Connection-Notification is an L2TP control message 1901 sent by one peer of an LAC-LNS control connection to inform the other 1902 peer that the control connection should be closed. In addition to 1903 closing the control connection, all active user calls are implicitly 1904 cleared. The reason for issuing this request is indicated in the 1905 Result Code AVP. 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | L2TP Control Message Header | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | Stop-Control-Connection-Notification| 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | Assigned Tunnel ID | 1913 | Result Code | 1914 +-+-+-+-+-+-+-+-+-+-+-+-+ 1916 Stop-Control-Connection-Notification AVP 1918 0 1 2 3 1919 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 |1|0|0|0| 8 | 0 | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | 0 | 4 | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 The Message Type AVP contains a Value of 4, indicating Stop- 1927 Control-Connection-Notification. The Flags indicate a mandatory 1928 option. 1930 Assigned Tunnel ID 1932 0 1 2 3 1933 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 |1|0|0|0| 8 | 0 | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | 9 | Tunnel ID | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 The Attribute value is 9, indicating Assigned Tunnel ID, and is 1941 marked mandatory. This AVP MUST be present. The Value MUST be 1942 the same Assigned Tunnel ID first sent to the receiving peer. 1943 This AVP permits the peer to identify the appropriate tunnel even 1944 if Stop-Control-Connection-Notification must be sent before an 1945 Assigned Tunnel ID is received. 1947 Result Code 1949 0 1 2 3 1950 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 |1|0|0|0| 10 + Message length | 0 | 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 | 1 | Result Code | 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | Error Code | Optional Message ... 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 The Result Code AVP within a Stop-Control-Connection-Notification 1960 packet indicates the reason for terminating the control channel. 1961 It is encoded as Attribute 1, indicating a Result Code AVP. This 1962 AVP is mandatory and MUST be present. The Result Code is a 16-bit 1963 word. The 16-bit word following the Result Code field contains 1964 the Error Code value, which for a Stop-Control-Connection- 1965 Notification is always 0. An optional message can follow the 1966 Error Code field. Its presence and length is indicated by the 1967 value of the AVP length field. Defined Result Code values are: 1969 1 - General request to clear control connection 1970 2 - General error--Error Code indicates the problem 1971 3 - Control channel already exists 1972 4 - Requester is not authorized to establish a control channel 1973 5 - The protocol version of the requester is not supported 1974 Error Code indicates highest version supported 1975 6 - Requester is being shut down 1976 7 - Finite State Machine error 1978 6.5 (reserved) 1980 The function previously described here has been deleted from L2TP. 1982 6.6 Hello 1984 The Hello message is an L2TP control message sent by either peer of a 1985 LAC-LNS control connection. This control message is used as a 1986 "keepalive" for the tunnel. 1988 Keepalives should be implemented by sending a Hello once every 60 1989 seconds if 60 seconds have passed without receiving any message 1990 (payload or control, including zero-length messages) from the peer. 1991 When a Hello is received, it MUST be silently discarded (after 1992 updating any effects of the indicated Nr/Ns values). 1994 Because a Hello is a control message, and control messages are 1995 reliably sent by the lower level transport, this keepalive function 1996 operates by causing the transport level to reliably deliver a 1997 message. If a media interruption has occurred, the reliable 1998 transport will be unable to deliver the Hello across, and will clean 1999 up the tunnel. 2001 Hello messages are global to the tunnel; the Call ID field of these 2002 control messages MUST be 0. 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | L2TP Control Message Header | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | Hello | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 Hello 2012 0 1 2 3 2013 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 |1|0|0|0| 8 | 0 | 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | 0 | 6 | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 The Message Type AVP contains a Value of 6, indicating Hello The 2021 Flags indicate a mandatory option. 2023 6.7 Outgoing-Call-Request (OCRQ) 2025 The Outgoing-Call-Request is an L2TP control message sent by the LNS 2026 to the LAC to indicate that an outbound call from the LNS is to be 2027 established. This request provides the LAC with information required 2028 to make the call. It also provides information to the LAC that is 2029 used to regulate the transmission of data to the LNS for this session 2030 once it is established. 2032 This message is the first in the "three-way handshake" used by L2TP 2033 for establishing outgoing calls. The first message requests the 2034 call; the second indicates that the call was successfully initiated. 2035 The third and final message indicates that the call was established. 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | L2TP Control Message Header | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | Outgoing-Call-Request | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | Assigned Call ID | 2043 | Call Serial Number | 2044 | Minimum BPS | 2045 | Maximum BPS | 2046 | Bearer Type | 2047 | Framing Type | 2048 | Receive Window Size | 2049 | Packet Processing Delay | 2050 | Dialed Number | 2051 | Sub-Address | 2052 | Private Group ID | 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 Outgoing-Call-Request 2057 0 1 2 3 2058 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 |1|0|0|0| 8 | 0 | 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | 0 | 7 | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 The Message Type AVP contains a Value of 7, indicating Outgoing- 2066 Call-Request. The Outgoing-Call-Request encodes a request to an 2067 LAC to establish an outgoing call. The flags indicate a mandatory 2068 option. 2070 Assigned Call ID 2072 0 1 2 3 2073 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 |1|0|0|0| 8 | 0 | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | 14 | Call ID | 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 The Assigned Call ID AVP encodes the ID being assigned to this 2081 call by the LNS. The Attribute value is 14, indicating Assigned 2082 Call ID, and is marked mandatory. This AVP MUST be present. The 2083 LAC places this value in the Call ID header field of all command 2084 and payload packets that it subsequently transmits over the tunnel 2085 that belong to this call. The Call ID value is an identifier 2086 assigned by the LNS to this session. It is used to multiplex and 2087 demultiplex data sent over that tunnel between the LNS and LAC. 2089 Call Serial Number 2091 0 1 2 3 2092 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 |1|0|0|0| 6 + Number length | 0 | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | 15 | Number... 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 Call Serial Number AVP encodes an identifier assigned by the LNS to 2101 this call. 2102 Attribute is 15, indicating Call Serial Number, and is marked mandatory. 2103 This AVP MUST be present. 2104 The Call Serial Number is intended 2105 to be an easy reference for administrators on both ends of a tunnel to use 2106 when investigating call failure problems. Call Serial Numbers should 2107 be set to progressively increasing values, which are likely to be unique for 2108 a significant period of time across all interconnected LNS and LACs. Other 2109 identification information may also be prepended. 2111 Minimum BPS 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 | 0 | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | 16 | BPS (H) | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 | BPS (L) | 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 Minimum BPS AVP encodes the lowest acceptable line speed for this 2124 call. Attribute is 16, Minimum BPS, and is marked mandatory. 2125 This AVP MUST be present. The BPS value indicates the speed in 2126 bits/second. 2128 Maximum BPS 2130 0 1 2 3 2131 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 |1|0|0|0| 10 | 0 | 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | 17 | BPS (H) | 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | BPS (L) | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 Maximum BPS AVP encodes the highest acceptable line speed for this 2141 call. Attribute is 17, indicating Maximum BPS, and is marked 2142 mandatory. This AVP MUST be present. The BPS value indicates the 2143 speed in bits/second. 2145 Bearer Type 2147 0 1 2 3 2148 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 |1|0|0|0| 10 | 0 | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 Bearer Type AVP encodes the bearer type for the requested call. 2158 The value bit field Attribute is 18, indicating Bearer Type, and 2159 is marked mandatory. This AVP MUST be present. The Value is a 2160 32-bit quantity indicating the bearer capability required for this 2161 outgoing call. If set, bit A indicates that the call should be on 2162 an analog channel. If set, bit D indicates that the call should 2163 be on a digital channel. Both may be set, indicating that the 2164 call can be of either type. 2166 Framing Type 2168 0 1 2 3 2169 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 |1|0|0|0| 10 | 0 | 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 Framing Type AVP encodes the framing type for the requested call. 2179 Attribute is 19, indicating Framing Type, and is marked mandatory. 2180 This AVP MUST be present. The 32-bit field indicates the type of 2181 PPP framing to be used for the outgoing call. Bit A if set 2182 indicates that asynchronous framing should be used. Bit S is set 2183 indicates that synchronous framing should be used. 2185 Receive Window Size 2187 0 1 2 3 2188 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 |1|0|0|0| 8 | 0 | 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 | 10 | Size | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 Receive Window Size AVP encodes the window size being advertised 2196 by the LNS for this call. Attribute is 10, indicating Receive 2197 Window Size, and is marked mandatory. This AVP is optional. The 2198 Size value indicates the number of received data packets the LNS 2199 will buffer for this call, which is also the maximum number of 2200 data packets the LAC should send before waiting for an 2201 acknowledgment. The absence of this AVP indicates that Sequence 2202 and Acknowledgment Numbers are not to be used in the payload 2203 session for this call. 2205 Packet Processing Delay 2206 0 1 2 3 2207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 |1|0|0|0| 8 | 0 | 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 | 20 | Delay | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 The Packet Processing Delay AVP encodes the delay LNS has for 2215 processing a window full of packets sent by the LAC. Attribute is 2216 20, indicating Packet Processing Delay, and is marked mandatory. 2217 This AVP is optional. The Delay value is specified in units of 2218 1/10 seconds. Refer to Appendix A for a description of how this 2219 value is determined and used. 2221 Dialed Number 2223 0 1 2 3 2224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 |1|0|0|0|6 + Phone Number length| 0 | 2227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2228 | 21 | Phone Number.. 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 Phone Number AVP encodes the phone number to be called. Attribute 2232 is 21, indicating Phone Number, and is marked mandatory. This AVP 2233 MUST be present. The Phone Number value is an ASCII string. 2235 Sub-Address 2237 0 1 2 3 2238 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 |1|0|0|0|6 + Sub-Address length | 0 | 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | 23 |Sub-Address ... 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 Sub-Address AVP encodes additional dialing information. Attribute 2246 is 23, indicating Sub-Address, and is marked mandatory. This AVP 2247 is optional. The Sub-Address value is an ASCII string. 2249 Private Group ID 2251 0 1 2 3 2252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 |1|0|0|0| 6 + Private Group ID | 0 | 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 | 37 | Private Group ID ... 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 The Private Group ID AVP is sent by the LNS to the LAC to indicate 2260 that a particular call is to be treated specially, for example, to 2261 select a particular port group or exchange carrier. The Attribute 2262 is 37, Private Group ID, and is marked optional. The presence of 2263 this AVP is optional. The Private Group ID is a string 2264 corresponding to a table in the LAC that defines the particular 2265 characteristics of the selected group. 2267 6.8 Outgoing-Call-Reply (OCRP) 2269 The Outgoing-Call-Reply is an L2TP control message sent by the LAC to 2270 the LNS in response to a received Outgoing-Call-Request message. The 2271 reply indicates whether or not the LAC is able to attempt the 2272 outbound call and also returns certain parameters regarding the call 2273 attempt. 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | L2TP Control Message Header | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 | Outgoing-Call-Reply | 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 | Assigned Call ID | 2281 | Result Code | 2282 | Connect Speed | 2283 | Physical Channel Id | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 Outgoing-Call-Reply 2288 0 1 2 3 2289 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 |1|0|0|0| 8 | 0 | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | 0 | 8 | 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 The Message Type AVP contains a Value of 8, indicating Outgoing- 2297 Call-Reply. The Outgoing-Call-Reply message encodes the immediate 2298 result of attempting an outgoing call request. The flags indicate a 2299 mandatory option. 2301 Assigned Call ID 2303 0 1 2 3 2304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 |1|0|0|0| 8 | 0 | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | 14 | Call ID | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 The Assigned Call ID AVP encodes the ID being assigned to this call 2312 by the LAC. Attribute is 14, indicating Assigned Call ID, and is 2313 marked mandatory. This AVP MUST be present if the Result Code 2314 indicates a call is in progress. Call ID value is an identifier, 2315 unique within the tunnel, assigned by the sender to this session. 2316 The remote peer MUST place this Call ID in the Call ID portion of all 2317 future packets it sends associated with this session. It is used to 2318 multiplex and demultiplex data sent over that tunnel between the LNS 2319 and LAC. 2321 Result Code 2323 0 1 2 3 2324 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 |1|0|0|0| 10 + Message length | 0 | 2327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 | 1 | Result Code | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 | Error Code | Optional Message ... 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 The Result Code AVP within an Outgoing-Call-Request indicates the 2334 result of the outgoing call establishment attempt. It is encoded 2335 as Attribute 1, indicating a Result Code AVP. This AVP is 2336 mandatory and MUST be present. The Result Code is a 16-bit word. 2337 The 16-bit word following the Result Code field contains the Error 2338 Code value. The Result Code value indicates whether the Error 2339 Code value is meaningful or not. If it is not meaningful it 2340 should be set to a value of 0. An optional error message can 2341 follow the Error Code field. Its presence and length is indicated 2342 by the value of the AVP length field. Defined Result Code values 2343 are: 2345 1 - Call attempt in progress 2346 2 - Outgoing Call not attempted for the reason indicated in Error Code 2347 3 - No appropriate facilities are available (temporary condition) 2348 4 - No appropriate facilities are available (permanent condition) 2349 5 - Invalid destination 2350 6 - Outgoing Call administratively prohibited 2352 Connect Speed 2354 0 1 2 3 2355 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 |1|0|0|0| 10 | 0 | 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 | 24 | BPS (H) | 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 | BPS (L) | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 Connect Speed BPS AVP encodes the speed of the facility chosen for 2365 the connection attempt. The Attribute value is 24, indicating 2366 Connect Speed, and is marked mandatory. This AVP MUST be present 2367 if the Result indicates a call is in progress. The BPS is a 32- 2368 bit value indicating the speed in bits/second. 2370 Physical Channel ID 2372 0 1 2 3 2373 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 |1|0|0|0| 10 | 0 | 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 | 25 | ID (H) | 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 | ID (L) | 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 Physical Channel ID AVP encodes the vendor specific physical 2383 channel number used for the call. The Attribute value is 25, 2384 indicating Physical Channel ID, and is marked optional. This AVP 2385 itself is optional. ID is a 32-bit value in network byte order. 2386 The value is used for logging purposes only. 2388 6.9 Outgoing-Call-Connected (OCCN) 2390 Outgoing-Call-Connected is an L2TP control message sent by the LAC to 2391 the LNS to indicate the result of a requested outgoing call. The LAC 2392 MUST send the corresponding Outgoing-Call-Reply to the LNS before 2393 sending this message. This message provides information to the LNS 2394 about the particular parameters used for the call. It provides 2395 information to allow the LNS to regulate the transmission of data to 2396 the LAC for this session. 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | L2TP Control Message Header | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Outgoing-Call-Connected | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 | Result Code | 2404 | Q.931 Cause Code | 2405 | Connect Speed | 2406 | Framing Type | 2407 | Receive Window Size | 2408 | Packet Processing Delay | 2409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 Outgoing-Call-Connected 2413 0 1 2 3 2414 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 |1|0|0|0| 8 | 0 | 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 | 0 | 9 | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 The Message Type AVP contains a Value of 9, indicating Outgoing- 2421 Call-Connected. The Outgoing-Call-Connected message encodes the 2422 final result of an outgoing call request. The flags indicate a 2423 mandatory option. 2425 Result Code 2427 0 1 2 3 2428 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 |1|0|0|0| 10 + Message length | 0 | 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | 1 | Result Code | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | Error Code | Optional Message ... 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2437 The Result Code AVP within an Outgoing-Call-Connected message 2438 indicates the final result of the outgoing call establishment 2439 attempt. It is encoded as Attribute 1, indicating a Result Code 2440 AVP. This AVP is mandatory and MUST be present. The Result Code 2441 is a 16-bit word. The 16-bit word following the Result Code field 2442 contains the Error Code value. The Result Code value indicates 2443 whether the Error Code value is meaningful or not. If it is not 2444 meaningful it should be set to a value of 0. An optional error 2445 message can follow the Error Code field. Its presence and length 2446 is indicated by the value of the AVP length field. Defined Result 2447 Code values are: 2449 1 - Call established with no errors 2450 2 - Outgoing Call not established for the reason indicated in Error Code 2451 3 - Outgoing Call failed due to no carrier detected 2452 4 - Outgoing Call failed due to detection of a busy signal 2453 5 - Outgoing Call failed due to lack of a dial tone 2454 6 - Outgoing Call was not established within time allotted by LAC 2455 7 - Outgoing Call was connected but no appropriate framing was detected 2457 Q.931 Cause Code 2459 0 1 2 3 2460 0 1 2 3 4 5 6 7 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 |0|0|0|0|9 + Advisory Msg length| 0 | 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 | 12 | Cause Code | 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 | Cause Msg |Advisory Msg... 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 The Q.931 Cause Code AVP is used to give additional information in 2470 cases of call failure. The Attribute value is 12, indicating 2471 Cause Code, and is marked mandatory. This AVP is optional. It is 2472 only relevant when the LAC uses Q.931/DSS1 for the outbound call 2473 attempt. Cause Code is the returned Q.931 Cause code and Cause 2474 Msg is the returned Q.931 message code (e.g., DISCONNECT) 2475 associated with the Cause Code. Both values are returned in their 2476 native ITU encodings. An additional ASCII text Advisory Message 2477 may also be included (presence indicated by the AVP length) to 2478 further explain the call failure. 2480 Connect Speed 2482 0 1 2 3 2483 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 |1|0|0|0| 10 | 0 | 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 | 24 | BPS (H) | 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 | BPS (L) | 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 Connect Speed BPS AVP encodes the final negotiated speed for the 2493 connection. The Attribute value is 24, indicating Connect Speed, 2494 and is marked mandatory. This AVP MUST be present if the call 2495 attempt is successful. The BPS value indicates the speed in 2496 bits/second. 2498 Framing Type 2500 0 1 2 3 2501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 |1|0|0|0| 10 | 0 | 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 Framing Type AVP encodes the framing type for the call. The 2511 Attribute value is 19, indicating Framing Type, and is marked 2512 mandatory. This AVP MUST be present if the call attempt is 2513 successful. The value bit field indicates the type of PPP framing 2514 is used for the call. If set, bit A indicates that asynchronous 2515 framing is being used. If set, bit S indicates that synchronous 2516 framing is being used. 2518 Receive Window Size 2520 0 1 2 3 2521 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 |1|0|0|0| 8 | 0 | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 | 10 | Size | 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 Receive Window Size AVP encodes the window size being offered by 2528 the LNS for this call. The Attribute value is 10, indicating 2529 Receive Window Size, and is marked mandatory. The Size is a 16- 2530 bit value indicating the number of received data packets the LAC 2531 will buffer for this call, which is also the maximum number of 2532 data packets the LNS should send before waiting for an 2533 acknowledgment. This AVP MUST be present if and only if Sequence 2534 and Acknowledgment Numbers are to be used in the payload session 2535 for this call. 2537 Packet Processing Delay 2539 0 1 2 3 2540 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2542 |1|0|0|0| 8 | 0 | 2543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2544 | 20 | Delay | 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 Packet Processing Delay AVP encodes the delay the LAC expects for 2548 processing a window full of packets sent by the LNS. The 2549 Attribute value is 20, indicating Packet Processing Delay, and is 2550 marked mandatory. This AVP is optional. The Delay value is 2551 specified in units of 1/10 seconds. Refer to Appendix A to see a 2552 description of how this value is determined and used. 2554 6.10 Incoming-Call-Request (ICRQ) 2556 Incoming-Call-Request is an L2TP control message sent by the LAC to 2557 the LNS to indicate that an inbound call is to be established from 2558 the LAC. This request provides the LNS with parameter information 2559 for the incoming call. 2561 This message is the first in the "three-way handshake" used by L2TP 2562 for establishing incoming calls. The LAC may defer answering the 2563 call until it has received an Incoming-Call-Reply from the LNS 2564 indicating that the call should be established. This mechanism 2565 allows the LNS to obtain sufficient information about the call before 2566 it is answered to determine whether the call should be answered or 2567 not. Alternatively, the LAC may answer the call, negotiate LCP and 2568 PPP authentication, and use the information gained to choose the LNS. 2569 In this case, the call has already been answered by the time the 2570 Incoming-Call-Reply message is received; the LAC simply spoofs the 2571 "call indication/answer call" phase in this case. 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2574 | L2TP Control Message Header | 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 | Incoming-Call-Request | 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | Assigned Call ID | 2579 | Call Serial Number | 2580 | Bearer Type | 2581 | Physical Channel ID | 2582 | Dialed Number | 2583 | Dialing Number | 2584 | Sub-Address | 2585 | Private Group ID | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 Incoming-Call-Request 2590 0 1 2 3 2591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 |1|0|0|0| 8 | 0 | 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | 0 | 10 | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 The Message Type AVP contains a Value of 10, indicating Incoming- 2599 Call-Request. The Incoming-Call-Request message encodes an incoming 2600 call being indicated by the LAC. The flags indicate a mandatory 2601 option. 2603 Assigned Call ID 2605 0 1 2 3 2606 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 |1|0|0|0| 8 | 0 | 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | 14 | Call ID | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 The Assigned Call ID AVP encodes the Call ID being assigned to call 2614 by the LAC. The Attribute value is 14, indicating Call ID, and is 2615 marked mandatory. This AVP MUST be present. The LNS places this 2616 value in the Call ID header field of all command and payload packets 2617 that it subsequently transmits over the tunnel that belong to this 2618 call. The Call ID value is an identifier assigned by the LAC to this 2619 session. It is used to multiplex and demultiplex data sent over that 2620 tunnel between the LNS and LAC. 2622 Call Serial Number 2624 0 1 2 3 2625 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 |1|0|0|0| 6 + Number length | 0 | 2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2629 | 15 | Number... 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 Call Serial Number AVP encodes an identifier assigned by the LAC to 2633 this call. The Attribute value is 15, Call Serial Number, and is 2634 marked mandatory. This AVP MUST be present. Please refer to the 2635 description of this field from section 6.8. 2637 Bearer Type 2639 0 1 2 3 2640 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 |1|0|0|0| 10 | 0 | 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2649 Bearer Type AVP encodes the bearer type for the incoming call. The 2650 Attribute value is 18, Bearer Type, and is marked mandatory. This 2651 AVP MUST be present. The Value is a 32-bit field indicating the 2652 bearer capability being used by the incoming call. If set, bit A 2653 indicates that the call is on an analog channel. If set, bit D 2654 indicates that the call is on a digital channel. 2656 Physical Channel ID 2658 0 1 2 3 2659 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 |1|0|0|0| 10 | 0 | 2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2663 | 25 | ID (H) | 2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2665 | ID (L) | 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 Physical Channel ID AVP encodes the vendor specific physical channel 2669 number used for the call. The Attribute value is 25, Physical 2670 Channel ID, and is marked mandatory. The presence of this AVP is 2671 optional. ID is a 32-bit value in network byte order. The value is 2672 used for logging purposes only. 2674 Dialed Number 2676 0 1 2 3 2677 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2679 |1|0|0|0|6 + Phone Number length| 0 | 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 | 21 | Phone Number.. 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 Dialed Number AVP encodes the dialed number for the incoming call, 2685 that is, DNIS. The Attribute value is 21, Dialed Number, and is 2686 marked mandatory. The presence of this AVP is optional. The value 2687 is an ASCII string. 2689 Dialing Number 2691 0 1 2 3 2692 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 |1|0|0|0|6 + Phone Number length| 0 | 2695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 | 22 |Phone Number... 2697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 Dialing Number AVP encodes the originating number for the incoming 2700 call, that is, CLID. The Attribute value is 22, Dialing Number, and 2701 is marked mandatory. The presence of this AVP is optional. The 2702 value is an ASCII string. 2704 Sub-Address 2706 0 1 2 3 2707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 |1|0|0|0|6 + Sub-Address length | 0 | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 | 23 |Sub-Address ... 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 Sub-Address AVP encodes additional dialing information. The 2715 Attribute value is 23, Sub-Address, and is marked mandatory. The 2716 presence of this AVP is optional. The Sub-Address value is an ASCII 2717 string. 2719 Private Group ID 2721 0 1 2 3 2722 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 |1|0|0|0| 6 + Private Group ID | 0 | 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 | 37 | Private Group ID ... 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 The PrivateGroup ID AVP is used by the LAC to indicate that this call 2730 is to be associated with a particular customer group. The Attribute 2731 is 37, Private Group ID, and is marked optional. The presence of 2732 this AVP is optional. The LNS MAY treat the PPP session as well as 2733 network traffic through this session specially in a manner determined 2734 by the peer. For example, if the LNS is individually connected to 2735 several private networks using unregistered addresses, this AVP may 2736 be included by the LAC to indicate that a given call should be 2737 associated with one of the private networks. 2739 The Private Group ID is a string corresponding to a table in the LNS 2740 that defines the particular characteristics of the selected group. A 2741 LAC MAY determine the Private Group ID from a RADIUS response 2742 containing the PrivateGroupID attribute. 2744 The Private Group ID AVP MAY be included in either incoming call 2745 request or incoming call connected messages. This AVP SHOULD NOT be 2746 included in both messages. 2748 6.11 Incoming-Call-Reply (ICRP) 2750 The Incoming-Call-Reply is an L2TP control message sent by the LNS to 2751 the LAC in response to a received Incoming-Call-Request message. The 2752 reply indicates the result of the incoming call attempt. It also 2753 provides information to allow the LAC to regulate the transmission of 2754 data to the LNS for this session. 2756 This message is the second in the three-way handshake used by L2TP 2757 for establishing incoming calls. It indicates to the LAC whether the 2758 call should be answered or not. 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2761 | L2TP Control Message Header | 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 | Incoming-Call-Reply | 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 | Assigned Call ID | 2766 | Result Code | 2767 | Receive Window Size | 2768 | Packet Processing Delay | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 Incoming-Call-Reply 2773 0 1 2 3 2774 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 |1|0|0|0| 8 | 0 | 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | 0 | 11 | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 The Message Type AVP contains a Value of 11, indicating Incoming- 2782 Call-Reply. The Incoming-Call-Reply message encodes a response by 2783 the LNS to the incoming call indication given by the LAC. The flags 2784 indicate a mandatory option. 2786 Assigned Call ID 2788 0 1 2 3 2789 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 |1|0|0|0| 8 | 0 | 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2793 | 14 | Call ID | 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 The Assigned Call ID AVP encodes the ID being assigned to call by the 2797 LNS. The Attribute value is 14, Assigned Call ID, and is marked 2798 mandatory. This AVP MUST be present if the Result Code indicates the 2799 call was successful. The LAC places this value in the Call ID header 2800 field of all command and payload packets that it subsequently 2801 transmits over the tunnel that belong to this call. The Call ID 2802 value is an identifier assigned by the LNS to this session. It is 2803 used to multiplex and demultiplex data sent over that tunnel between 2804 the LNS and LAC. 2806 Result Code 2808 0 1 2 3 2809 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2811 |1|0|0|0| 10 + Message length | 0 | 2812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2813 | 1 | Result Code | 2814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2815 | Error Code | Optional Message ... 2816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2818 The Result Code AVP within an Incoming-Call-Reply message 2819 indicates the result of the incoming call establishment attempt. 2820 It is encoded as Attribute 1, indicating a Result Code AVP. This 2821 AVP is mandatory and MUST be present. The Result Code is a 16-bit 2822 word. The 16-bit word following the Result Code field contains 2823 the Error Code value. The Result Code value indicates whether the 2824 Error Code value is meaningful or not. If it is not meaningful it 2825 should be set to a value of 0. An optional error message can 2826 follow the Error Code field. Its presence and length is indicated 2827 by the value of the AVP length field. Defined Result Code values 2828 are: 2830 1 - The LAC should answer the incoming call 2831 2 - The Incoming Call should not be established due to the 2832 reason indicated in Error Code 2833 3 - The LAC should not accept the incoming call. It should 2834 hang up or issue a busy indication 2836 Receive Window Size 2838 0 1 2 3 2839 0 1 2 3 4 5 6 7 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| 8 | 0 | 2842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 | 10 | Size | 2844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2845 | Optional Message... | 2846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2848 Receive Window Size AVP encodes the receive window size being 2849 offered by the LNS for this call. The Attribute value is 10, 2850 Receive Window Size, and is marked mandatory. The Size value 2851 indicates the number of received data packets the LNS will buffer 2852 for this call, which is also the maximum number of data packets 2853 the LAC should send before waiting for an acknowledgment. This 2854 AVP is optional if Sequence and Acknowledgment Numbers are not to 2855 be used in the payload session for this call, or if the Result AVP 2856 indicates failure. 2858 Packet Processing Delay 2860 0 1 2 3 2861 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2863 |1|0|0|0| 8 | 0 | 2864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 | 20 | Delay | 2866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 Packet Processing Delay AVP encodes the delay the LNS expects for 2869 processing a window full of packets sent by the LAC. The 2870 Attribute value is 20, Packet Processing Delay AVP, and is marked 2871 mandatory. The presence of this AVP is optional. The Delay value 2872 is specified in units of 1/10 seconds. Refer to Appendix A to see 2873 a description of how this value is determined and used. 2875 6.12 Incoming-Call-Connected (ICCN) 2877 The Incoming-Call-Connected message is an L2TP control message sent 2878 by the LAC to the LNS in response to a received Incoming-Call-Reply. 2879 It provides information to the LNS about particular parameters used 2880 for the call. It also provides information to allow the LNS to 2881 regulate the transmission of data to the LAC for this session. 2883 This message is the third in the three-way handshake used by L2TP for 2884 establishing incoming calls. It provides a mechanism for providing 2885 the LNS with additional information about the call that cannot, in 2886 general, be obtained at the time the Incoming-Call-Request is issued 2887 by the LAC. 2889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2890 | L2TP Control Message Header | 2891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 | Incoming-Call-Connected | 2893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2894 | Connect Speed | 2895 | Framing Type | 2896 | Receive Window Size | 2897 | Packet Processing Delay | 2898 | Initial LCP Confreq | 2899 | Last Sent LCP Confreq | 2900 | Last Received LCP Confreq | 2901 | Proxy authen type | 2902 | Proxy authen name | 2903 | Proxy authen challenge | 2904 | Proxy authen ID | 2905 | Proxy authen response | 2906 | Private Group ID | 2907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2909 Incoming-Call-Connected 2911 0 1 2 3 2912 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 |1|0|0|0| 8 | 0 | 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2916 | 0 | 12 | 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 The Message Type AVP contains a Value of 12, indicating Incoming- 2920 Call-Connected. The Incoming-Call-Connected message encodes a 2921 response by the LAC to the Incoming-Call-Reply message sent by the 2922 LAC. The flags indicate a mandatory option. 2924 Connect Speed 2926 0 1 2 3 2927 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 |1|0|0|0| 10 | 0 | 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 | 24 | BPS (H) | 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 | BPS (L) | 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2936 Connect Speed BPS AVP encodes the speed for the connection. The 2937 Attribute value is 24, Connect Speed, and is marked mandatory. This 2938 AVP MUST be present. The value is a 32-bit quantity indicating the 2939 speed in bits/second. 2941 Framing Type 2943 0 1 2 3 2944 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 |1|0|0|0| 10 | 0 | 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2948 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2950 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2953 Framing Type AVP encodes the framing type for the call. The 2954 Attribute value is 19, Framing Type, and is marked mandatory. This 2955 AVP MUST be present. The value is a 32-bit bit field indicating the 2956 type of PPP framing used for the call. If set, bit A indicates that 2957 asynchronous framing is being used. If set, bit S indicates that 2958 synchronous framing is being used. 2960 Receive Window Size 2962 0 1 2 3 2963 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 |1|0|0|0| 8 | 0 | 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2967 | 10 | Size | 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2970 Receive Window Size AVP encodes the window size being offered by the 2971 LAC for this call. The Attribute value is 10, Receive Window Size, 2972 and is marked mandatory. This AVP is optional if Sequence and 2973 Acknowledgment Numbers are not to be used in the payload session for 2974 this call. The 16-bit Size value indicates the number of received 2975 data packets the LAC will buffer for this call, which is also the 2976 maximum number of data packets the LNS should send before waiting for 2977 an acknowledgment. 2979 Packet Processing Delay 2981 0 1 2 3 2982 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2984 |1|0|0|0| 8 | 0 | 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2986 | 20 | Delay | 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2989 Packet Processing Delay AVP encodes the delay the LAC expects for 2990 processing a window full of packets sent by the LNS. The Attribute 2991 value is 20, Packet Processing Delay, and is marked mandatory. The 2992 presence of this AVP is optional. The 16-bit Delay value is 2993 specified in units of 1/10 seconds. Refer to Appendix A to see a 2994 description of how this value is determined and used. 2996 Initial LCP Confreq 2998 0 1 2 3 2999 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3001 |0|0|0|0|6 + LCP confreq length | 0 | 3002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3003 | 26 | LCP confreq... 3004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 The LAC may have answered the phone call and negotiated LCP with the 3007 dial-in client in order to establish the client's apparent identity. 3008 In this case, this option may be included to indicate the link 3009 properties the client requested in its initial LCP CONFREQ request. 3010 The Attribute value is 26, Initial LCP Confreq, and is marked 3011 optional. The presence of this AVP is optional. The Value field is 3012 a copy of the body of the initial CONFREQ received, starting at the 3013 first option within this packet's body. 3015 Last Sent LCP Confreq 3017 0 1 2 3 3018 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3020 |0|0|0|0|6 + LCP confreq length | 0 | 3021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3022 | 27 | LCP confreq... 3023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3025 See Initial LCP Confreq above for rationale. The Attribute value is 3026 27, Last Sent LCP Confreq, and is marked optional. The presence of 3027 this AVP is optional. The Value field is a copy of the body of the 3028 final CONFREQ sent to the client to complete LCP negotiation, 3029 starting at the first option within this packet's body. 3031 Last Received LCP Confreq 3033 0 1 2 3 3034 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 |0|0|0|0|6 + LCP confreq length | 0 | 3037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3038 | 28 | LCP confreq... 3039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3041 See Initial LCP Confreq above for rationale. The Attribute value is 3042 28, Last Received LCP Confreq, and is marked optional. The presence 3043 of this AVP is optional. The Value field is a copy of the body of 3044 the final CONFREQ received from the client to complete LCP 3045 negotiation, starting at the first option within this packet's body. 3047 Proxy Authen Type 3049 0 1 2 3 3050 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3052 |1|0|0|0| 8 | 0 | 3053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3054 | 29 | Type | 3055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3057 The Attribute value is 29, Proxy Authen Type, and is marked 3058 mandatory. This AVP MUST be present. The value Type is a 16-bit 3059 word, holding a value: 3061 1 - Textual username/password exchange 3062 2 - PPP CHAP 3063 3 - PPP PAP 3064 4 - None 3066 Associated AVP's for each type of authentication follow. 3068 Proxy Authen Name 3069 0 1 2 3 3070 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3072 |0|0|0|0| 6 + Name length | 0 | 3073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3074 | 30 | Name... 3075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 The Attribute value is 30, Proxy Authen Name, and is marked 3078 mandatory. This AVP MUST be present for Proxy Authen Type values 1, 3079 2, and 3. The Name field contains the name specified in the client's 3080 authentication response. Note that the AVP H bit may be desirable 3081 for obscuring the cleartext name. 3083 Proxy Authen Challenge 3085 0 1 2 3 3086 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 |0|0|0|0| 6 + Challenge length | 0 | 3089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3090 | 31 | Challenge... 3091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3093 The Attribute value is 31, Proxy Authen Challenge, and is marked 3094 mandatory. The AVP itself MUST be present for Proxy authen type 2. 3095 The Challenge field contains the value presented to the client by the 3096 LAC. 3098 Proxy Authen ID 3100 0 1 2 3 3101 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3103 |0|0|0|0| 8 | 0 | 3104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3105 | 32 | ID | 3106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 The Attribute value is 32, Proxy Authen ID, and is marked mandatory. 3109 The AVP itself MUST be present for Proxy authen types 2 and 3. For 3110 CHAP, the ID field contains the byte ID value presented to the client 3111 by the LAC in its Challenge. For PAP, it is the Identifier value of 3112 the Authenticate-Request. The most significant 8 bits of ID MUST be 3113 0, and are reserved. 3115 Proxy Authen Response 3117 0 1 2 3 3118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3120 |1|0|0|0| 6 + Response length | 0 | 3121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3122 | 33 | Response... 3124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3126 The Attribute value is 33, Proxy Authen Response, and is marked 3127 mandatory. The AVP itself MUST be present for Proxy authen types 1, 3128 2, and 3. The Response field contains the client's response to the 3129 challenge. For Proxy authen type 2, this field contains the response 3130 value received by the LAC. For types 1 or 3, it contains the clear 3131 text password received from the client by the LAC. In the case of 3132 cleartext passwords, use of the AVP H bit is recommended. 3134 Private Group ID 3136 0 1 2 3 3137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 |1|0|0|0| 6 + Private Group ID | 0 | 3140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3141 | 37 | Private Group ID ... 3142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3144 PrivateGroup ID AVP is used by the LAC to indicate that this call is 3145 to be associated with a particular customer group. The Attribute is 3146 37, Private Group ID, and is marked optional. The presence of this 3147 AVP is optional. The LNS MAY treat the PPP session as well as 3148 network traffic through this session specially in a manner determined 3149 by the peer. For example, if the LNS is individually connected to 3150 several private networks using unregistered addresses, this AVP may 3151 be included by the LAC to indicate that a given call should be 3152 associated with one of the private networks. 3154 The Private Group ID is a string corresponding to a table in the LNS 3155 that defines the particular characteristics of the selected group. A 3156 LAC MAY determine the Private Group ID from a RADIUS response 3157 containing the PrivateGroupID attribute. 3159 The Private Group ID AVP MAY be included in either incoming call 3160 request or incoming call connected messages. This AVP SHOULD NOT be 3161 included in both messages. 3163 6.13 (reserved) 3165 The function previously described here has been deleted from L2TP. 3167 6.14 Call-Disconnect-Notify (CDN) 3169 The Call-Disconnect-Notify message is an L2TP control message sent to 3170 request disconnection of a specific call within the tunnel. Its 3171 purpose is to inform the peer of the disconnection and the reason why 3172 the disconnection occurred. The peer MUST clean up any resources, 3173 and does not send back any indication of success or failure for such 3174 cleanup. 3176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3177 | L2TP Control Message Header | 3178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3179 | Call-Disconnect-Notify | 3180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3181 | Result Code | 3182 | Q.931 Cause Code | 3183 | Assigned Call ID | 3184 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3186 Call-Disconnect-Notify 3188 0 1 2 3 3189 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3191 |1|0|0|0| 8 | 0 | 3192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3193 | 0 | 14 | 3194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3196 The Message Type AVP contains a Value of 14, indicating Call- 3197 Disconnect-Notify. The Call-Disconnect-Notify message encodes a 3198 disconnect indication for a specific call within the tunnel. The 3199 flags indicate a mandatory option. 3201 Result Code 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| 10 + Message length | 0 | 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 | 1 | Result Code | 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 | Error Code | Optional Message ... 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3213 The Result Code AVP within a Call-Disconnect-Notify message 3214 indicates the reason for the call disconnect. It is encoded as 3215 Attribute 1, indicating a Result Code AVP. This AVP is mandatory 3216 and MUST be present. The Result Code is a 16-bit word. The 16- 3217 bit word following the Result Code field contains the Error Code 3218 value. The Result Code value indicates whether the Error Code 3219 value is meaningful or not. If Error Code is not meaningful it 3220 MUST be set to 0. An optional error message can follow the Error 3221 Code field; its presence and length is indicated by the value of 3222 the AVP length field. Defined Result Code values are: 3224 1 - Call disconnected due to loss of carrier 3225 2 - Call disconnected for the reason indicated in Error Code. 3226 3 - Call disconnected for administrative reasons 3227 4 - Call failed due to no appropriate facilities being 3228 available (temporary condition) 3229 5 - Call failed due to no appropriate facilities being 3230 available (permanent condition) 3231 6 - Invalid destination 3232 7 - Call failed due to no carrier detected 3233 8 - Call failed due to detection of a busy signal 3234 9 - Call failed due to lack of a dial tone 3235 10 - Call was not established within time allotted by LAC 3236 11 - Call was connected but no appropriate framing was detected 3238 Q.931 Cause Code 3240 0 1 2 3 3241 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3243 |0|0|0|0|9 + Advisory Msg length| 0 | 3244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3245 | 12 | Cause Code | 3246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3247 | Cause Msg |Advisory Msg...| 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3250 The Q.931 Cause Code AVP is used to give additional information in 3251 case of unsolicited call disconnection. The Attribute value is 3252 12, Cause Code, and is marked mandatory. The presence of this AVP 3253 is optional. The Cause Code AVP is used to give additional 3254 information about the reason for disconnecting. It is only 3255 relevant when the LAC is using Q.931/DSS1 for the call. This AVP 3256 is optional. Cause Code is the returned Q.931 Cause code and 3257 Cause Msg is the returned Q.931 message code (e.g., DISCONNECT) 3258 associated with the Cause Code. Both values are returned in their 3259 native ITU encodings. An additional Ascii text Advisory Message 3260 may also be included (presence indicated by the AVP length) to 3261 further explain the reason for disconnecting. 3263 Assigned Call ID 3265 0 1 2 3 3266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3268 |1|0|0|0| 8 | 0 | 3269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3270 | 14 | Call ID | 3271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3273 The Assigned Call ID which was provided to the LNS from this LAC 3274 is included in the Call-Disconnect-Notify message. This permits a 3275 connection to be terminated even before the LNS has provided its 3276 own Assigned Call ID to this LAC (the Call ID field in the control 3277 message header is 0). The Attribute value is 14, Assigned Call 3278 ID, and is marked mandatory. This AVP MUST be present. 3280 6.15 WAN-Error-Notify (WEN) 3282 The WAN-Error-Notify message is an L2TP control message sent by the 3283 LAC to the LNS to indicate WAN error conditions (conditions that 3284 occur on the interface supporting PPP). The counters in this message 3285 are cumulative. This message should only be sent when an error 3286 occurs, and not more than once every 60 seconds. The counters are 3287 reset when a new call is established. 3289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3290 | L2TP Control Message Header | 3291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3292 | WAN-Error-Notify | 3293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3294 | Call Errors | 3295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3297 WAN-Error-Notify 3299 0 1 2 3 3300 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3302 |1|0|0|0| 8 | 0 | 3303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3304 | 0 | 15 | 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3307 The Message Type AVP contains a Value of 15, indicating WAN-Error- 3308 Notify. The WAN-Error-Notify message encodes information about line 3309 and other errors detected on the LAC's physical interface to the 3310 client. This message is sent by the LAC to the LNS. The flags 3311 indicate a mandatory option. 3313 Call Errors 3315 0 1 2 3 3316 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 |1|0|0|0| 32 | 0 | 3319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 | 34 | Reserved | 3321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3322 | CRC Errors | 3323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 | Framing Errors | 3325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3326 | Hardware Overruns | 3327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3328 | Buffer Overruns | 3329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3330 | Time-out Errors | 3331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3332 | Alignment Errors | 3333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 The Call Errors AVP is used by the LAC to send error information to 3336 the LNS. The Attribute value is 34, WAN-Error-Notify, and is marked 3337 mandatory. This AVP MUST be present. The value contains the 3338 following fields: 3340 Reserved - Not used, MUST be 0 3341 CRC Errors - Number of PPP frames received with CRC errors since 3342 session was established 3343 Framing Errors - Number of improperly framed PPP packets received 3344 Hardware Overruns - Number of receive buffer over-runs since 3345 session was established 3346 Buffer Overruns - Number of buffer over-runs detected since 3347 session was established 3348 Time-out Errors - Number of time-outs since call was established 3349 Alignment Errors - Number of alignment errors since call was 3350 established 3352 6.16 Set-Link-Info (SLI) 3354 The Set-Link-Info message is an L2TP control message sent by the LNS 3355 to the LAC to set PPP-negotiated options. Because these options can 3356 change at any time during the life of the call, the LAC MUST be able 3357 to update its internal call information dynamically and update its 3358 behavior on an active PPP session. 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 | L2TP Control Message Header | 3362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 | Set-Link-Info | 3364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3365 | ACCM | 3366 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3368 Set-Link-Info 3370 0 1 2 3 3371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3373 |1|0|0|0| 8 | 0 | 3374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3375 | 0 | 16 | 3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3378 The Message Type AVP contains a Value of 16, indicating Set-Link- 3379 Info. The Set-Link-Info message encodes ACCM information sent from 3380 the LNS to the LAC after it is negotiated in LCP. The flags indicate 3381 a mandatory option. 3383 ACCM 3385 0 1 2 3 3386 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3388 |1|0|0|0| 32 | 0 | 3389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3390 | 35 | Reserved | 3391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3392 | Send ACCM | 3393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3394 | Receive ACCM | 3395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3397 The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. 3398 The Attribute value is 35, ACCM, and is marked mandatory. This 3399 attribute MUST be present. The value contains Send ACCM and Receive 3400 ACCM fields. The send ACCM value should be used by the LAC to 3401 process packets it is sends on the connection. The receive ACCM 3402 value should be used by the LAC to process incoming packets on the 3403 connection. The default values used by the LAC for both these fields 3404 are 0xFFFFFFFF. The LAC should honor these fields unless it has 3405 specific configuration information to indicate that the requested 3406 mask must be modified to permit operation. 3408 7.0 Control Connection State Machines 3410 The control messages defined in section 6 are exchanged by way of state 3411 tables defined in this section. Tables are defined for incoming call 3412 placement, outgoing call placement, as well as for initiation of the 3413 tunnel itself. The state tables do not encode timeout and 3414 retransmission behavior, as this is handled in the underlying semantics 3415 defined in 6.0.2. 3417 7.1 Control Connection Protocol Operation 3419 This section describes the operation of various L2TP control 3420 connection functions and the Control Connection messages which are 3421 used to support them. 3423 Receipt of an invalid or malformed Control Connection message should 3424 be logged appropriately, and the control connection should be closed 3425 and restarted to ensure recovery into a known state. 3427 In several cases in the following tables, a protocol message is sent, 3428 and then a "clean up" occurs. Note that regardless of the initiator 3429 of the tunnel destruction, the reliable delivery mechanism must be 3430 allowed to run (see 6.0.2) before destroying the tunnel. This 3431 permits the tunnel management messages to be reliably delivered to 3432 the peer. 3434 7.2 Control Connection States 3436 Control messages are carried over the same media as the payload 3437 messages which are carried following successful connection 3438 establishment. The L2TP control connection protocol is not 3439 distinguishable between the LNS and LAC, but is distinguishable 3440 between the originator and receiver. The originating peer is the one 3441 which first establishes the tunnel. Since either LAC or LNS can be 3442 the originator, a collision can occur. See Section 6.0.1 for a 3443 description of this and its resolution. 3445 7.2.1 Control Connection Establishment 3447 State Event Action New State 3448 ----- ----- ------ --------- 3449 idle Local Send SCCRQ wait-ctl-reply 3450 Open request 3452 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3453 acceptable 3455 idle Receive SCCRQ, Send StopCCN, idle 3456 not acceptable Clean up 3458 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3459 acceptable Send tunnel-open 3460 event to waiting 3461 sessions 3463 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3464 not acceptable Clean up 3466 wait-ctl-reply Receive SCCRQ, Clean up, idle 3467 lose tie-breaker Re-queue SCCRQ 3468 for idle state 3470 wait-ctl-conn Receive SCCCN, Send tunnel-open established 3471 acceptable event to waiting 3472 sessions 3474 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3475 not acceptable Clean up 3477 established Local Send tunnel-open established 3478 Open request event to waiting 3479 (new client) sessions 3481 established Admin Send StopCCN idle 3482 Tunnel Close Clean up 3484 wait-ctl-reply, 3485 wait-ctl-conn, 3486 established Receive StopCCN Clean up idle 3488 idle 3489 Both initiator and recipient start from this state. An initiator 3490 transmits a SCCRQ, while a recipient remains in the idle state 3491 until receiving a SCCRQ. 3493 wait-ctl-reply 3494 The originator checks to see if another connection has been 3495 requested from the same peer, and if so, handles the collision 3496 situation described in Section 6.0.1. 3498 When a SCCRP is received, it is examined for a compatible version. 3499 If the version of the reply is lower than the version sent in the 3500 request, the older (lower) version should be used provided it is 3501 supported. If the version in the reply is earlier and supported, 3502 the originator moves to the established state. If the version is 3503 earlier and not supported, a StopCCN MUST be sent to the peer and 3504 the originator cleans up and terminates the tunnel. 3506 wait-ctl-conn 3507 This is where an SCCCN is awaited; upon receipt, protocol version 3508 compatibility is checked. The tunnel is either established, or is 3509 torn down if a protocol mismatch is detected. 3511 established 3512 An established connection may be terminated by either a local 3513 condition or the receipt of a Stop-Control-Connection- 3514 Notification. In the event of a local termination, the originator 3515 MUST send a Stop-Control-Connection-Notification and clean up the 3516 tunnel. 3518 If the originator receives a Stop-Control-Connection-Notification 3519 it MUST also clean up the tunnel. 3521 7.3 Timing considerations 3523 Because of the real-time nature of telephone signaling, both the LNS 3524 and LAC should be implemented with multi-threaded architectures such 3525 that messages related to multiple calls are not serialized and 3526 blocked. The call and connection state figures do not specify 3527 exceptions caused by timers. These are addressed in Section 6.0.2. 3529 7.4 Incoming calls 3531 An Incoming-Call-Request message is generated by the LAC when an 3532 associated telephone line rings. The LAC selects a Call ID and 3533 serial number and indicates the call bearer type. Modems should 3534 always indicate analog call type. ISDN calls should indicate digital 3535 when unrestricted digital service or rate adaption is used and analog 3536 if digital modems are involved. CLID, DNIS, and subaddress may be 3537 included in the message if they are available from the telephone 3538 network. 3540 Once the LAC sends the Incoming-Call-Request, it waits for a response 3541 from the LNS but it does not necessarily answer the call from the 3542 telephone network yet. The LNS may choose not to accept the call if: 3544 - No resources are available to handle more sessions 3545 - The dialed, dialing, or subaddress fields do not correspond to 3546 an authorized user 3547 - The bearer service is not authorized or supported 3549 If the LNS chooses to accept the call, it responds with an Incoming- 3550 Call-Reply which may also indicate window sizes (see Appendix B). 3551 When the LAC receives the Incoming-Call-Reply, it attempts to connect 3552 the call. A final call connected message from the LAC to the LNS 3553 indicates that the call states for both the LAC and the LNS should 3554 enter the established state. If the call terminated before the LNS 3555 could accept it, a Call-Disconnect-Notify is sent by the LAC to 3556 indicate this condition. 3558 When the dialed-in client hangs up, the call is cleared normally and 3559 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 3560 clear a call, it sends a Call-Disconnect-Notify message and cleans up 3561 its session. 3563 7.4.1 LAC Incoming Call States 3565 State Event Action New State 3566 ----- ----- ------ --------- 3567 idle Bearer Ring or Initiate local wait-tunnel 3568 Ready to indicate tunnel open 3569 incoming conn. 3571 wait-tunnel tunnel-open Send ICRQ wait-reply 3573 wait-reply Receive ICRP, Answer call, established 3574 accepting Send ICCN 3576 wait-reply Receive ICRP, Send CDN, idle 3577 not accepting Clean up 3579 wait-reply Receive CDN Clean up idle 3581 wait-reply Local Send CDN, idle 3582 Close request Clean up 3584 established Receive CDN Hang up bearer, idle 3585 Clean up 3587 established Local Hang up bearer, idle 3588 Close request Send CDN, 3589 Clean up 3591 established Bearer Send CDN, idle 3592 Line drop Clean up 3594 The states associated with the LAC for incoming calls are: 3596 idle 3597 The LAC detects an incoming call on one of its interfaces. Typically 3598 this means an analog line is ringing or an ISDN TE has detected an 3599 incoming Q.931 SETUP message. The LAC initiates its tunnel 3600 establishment state machine, and moves to a state waiting for 3601 confirmation of the existence of a tunnel. 3603 wait-tunnel 3604 In this state the session is waiting for either the control tunnel to 3605 be opened or for verification that the tunnel is already open. Once 3606 an indication that the tunnel has/was opened, session control 3607 messages may be exchanged. The first of these is the Incoming-Call- 3608 Request. 3610 wait-reply 3611 The LAC receives an Incoming-Call-Reply message indicating non- 3612 willingness to accept the call (general error or don't accept) and 3613 moves back into the idle state. If the reply message indicates that 3614 the call is accepted, the LAC sends an Incoming-Call-Connected 3615 message and enters the established state. 3617 established 3618 Data is exchanged over the tunnel. The call may be cleared 3619 following: 3620 An event on the connected interface. The LAC sends a Call- 3621 Disconnect-Notify message 3622 Receipt of a Call-disconnect-Notify message. The LAC cleans up, 3623 disconnecting the call. 3624 A local reason. The LAC sends a Call-Disconnect-Notify message. 3626 7.4.2 LNS Incoming Call States 3628 State Event Action New State 3629 ----- ----- ------ --------- 3630 idle Receive ICRQ, Send ICRP wait-connect 3631 acceptable 3633 idle Receive ICRQ, Send CDN, idle 3634 not acceptable Clean up 3636 wait-connect Receive ICCN Prepare for established 3637 acceptable data 3639 wait-connect Receive ICCN Send CDN, idle 3640 not acceptable Clean up 3642 wait-connect, 3643 established Receive CDN Clean up idle 3645 established Local Send CDN, idle 3646 Close request Clean up 3648 The states associated with the LNS for incoming calls are: 3650 idle 3651 An Incoming-Call-Request message is received. If the request is 3652 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 3653 and the LNS remains in the idle state. If the Incoming-Call- 3654 Request message is acceptable, an Incoming-Call-Reply is sent. 3655 The session moves to the wait-connect state. 3657 wait-connect 3658 If the session is still connected on the LAC, the LAC sends an 3659 Incoming-Call-Connected message to the LNS which then moves into 3660 established state. The LAC may send a Call-Disconnect-Notify to 3661 indicate that the incoming caller could not be connected. This 3662 could happen, for example, if a telephone user accidentally places 3663 a standard voice call to an LAC resulting in a handshake failure 3664 on the called modem. 3666 established 3667 The session is terminated either by receipt of a Call-Disconnect- 3668 Notify message from the LAC or by sending a Call-Disconnect- 3669 Notify. Clean up follows on both sides regardless of the 3670 initiator. 3672 7.5 Outgoing calls 3674 Outgoing calls are initiated by an LNS and instruct an LAC to place a 3675 call. There are three messages for outgoing calls: Outgoing-Call- 3676 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 3677 sends an Outgoing-Call-Request specifying the dialed party phone 3678 number and subaddress as well as speed and window parameters. The 3679 LAC MUST respond to the Outgoing-Call-Request message with an 3680 Outgoing-Call-Reply message once the LAC determines that the proper 3681 facilities exist to place the call and the call is administratively 3682 authorized. For example, is this LNS allowed to dial an 3683 international call? Once the outbound call is connected the LAC 3684 sends an Outgoing-Call-Connected message to the LNS indicating the 3685 final result of the call attempt: 3687 7.5.1 LAC Outgoing Call States 3689 State Event Action New State 3690 ----- ----- ------ --------- 3691 idle Receive OCRQ, Send OCRP, wait-cs-answer 3692 acceptable Open bearer 3694 idle Receive OCRQ, Send CDN, idle 3695 not acceptable Clean up 3697 wait-cs-answer Bearer answer, Send OCCN established 3698 framing detected 3700 wait-cs-answer Bearer failure Send CDN, idle 3701 Clean up 3703 wait-cs-answer, 3704 established Receive CDN Hang up bearer, idle 3705 Clean up 3707 The states associated with the LAC for outgoing calls are: 3709 idle 3710 Received Outgoing-Call-Request. If this is received in error, 3711 respond with a Call-Disconnect-Notify. Otherwise, allocate a 3712 physical channel and send an Outgoing-Call-Reply. Place the 3713 outbound call and move to the wait-cs-answer state. 3715 wait-cs-answer 3716 If the call is not completed or a timer expires waiting for the 3717 call to complete, send a Call-Disconnect-Notify with the 3718 appropriate error condition set and go to idle state. If a 3719 circuit switched connection is established and framing is 3720 detected, send an Outgoing-Call-Connected indicating success and 3721 go to established state. 3723 established 3724 If a Call-Disconnect-Notify is received, the telco call MUST be 3725 released via appropriate mechanisms and the session cleaned up. 3726 If the call is disconnected by the client or the called interface, 3727 a Call-Disconnect-Notify message MUST be sent to the LNS. Return 3728 to idle state after sending the Call-Disconnect-Notify. 3730 7.5.2 LNS Outgoing Call States 3732 State Event Action New State 3733 ----- ----- ------ --------- 3734 idle Local Initiate local wait-tunnel 3735 Open request tunnel-open 3737 wait-tunnel tunnel-open Send OCRQ wait-reply 3739 wait-reply Receive OCRP, none wait-connect 3740 acceptable 3742 wait-reply Receive OCRP, Send CDN idle 3743 not acceptable 3745 wait-connect Receive OCCN none established 3747 established, 3748 wait-connect Receive CDN Clean up idle 3750 wait-reply, 3751 wait-connect, 3752 established Local Send CDN idle 3753 Close request 3755 The states associated with the LNS for outgoing calls are: 3757 idle, wait-tunnel 3758 When an outgoing call is initiated, a tunnel is first created, 3759 much as the idle and wait-tunnel states for an LAC incoming call. 3760 Once a tunnel is established, an Outgoing-Call-Request message is 3761 sent to the LAC and the session moves into the wait-reply state. 3763 wait-reply 3764 If a Call-Disconnect-Notify is received, an error occurred, and 3765 the session is cleaned up and returns to idle. If an Outgoing- 3766 Call-Reply is received, the call is in progress and the session 3767 moves to the wait-connect state. 3769 wait-connect 3770 If a Call-Disconnect-Notify is received, the call failed; the 3771 session is cleaned up and returns to idle. If an Outgoing-Call- 3772 Connected is received, the call has succeeded and the session may 3773 now exchange data. 3775 established 3776 If a Call-Disconnect-Notify is received, the call has been 3777 terminated for the reason indicated in the Result and Cause Codes; 3778 the session moves back to the idle state. If the LNS chooses to 3779 terminate the session, it sends a Call-Disconnect-Notify to the 3780 LAC and then cleans up and idles its session. 3782 8.0 L2TP Over Specific Media 3784 L2TP tries to be self-describing, operating at a level above the 3785 particular media over which it is carried. However, some details of 3786 its connection to media are required to permit interoperable 3787 implementations. The following sections describe details needed to 3788 permit interoperability over specific media. 3790 8.1 IP/UDP 3792 L2TP uses the well-known UDP port 1701 [3]. The entire L2TP packet, 3793 including payload and L2TP header, is sent within a UDP datagram. 3794 The initiator of an L2TP tunnel picks an available source UDP port, 3795 and sends to the desired destination at port 1701. The recipient 3796 picks a free port on its own system, and sends its reply to the 3797 initiator's UDP port, setting its own UDP source port set to the free 3798 port it found. All subsequent packets exchanged will use these UDP 3799 ports. It is legal for a peer's IP address used for a given tunnel 3800 to change over the life of a connection; this may correspond to a 3801 peer with multiple IP interfaces responding to a network topology 3802 change. Responses should reflect the last source IP address for that 3803 Tunnel ID. 3805 IP fragmentation may occur as the L2TP packet travels over the IP 3806 substrate. L2TP makes no special efforts to optimize this. A LAC 3807 implementation MAY cause its LCP to negotiate for a specific MRU, 3808 which could optimize for LAC environments in which the MTUs of the 3809 path over which the L2TP packets are likely to travel have a 3810 consistent value. 3812 When operating over UDP, both the I and C bits MUST be present, and 3813 are used to permit correct demultiplexing and tunnel identification. 3815 The default for any L2TP implementation is that UDP checksums MUST be 3816 enabled for both control and payload messages. An L2TP 3817 implementation MAY provide an option to disable UDP checksums for 3818 payload packets. It is recommended that UDP checksums always be 3819 enabled on control packets. 3821 Port 1701 is used for both L2F [5] and L2TP packets. The two types 3822 of packets may be detected by their headers; L2TP has a Vers field of 3823 2, L2F has a 1 in this field instead. An L2TP implementation running 3824 on a system which does not support L2F MUST silently discard all 3825 packets whose Vers field is set to 1. 3827 8.2 IP 3829 When operating in IP environments, L2TP MUST offer the UDP 3830 encapsulation described in 8.1 as its default configuration for IP 3831 operation. Other configurations (perhaps corresponding to a 3832 compressed header format) may be defined, and made available as a 3833 configurable option. 3835 9.0 Security Considerations 3837 L2TP encounters several security issues in its operation. The 3838 general approach of L2TP to these issues is documented here. 3840 9.1 Tunnel Endpoint Security 3842 The tunnel endpoints may authenticate each other during tunnel 3843 establishment. This authentication has the same security 3844 attributes as CHAP, and has reasonable protection against replay 3845 and snooping. In environments where some L2TP peers will be 3846 authenticated, but others not, a mechanism should be provided to 3847 control when tunnel endpoint authentication will be active. 3849 The LAC and LNS MUST share a single secret for authentication of 3850 both ends of the tunnel. Each side uses this same secret when 3851 acting as authenticatee as well as authenticator. Since a single 3852 secret it used, the tunnel authentication AVPs include 3853 differentiating values in the CHAP ID fields for each message 3854 digest calculation to guard against replay attacks. 3856 For L2TP tunnels over IP, IP-level packet security provides very 3857 strong protection of the tunnel. This requires no modification to 3858 the L2TP protocol, and leverages extensive IETF work in this area. 3860 For L2TP tunnels over Frame Relay or other switched networks, 3861 current practice indicates that these media are much less likely 3862 to experience attacks of in-transit data. If these attacks became 3863 prevalent, either the media or the L2TP packets would have to be 3864 encrypted. 3866 Because the shared secret used for endpoint authentication is the 3867 same shared secret used to obscure AVP contents using the H 3868 (Hidden) bit, tunnel authentication must be used in all cases 3869 where the H bit will be used. Proxy authentication involving PAP 3870 may be usable without the H bit if PAP is only carrying one-time 3871 passwords; if clear text passwords are carried in the proxy 3872 authentication, the H bit (and, by implication, tunnel 3873 authentication) should be used. 3875 To protect against exhaustive attack during tunnel authentication, 3876 no tunnel authentication response should ever be accepted if it 3877 corresponds to a challenge more than one minute old. 3879 9.2 Client Security 3881 A more systematic method of protection in tunneled PPP 3882 environments may be achieved through client security. PPP layer 3883 encryption would provide end-to-end security for both direct 3884 dial-in clients as well as PPP clients carried within a tunnel. 3885 With this level of client security, sessions are protected against 3886 attacks against the carrying tunnel, as well as attacks on the LAC 3887 itself. Because both encryption and compression can occur at the 3888 PPP layer, the two can be coordinated, permitting compression to 3889 precede encryption. 3891 9.3 Proxy Authentication 3893 The optional proxy CHAP function of L2TP can permit an entirely 3894 transparent PPP tunnel, with a single LCP and CHAP sequence being 3895 seen by the client. For cases where the LAC and the entire path 3896 to the LNS are operated by a single entity, this function may 3897 provide acceptable security. For cases where LNS-initiated 3898 authentication is required, proxy CHAP still permits an initial 3899 access decision to be made before accepting the tunnel, permitting 3900 the LNS in most cases to reject tunnel initiations rather than 3901 accept them and later disconnect. 3903 The optional proxy PAP may result in the cleartext password 3904 traversing the tunnel. Where PAP is being used in conjunction 3905 with static passwords, this may pose a significant security issue. 3906 Where PAP is only used to transport one-time passwords, such 3907 issues may be greatly mitigated. The H bit of the carrying AVP 3908 may be used to protect against this. 3910 All implementations MUST accept proxy authentication AVP's, but 3911 are free to silently discard them and initiate an entirely new 3912 authentication with the PPP client. 3914 10.0 Acknowledgments 3916 The AVP construct comes from Glen Zorn, who thought up the framework 3917 for permitting multiple vendors to contribute to a common attribute 3918 space in a relatively orderly fashion. 3920 Dory Leifer and Allan Rubens of Ascend Communications made valuable 3921 refinements to the protocol definition of L2TP and contributed to the 3922 editing of this document. 3924 Steve Cobb and Evan Caves redesigned the state machine tables. 3926 Barney Wolff provided a great deal of design input on the endpoint 3927 authentication mechanism. 3929 11.0 Contacts 3931 Kory Hamzeh 3932 Ascend Communications 3933 1275 Harbor Bay Parkway 3934 Alameda, CA 94502 3935 kory@ascend.com 3937 Tim Kolar, Morgan Littlewood, Bill Palter, Andrew J. Valencia 3938 Cisco Systems 3939 170 West Tasman Drive 3940 San Jose CA 95134-1706 3941 tkolar@cisco.com 3942 littlewo@cisco.com 3943 palter@cisco.com 3944 vandys@cisco.com 3946 Gurdeep Singh Pall 3947 Microsoft Corporation 3948 Redmond, WA 3949 gurdeep@microsoft.com 3951 Jeff Taarud 3952 Copper Mountain Networks 3953 jtaarud@coppermountain.com 3955 W. Mark Townsley 3956 IBM Corporation 3957 700 Park Office Dr. 3958 Raleigh, NC 27709 3959 wmt@raleigh.ibm.com 3961 William Verthein 3962 U.S. Robotics 3964 12.0 References 3966 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 3967 07/21/1994 3969 [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet 3970 draft, April 1996 3972 [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point 3973 Tunneling Protocol", Internet draft, June 1996 3975 [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC1034, 3976 November 1987 3978 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, 3979 USC/Information Sciences Institute, July 1992. 3981 [6] Sally Floyd, Van Jacobson, "Random Early Detection Gateways for 3982 Congestion Avoidance", IEEE/ACM Transactions on Networking, 3983 August 1993 3985 [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, 3986 October 1996 3988 [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authentication 3989 Dial In User Service (RADIUS)." draft-ietf-radius-radius-05.txt, 3990 Livingston, Merit, Daydreamer, July 1996. 3992 Appendix A: Acknowledgment Time-Outs 3994 L2TP uses sliding windows and time-outs to provide both user session 3995 flow-control across the underlying medium (which may be an 3996 internetwork) and to perform efficient data buffering to keep the 3997 LAC-LNS data channels full without causing receive buffer overflow. 3998 L2TP requires that a time-out be used to recover from dropped data or 3999 acknowledgment packets. The exact implementation of the time-out is 4000 vendor-specific. It is suggested that an adaptive time-out be 4001 implemented with backoff for congestion control. The time-out 4002 mechanism proposed here has the following properties: 4004 Independent time-outs for each session. A device (LAC or LNS) 4005 will have to maintain and calculate time-outs for every active 4006 session. 4008 An administrator-adjustable maximum time-out, MaxTimeOut, unique 4009 to each device. 4011 An adaptive time-out mechanism that compensates for changing 4012 throughput. To reduce packet processing overhead, vendors may 4013 choose not to recompute the adaptive time-out for every received 4014 acknowledgment. The result of this overhead reduction is that the 4015 time-out will not respond as quickly to rapid network changes. 4017 Timer backoff on time-out to reduce congestion. The backed-off 4018 timer value is limited by the configurable maximum time-out value. 4019 Timer backoff is done every time an acknowledgment time-out 4020 occurs. 4022 In general, this mechanism has the desirable behavior of quickly 4023 backing off upon a time-out and of slowly decreasing the time-out 4024 value as packets are delivered without time-outs. 4026 Some definitions: 4028 Packet Processing Delay, "PPD", is the amount of time required for 4029 each peer to process the maximum amount of data buffered in its 4030 offered receive packet window. The PPD is the value exchanged 4031 between the LAC and LNS when a call is established. For the LNS, 4032 this number should be small. For an LAC supporting modem 4033 connections, this number could be significant. 4035 "Sample" is the actual amount of time incurred receiving an 4036 acknowledgment for a packet. The Sample is measured, not 4037 calculated. 4039 Round-Trip Time, "RTT", is the estimated round-trip time for an 4040 Acknowledgment to be received for a given transmitted packet. 4041 When the network link is a local network, this delay will be 4042 minimal (if not zero). When the network link is the Internet, 4043 this delay could be substantial and vary widely. RTT is adaptive: 4044 it will adjust to include the PPD and whatever shifting network 4045 delays contribute to the time between a packet being transmitted 4046 and receiving its acknowledgment. 4048 Adaptive Time-Out, "ATO", is the time that must elapse before an 4049 acknowledgment is considered lost. After a time-out, the sliding 4050 window is partially closed and the ATO is backed off. 4052 Packet Processing Delay (PPD) 4054 The PPD parameter is a 16-bit time value exchanged during the Call 4055 Control phase expressed in units of tenths of a second (64 means 6.4 4056 seconds). The protocol only specifies that the parameter is 4057 exchanged, it does not specify how it is calculated. The way values 4058 for ATO are calculated is implementation-dependent and need not be 4059 variable (static time-outs are allowed). IF adaptive time-outs are 4060 to be used then the PPD should be exchanged in the call connect 4061 sequences. A possible way to calculate the PPD is: 4063 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 4064 + LACFudge (for an LAC) 4065 or 4066 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4067 + LNSFudge (for an LNS) 4069 Header is the total size of the L2TP and media dependent headers. 4070 MTU is the overall MTU for the link between the LAC and LNS. 4071 WindowSize represents the number of packets in the sliding window, 4072 and is implementation-dependent. The latency of the underlying 4073 connection path between the LAC and LNS could be used to pick a 4074 window size sufficient to keep the current session's pipe full. The 4075 constant 8 converts octets to bits (assuming ConnectRate is in bits 4076 per second). If ConnectRate is in bytes per second, omit the 8. 4077 LACFudge and LNSFudge are not required but can be used to take 4078 overall processing overhead of the LAC or LNS into account. 4080 In the case of the computed PPD for an LNS, AvePathRate is the 4081 average bit rate of the path between the LNS and LAC. Given that 4082 this number is probably very large and WindowSize is relatively 4083 small, LNSFudge will be the dominant factor in the computation of 4084 PPD. It is recommended that the minimum value of PPD be on the order 4085 of 0.5 second. 4087 The value of PPD is used to seed the adaptive algorithm with the 4088 initial RTT[n-1] value. 4090 A.1 Calculating Adaptive Acknowledgment Time-Out 4092 We still must decide how much time to allow for acknowledgments to 4093 return. If the time-out is set too high, we may wait an 4094 unnecessarily long time for dropped packets. If the time-out is too 4095 short, we may time out just before the acknowledgment arrives. The 4096 acknowledgment time-out should also be reasonable and responsive to 4097 changing network conditions. 4099 The suggested adaptive algorithm detailed below is based on the TCP 4100 1989 implementation and is explained in Richard Steven's book TCP/IP 4101 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 4102 calculation, and 'n-1' refers to values from the last calculation. 4104 DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta * 4105 (|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 4106 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 4108 DIFF represents the error between the last estimated round-trip 4109 time and the measured time. DIFF is calculated on each iteration. 4111 DEV is the estimated mean deviation. This approximates the 4112 standard deviation. DEV is calculated on each iteration and 4113 stored for use in the next iteration. Initially, it is set to 0. 4115 RTT is the estimated round-trip time of an average packet. RTT is 4116 calculated on each iteration and stored for use in the next 4117 iteration. Initially, it is set to PPD. 4119 ATO is the adaptive time-out for the next transmitted packet. ATO 4120 is calculated on each iteration. Its value is limited, by the MIN 4121 function, to be a maximum of the configured MaxTimeOut value. 4123 Alpha is the gain for the average and is typically 1/8 (0.125). 4125 Beta is the gain for the deviation and is typically 1/4 (0.250). 4127 Chi is the gain for the time-out and is typically set to 4. 4129 To eliminate division operations for fractional gain elements, the 4130 entire set of equations can be scaled. With the suggested gain 4131 constants, they should be scaled by 8 to eliminate all division. To 4132 simplify calculations, all gain values are kept to powers of two so 4133 that shift operations can be used in place of multiplication or 4134 division. The above calculations are carried out each time an 4135 acknowledgment is received for a packet that was not retransmitted 4136 (no time-out occurs). 4138 A.2 Congestion Control: Adjusting for Time-Out 4140 This section describes how the calculation of ATO is modified in the 4141 case where a time-out does occur. When a time-out occurs, the time- 4142 out value should be adjusted rapidly upward. Although L2TP payload 4143 packets are not retransmitted when a time-out occurs, the time-out 4144 should be adjusted up toward a maximum limit. To compensate for 4145 shifting internetwork time delays, a strategy must be employed to 4146 increase the time-out when it expires. A simple formula called 4147 Karn's Algorithm is used in TCP implementations and may be used in 4148 implementing the backoff timers for the LNS or the LAC. Notice that 4149 in addition to increasing the time-out, we also shrink the size of 4150 the window as described in the next section. 4152 Karn's timer backoff algorithm, as used in TCP, is: 4154 NewTIMEOUT = delta * TIMEOUT 4156 Adapted to our time-out calculations, for an interval in which a 4157 time-out occurs, the new time-out interval ATO is calculated as: 4159 RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MIN (RTT[n] + 4160 (chi * DEV[n]), MaxTimeOut) 4162 In this modified calculation of ATO, only the two values that 4163 contribute to ATO and that are stored for the next iteration are 4164 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 4165 not carried forward and is not used in this scenario. A value of 2 4166 for Delta, the time-out gain factor for RTT, is suggested. 4168 Appendix B: Acknowledgment Time-Out and Window Adjustment 4170 B.1 Initial Window Size 4172 Although each side has indicated the maximum size of its receive 4173 window, it is recommended that a slow start method be used to begin 4174 transmitting data. The initial maximum window size on the 4175 transmitter is set to half the maximum size the receiver requested, 4176 with a minimum size of one packet. The transmitter stops sending 4177 packets when the number of packets awaiting acknowledgment is equal 4178 to the current maximum window size. As the receiver successfully 4179 digests each window, the maximum window size on the transmitter is 4180 bumped up by one packet until the maximum specified by the receiver 4181 is reached. This method prevents a system from flooding an already 4182 congested network because no history has been established. 4184 When for any reason an LAC or LNS receives more data than it can 4185 queue for the tunnel, a packet must be discarded. In this case, it 4186 is recommended that a "random early discard" algorithm [6] be used 4187 rather than the obvious "drop last" algorithm. 4189 B.2 Closing the Window 4191 When a time-out does occur on a packet, the sender adjusts the size 4192 of the transmit window down to one half its maximum value when it 4193 failed. Fractions are rounded up, and the minimum window size is 4194 one. 4196 B.3 Opening the Window 4198 With every successful transmission of a window's worth of packets 4199 without a time-out, the maximum transmit window size is increased by 4200 one packet until it reaches the maximum window size that was sent by 4201 its peer when the call was connected. As stated earlier, no 4202 retransmission is done on a time-out. After a time-out, transmission 4203 resumes with the maximum transmit window starting at one half the 4204 size of the maximum transmit window when the time-out occurred (with 4205 a minimum window size of 1) and adjusting upward by one each time the 4206 current maximum transmit window is filled with packets that are all 4207 acknowledged without time-outs. 4209 B.4 Window Overflow 4211 When a receiver's window overflows with too many incoming packets, 4212 excess packets are thrown away. This situation should not arise if 4213 the sliding window procedures are being properly followed by the 4214 transmitter and receiver. It is assumed that, on the transmit side, 4215 packets are buffered for transmission and are no longer accepted from 4216 the packet source when the transmit buffer fills. 4218 Appendix C: Handling of out-of-order packets 4220 When the Sequence Number and Acknowledgment Number fields are present 4221 in payload packets, they are used to manage packet rate. In 4222 addition, they may be used to handle out-of-order arrival of packets. 4223 A simple L2TP client would simply discard any packet other than a 4224 packet with a sequence greater than that last received; if packets 1, 4225 2, 3 arrived as 1, 3, 2, this would result in packet 2 being 4226 discarded. 4228 Such behavior does not affect the L2TP protocol itself, but 4229 significantly improved throughput in such environments may be 4230 attained by queueing and reordering packets when they arrive out of 4231 order. The number of packets to be queued is a function of memory 4232 resources on the L2TP implementation, but should never be more than 4233 1/4 of the total sequence number space (i.e., 16384 packets), to 4234 avoid aliasing. 4236 An implementation which queues packets in this way must also employ 4237 an algorithm for deciding that a given sequence number corresponds to 4238 a packet which is lost, rather than one which is out of order but 4239 still in transit. Such a decision would likely be based upon timing, 4240 buffering conditions, and packet arrival characteristics. The 4241 details of such a tradeoff are outside the scope of this 4242 specification, but it is recommended a packet should be afforded an 4243 interval at least twice the estimated RTT from the L2TP peer. 4245 Appendix D: Transport Layer Adaptive Time-outs and Window Adjustment 4247 Appendixes A, B, and C dealt with operation of the payload packet 4248 sessions of L2TP. This Appendix explains how these three algorithms 4249 pertain to the transport layer for L2TP control sessions. Appendix B, 4250 Time-out Window Management, directly applies to the Transport Layer 4251 except in the case where a window size of 1 is being used. Appendix 4252 C, does not really apply because, for the Control Session, control 4253 messages MUST always be processed by the receiver in order. Also, 4254 there are no lost control packets because they are retransmitted by 4255 the L2TP Transport Layer. Thus, the main topic of this Appendix is 4256 how to adapt the example adaptive time-out algorithm of Appendix A to 4257 the Control Session Transport Layer. 4259 There are two main differences between the Control Session and 4260 payload sessions: 1) Unlike lost payload packets, lost control 4261 messages are retransmitted and 2) There is no Packet Processing Delay 4262 value provided in the control session setup messages. The latter 4263 affects the manner in which the initial value of the RTT estimate is 4264 determined. The former really doesn't affect the algorithm at all, 4265 except that upon a time-out, retransmission of unacknowledged control 4266 messages should be attempted, up to the number that fit in the 4267 sliding window with size computed as in Appendix B. 4269 Using the symbol definitions of Appendix A, the calculation of the 4270 value for the PPD of the remote peer can be estimated as: 4272 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4273 + Fudge 4275 This is simply the number of bits in a full control session window 4276 divided by the average speed of the path between the LAC and LNS with 4277 a fudge factor added on to make it work. In cases where the average 4278 rate of the connection between LAC and LNS isn't known, it is 4279 suggested that some value be configured that is associated with each 4280 possible peer. Because Control Session windows will most likely be 4281 small and the connection speed will be quite high, fudge will be the 4282 dominant factor in this calculation. For this reason, just 4283 configuring a single fixed initial PPD estimate to be used for all 4284 possible peers will probably provide adequate results. This fudge 4285 factor should probably be at least 0.5 second. 4287 Appendix E: Examples of L2TP sequence numbering 4289 Although sequence numbers serve distinct purposes for control and 4290 data messages, both types of messages use identical techniques for 4291 assigning sequence numbers. This appendix shows several common 4292 scenarios, and illustrates how sequence number state progresses and 4293 is interpreted. 4295 E.1: Lock-step tunnel establishment 4297 In this example, an LAC establishes a tunnel, with the exchange 4298 involving each side alternating in sending messages. This example 4299 is contrived, in that the final acknowledgment in the example is 4300 explicitly sent within a zero-length message, although most 4301 typically the acknowledgment would have been included in the 4302 processing of the Incoming-Call-Request which had prompted the LAC 4303 to initiate the tunnel in the first place. 4305 LAC LNS 4306 -> Start-Control-Connection-Request 4307 Nr: 0, Ns: 0 4309 Start-Control-Connection-Reply <- 4310 Nr: 1, Ns: 0 4312 -> Start-Control-Connection-Connected 4313 Nr: 1, Ns: 1 4315 (delay) 4317 (zero-length) <- 4318 Nr: 2, Ns: 1 4320 E.2: Multiple packets acknowledged 4322 This example shows a flow of payload packets from the LNS to the 4323 LAC, with the LAC having no traffic of its own. The LAC is 4324 waiting 1/4 of its timeout interval, and then acknowledging all 4325 packets seen since the last interval. 4327 (previous packet flow precedes this) 4329 LAC LNS 4330 -> (zero-length) 4331 Nr: 7000, Ns: 1000 4332 (payload) <- 4333 Nr: 1000, Ns: 7000 4334 (payload) <- 4335 Nr: 1000, Ns: 7001 4336 (payload) <- 4337 Nr: 1000, Ns: 7002 4339 (LAC's timer indicates it should acknowledge pending traffic) 4341 -> (zero-length) 4342 Nr: 7003, Ns: 1000 4344 E.3: Lost packet with retransmission 4346 As a final example, an existing tunnel has a new session requested 4347 by the LAC. The Incoming-Call-Reply is lost and must be 4348 retransmitted by the LNS. This example continues from the 4349 sequence state reached at the end of example E.1. Note that loss 4350 of the -Reply has two impacts: not only does it keep the upper 4351 level state machine from progressive, but it also keeps the LAC 4352 from seeing a timely lower level acknowledgment of its -Request 4353 packet. 4355 LAC LNS 4356 -> Incoming-Call-Request 4357 Nr: 1, Ns: 2 4359 Incoming-Call-Reply <- 4360 Nr: 3, Ns: 1 4362 (pause; LAC's timer started first, so fires first) 4363 -> Incoming-Call-Request 4364 Nr: 1, Ns: 2 4366 (LNS realizes it has already seen this packet) 4367 (LNS might use this as a cue to retransmit, as in this example) 4369 Incoming-Call-Reply <- 4370 Nr: 3, Ns: 1 4371 -> Incoming-Call-Connected 4372 Nr: 2, Ns: 3 4374 (delay) 4376 (zero-length) <- 4377 Nr: 4, Ns: 2