idnits 2.17.1 draft-ietf-pppext-l2tp-09.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 90 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 90 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 29 instances of too long lines in the document, the longest one being 8 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 155: '... o MUST, SHALL, or MANDATORY --...' RFC 2119 keyword, line 158: '... o SHOULD or RECOMMEND -- This ...' RFC 2119 keyword, line 161: '... o MAY or OPTIONAL -- This item...' RFC 2119 keyword, line 405: '...s it. Rejection MUST include a result...' RFC 2119 keyword, line 701: '...e of 0 is thus special and MUST NOT be...' (132 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3722 has weird spacing: '...e local wai...' == Line 3723 has weird spacing: '...ndicate tunne...' == Line 3890 has weird spacing: '...e local wai...' == 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 357 -- Looks like a reference, but probably isn't: 'R' on line 359 -- Looks like a reference, but probably isn't: 'U' on line 360 -- Looks like a reference, but probably isn't: 'L' on line 358 -- Looks like a reference, but probably isn't: 'N' on line 361 -- 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' ** Obsolete normative reference: RFC 2058 (ref. '8') (Obsoleted by RFC 2138) -- Possible downref: Non-RFC (?) normative reference: ref. '12' == Outdated reference: A later version (-08) exists of draft-ietf-radius-tunnel-auth-04 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-auth (ref. '13') Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group K. Hamzeh, A. Rubens 3 INTERNET DRAFT Ascend Communications 4 Category: Internet Draft T. Kolar, M. Littlewood, 5 Title: draft-ietf-pppext-l2tp-09.txt B. Palter, A. Valencia 6 Date: January 1998 Cisco Systems 7 J. Taarud 8 Copper Mountain Networks 9 W. M. Townsley 10 IBM Corporation 11 G. S. Pall 12 Microsoft Corporation 13 W. Verthein 14 3COM Corporation 16 Layer Two Tunneling Protocol "L2TP" 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months. Internet-Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet- 28 Drafts as reference material or to cite them other than as a 29 ``working draft'' or ``work in progress.'' 31 To learn the current status of any Internet-Draft, please check the 32 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 33 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 34 munnari.oz.au. 36 Abstract 38 Virtual dial-up allows many separate and autonomous protocol domains 39 to share common access infrastructure including modems, Access 40 Servers, and ISDN routers. RFC1661 specifies multi-protocol dial-up 41 via PPP [1]. This document describes the Layer Two Tunneling 42 Protocol (L2TP) which permits the tunneling of the link layer (i.e., 43 HDLC, async HDLC) of PPP. Using such tunnels, it is possible to 44 divorce the location of the initial dial-up server from the location 45 at which the dial-up protocol connection is terminated and access to 46 the network provided. 48 Table of Contents 50 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.0 Problem Space Overview . . . . . . . . . . . . . . . . . . 6 54 2.1 Initial Assumptions . . . . . . . . . . . . . . . . . . . 6 55 2.2 Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 2.3 Providing Virtual Dial-up Services--a walk-through . . . . 7 57 3.0 Service Model Issues . . . . . . . . . . . . . . . . . . . 9 58 3.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 3.2 Address Allocation . . . . . . . . . . . . . . . . . . . . 10 60 3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 10 61 3.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.0 Protocol Overview . . . . . . . . . . . . . . . . . . . . 11 63 4.1 Control Message Overview . . . . . . . . . . . . . . . . . 13 64 4.2 Payload Packet Overview . . . . . . . . . . . . . . . . . 14 65 4.3 Congestion Control . . . . . . . . . . . . . . . . . . . . 16 66 5.0 Message Format and Protocol Extensibility . . . . . . . . 18 67 5.1 AVP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 5.2 Control Message Format . . . . . . . . . . . . . . . . . . 19 69 5.3 Payload Message Format . . . . . . . . . . . . . . . . . . 20 70 5.4 Control Message Types . . . . . . . . . . . . . . . . . . 22 71 5.5 AVP Summary . . . . . . . . . . . . . . . . . . . . . . . 22 72 5.6 Result and Error Code Summary . . . . . . . . . . . . . . 26 73 5.7 Hiding of AVP values . . . . . . . . . . . . . . . . . . . 26 74 6.0 Control Connection Protocol Specification . . . . . . . . 28 75 6.1 Start-Control-Connection-Request . . . . . . . . . . . . . 30 76 6.2 Start-Control-Connection-Reply . . . . . . . . . . . . . . 35 77 6.3 Start-Control-Connection-Connected . . . . . . . . . . . . 40 78 6.4 Stop-Control-Connection-Notification . . . . . . . . . . . 41 79 6.5 Hello . . . . . . . . . . . . . . . . . . . . . . . . . . 42 80 6.6 Outgoing-Call-Request . . . . . . . . . . . . . . . . . . 43 81 6.7 Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . 48 82 6.8 Outgoing-Call-Connected . . . . . . . . . . . . . . . . . 49 83 6.9 Incoming-Call-Request . . . . . . . . . . . . . . . . . . 52 84 6.10 Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 55 85 6.11 Incoming-Call-Connected . . . . . . . . . . . . . . . . . 57 86 6.12 Call-Disconnect-Notify . . . . . . . . . . . . . . . . . 64 87 6.13 WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . 66 88 6.14 Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 67 89 7.0 Control Connection State Machines . . . . . . . . . . . . 68 90 7.1 Control Connection Protocol Operation . . . . . . . . . . 69 91 7.2 Control Connection States . . . . . . . . . . . . . . . . 69 92 7.2.1 Control Connection Establishment . . . . . . . . . . . . 69 93 7.3 Timing considerations . . . . . . . . . . . . . . . . . . 71 94 7.4 Incoming Calls . . . . . . . . . . . . . . . . . . . . . . 71 95 7.4.1 LAC Incoming Call States . . . . . . . . . . . . . . . . 71 96 7.4.2 LNS Incoming Call States . . . . . . . . . . . . . . . . 72 97 7.5 Outgoing calls . . . . . . . . . . . . . . . . . . . . . . 73 98 7.5.1 LAC Outgoing Call States . . . . . . . . . . . . . . . . 74 99 7.5.2 LNS Outgoing Call States . . . . . . . . . . . . . . . . 74 100 7.6 Tunnel Disconnection . . . . . . . . . . . . . . . . . . . 75 101 8.0 L2TP Over Specific Media . . . . . . . . . . . . . . . . . 76 102 8.1 IP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 76 103 8.2 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 104 9.0 Security Considerations . . . . . . . . . . . . . . . . . 77 105 9.1 Tunnel Endpoint Security . . . . . . . . . . . . . . . . . 77 106 9.2 Client Security . . . . . . . . . . . . . . . . . . . . . 78 107 9.3 Proxy Authentication . . . . . . . . . . . . . . . . . . . 79 108 10.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 79 109 11.0 Contacts . . . . . . . . . . . . . . . . . . . . . . . . 79 110 12.0 References . . . . . . . . . . . . . . . . . . . . . . . 80 111 Appendix A: Acknowledgment Time-Outs . . . . . . . . . . . . . 81 112 Appendix B: Acknowledgment Time-Out and Window Adjustment . . 85 113 Appendix C: Handling of out-of-order packets . . . . . . . . . 86 114 Appendix D: Transport Layer Adaptive Time-Outs 115 and Window Adjustment . . . . . . . . . . . . . . 86 116 Appendix E: Examples of L2TP sequence numbering . . . . . . . 87 118 1.0 Introduction 120 The traditional dial-up network service on the Internet is for 121 registered IP addresses only. A new class of virtual dial-up 122 application which allows multiple protocols and unregistered IP 123 addresses is also desired on the Internet. Examples of this class of 124 network application are support for privately addressed IP, IPX, and 125 AppleTalk dial-up via PPP across existing Internet infrastructure. 127 The support of these multi-protocol virtual dial-up applications is 128 of significant benefit to end users, enterprises, and Internet 129 Service providers as it allows the sharing of very large investments 130 in access and core infrastructure and allows local calls to be used. 131 It also allows existing investments in non-IP protocol applications 132 to be supported in a secure manner while still leveraging the access 133 infrastructure of the Internet. 135 It is the purpose of this document to identify the issues encountered 136 in integrating multi-protocol dial-up services into an existing 137 Internet Service Provider's Point of Presence (hereafter referred to 138 as ISP and POP, respectively), and to describe the L2TP protocol 139 which permits the leveraging of existing access protocols. 141 This protocol may also be used to solve the "multilink hunt-group 142 splitting" problem. Multilink PPP [9], often used to aggregate ISDN B 143 channels, requires that all channels composing a multilink bundle be 144 grouped at a single NAS. Because L2TP makes a PPP session terminate 145 at a location other than the point at which the session was 146 physically received, it can be used to make all channels terminate at 147 a single NAS, allowing multilink operation even when the physical 148 calls are spread across distinct physical NAS's. 150 1.1 Conventions 152 The following language conventions are used in the items of 153 specification in this document: 155 o MUST, SHALL, or MANDATORY -- This item is an absolute 156 requirement of the specification. 158 o SHOULD or RECOMMEND -- This item should generally be followed 159 for all but exceptional circumstances. 161 o MAY or OPTIONAL -- This item is truly optional and may be 162 followed or ignored according to the needs of the implementor. 164 1.2 Terminology 166 Analog Channel 168 A circuit-switched communication path which is intended to carry 169 3.1 kHz audio in each direction. 171 Control Connection 173 A control connection operates in-band over a tunnel to control the 174 establishment, release, and maintenance of sessions and of the 175 tunnel itself. 177 Digital Channel 179 A circuit-switched communication path which is intended to carry 180 digital information in each direction. 182 Call 184 A connection or attempted connection between two terminal 185 endpoints. For example, a telephone call through the PSTN between 186 two modems. (See also: Session). 188 CHAP 190 Challenge Authentication Protocol, a PPP cryptographic 191 challenge/response authentication protocol in which the cleartext 192 password is not passed over the line. 194 CLID 196 Calling Line ID, an indication to the receiver of a call as to the 197 phone number of the caller. 199 Control Messages 200 Control messages are exchanged between LAC and LNS pairs, 201 operating in-band within the tunnel protocol. Control messages 202 govern aspects of the tunnel and sessions within the tunnel. 204 Dial User 206 An end-system or router attached to an on-demand PSTN or ISDN 207 which is either the initiator or recipient of a call. Also 208 referred to as a dial-up or Virtual dial-up client. 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 the switched network fabric (e.g. PSTN or 223 ISDN) or co-located with a PPP end system capable of handling the 224 L2TP protocol. The LAC needs only implement the media over which 225 L2TP is to operate to pass traffic to one or more LNS's. It may 226 tunnel any protocol carried within PPP. The LAC is the initiator 227 of incoming calls and the receiver of outgoing calls. 229 L2TP Network Server (LNS) 231 An LNS operates on any platform capable of PPP termination. The 232 LNS handles the server side of the L2TP protocol. Since L2TP 233 relies only on the single media over which L2TP tunnels arrive, 234 the LNS may have only a single LAN or WAN interface, yet still be 235 able to terminate calls arriving at any LAC's full range of PPP 236 interfaces (async, synchronous ISDN, V.120, etc.). The LNS is the 237 initiator of outgoing calls and the receiver of incoming calls. 239 Network Access Server (NAS) 241 A device providing temporary, on-demand network access to users. 242 This access is point-to-point typically using PSTN or ISDN lines. 243 A NAS may also serve as an LAC, LNS or both. 245 PAP 247 Password Authentication Protocol, a simple PPP authentication 248 mechanism in which a cleartext username and password are 249 transmitted to prove identity. 251 POP 253 An Internet Service Provider's Point of Presence. 255 Quality of Service (QOS) 257 A given Quality of Service level is sometimes required for a given 258 user being tunneled between an LNS-LAC pair. For this scenario, a 259 unique L2TP tunnel is created (generally on top of a new SVC) and 260 encapsulated directly on top of the media providing the indicated 261 QOS. 263 Session 265 L2TP is connection-oriented. The LNS and LAC maintain state for 266 each user that is attached to an LAC. A session is created when 267 an end-to-end PPP connection is attempted between a dial user and 268 the LNS, or when an outbound call is initiated. The datagrams 269 related to a session are sent over the tunnel between the LAC and 270 LNS. (See also: Call). 272 Switched Virtual Circuit (SVC) 274 An L2TP-compatible media on top of which L2TP is directly 275 encapsulated. SVC's are dynamically created, permitting tunnel 276 media to be created dynamically in response to desired LNS-LAC 277 connectivity requirements. 279 Tunnel 281 A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP 282 datagrams between the LAC and the LNS; many sessions can be 283 multiplexed over a single tunnel. A control connection operating 284 in-band over the same tunnel controls the establishment, release, 285 and maintenance of sessions and of the tunnel itself. A tunnel is 286 sometimes referred to as a control connection. 288 Zero-Length Body (ZLB) Message 290 A control or payload packet with only an L2TP header, and no 291 control message information or PPP payload. ZLB messages are used 292 for explicitly acking packets on the control or data channel. 294 2.0 Problem Space Overview 296 In this section we describe in high level terms the scope of the 297 problem that will be explored in more detail in later sections. 299 2.1 Initial Assumptions 301 We begin by assuming that Internet access is provided by an ISP and 302 that the ISP wishes to offer services other than traditional 303 registered IP address based services to dial-up users of the network. 305 We also assume that the user of such a service wants all of the 306 security facilities that are available to him or her in a dedicated 307 dial-up configuration. In particular, the end user requires: 309 + End System transparency: Neither the remote end system nor his 310 home site hosts should require any special software to use this 311 service in a secure manner. 313 + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or 314 through other dialogs, for instance, a textual exchange on V.120 315 before starting PPP. This will include TACACS+ [7] and RADIUS [8] 316 solutions as well as support for smart cards and one-time passwords. 317 The authentication should be manageable by the user independently of 318 the ISP. 320 + Addressing should be as manageable as dedicated dial-up solutions. 321 The address should be assigned by the home site and not the ISP. 323 + Authorization should be managed by the home site as it would in a 324 direct dial-up solution. 326 + Accounting should be performed both by the ISP (for billing 327 purposes) and by the user (for charge-back and auditing). 329 2.2 Topology 331 Shown below is a generic Internet with Public switched Telephone 332 Network (PSTN) access (i.e., async PPP via modems) and Integrated 333 Services Digital Network (ISDN) access (i.e., synchronous PPP 334 access). Remote users (either async or ISDN PPP) will access the 335 Home LAN as if they were dialed into the L2TP Network Server (LNS), 336 although their physical dial-up is via the ISP Network Access Server 337 (acting as the LAC). 339 ...----[L]----+---[L]-----... 340 | 341 | 342 [H] 343 | 344 ________|________________________ 345 | | 346 ________|__ ______|________ 347 | | | | 348 | PSTN [R] [R] ISDN | 349 | Cloud | | Cloud [N]__[U] 350 | | Internet | | 351 | | [R] | 352 [N]______[R] |_____________| 353 | | | 354 | | | 355 [U] |________________________________| 357 [H] = LNS 358 [L] = Home LAN(s) 359 [R] = Router 360 [U] = Remote User 361 [N] = ISP Network Access Server (LAC) 363 2.3 Providing Virtual dial-up Services--a walk-through 365 To motivate the following discussion, this section walks through an 366 example of what might happen when a Virtual dial-up client initiates 367 access. 369 A Network Access Server (NAS) operating as a peer to an LNS is 370 referred to as an L2TP Access Concentrator, or "LAC". 372 The remote user initiates a PPP connection to an ISP via either the 373 PSTN or ISDN. The LAC accepts the connection and the PPP link is 374 established (L2TP also permits the LAC to check with an LNS after 375 call indication prior to accepting the call--this is useful where 376 DNIS or CLID information is available in the incoming call 377 notification). 379 The ISP may now undertake a partial authentication of the end 380 system/user. Only the username field would be interpreted to 381 determine whether the user requires a Virtual dial-up service. It is 382 expected--but not required--that usernames will be structured (e.g. 383 username@company.com). Alternatively, the ISP may maintain a 384 database mapping users to services. In the case of Virtual dial-up, 385 the mapping will name a specific endpoint, the LNS. 387 Alternatively, the ISP may have already determined the target LNS 388 from DNIS. If the LNS is willing to accept tunnel creation without 389 any authentication of the caller, the LAC may tunnel the PPP 390 connection without ever having communicated with the remote user. 392 If a virtual dial-up service is not required, standard access to the 393 Internet may be provided. 395 If no tunnel connection currently exists to the desired LNS, one is 396 initiated. L2TP is designed to be largely insulated from the details 397 of the media over which the tunnel is established; L2TP requires only 398 that the tunnel media provide packet oriented point-to-point 399 connectivity. Obvious examples of such media are UDP, Frame Relay 400 PVC's, or X.25 VC's. 402 Once the tunnel exists, an unused slot within the tunnel, a "Call 403 ID", is allocated, and a connect indication is sent to notify the LNS 404 of this new dial-up session. The LNS either accepts the connection, 405 or rejects it. Rejection MUST include a result condition and MAY 406 include an error indication, which may be displayed to the dial-up 407 user, after which the call should be disconnected. 409 The initial connect notification may include the authentication 410 information required to allow the LNS to authenticate the user and 411 decide to accept or decline the connection. In the case of CHAP, the 412 set-up packet includes the challenge, username and raw response. For 413 PAP or text dialog, it includes username and clear text password. 414 The LNS may choose to use this information to complete its 415 authentication, avoiding an additional cycle of authentication. 417 If the LAC negotiated PPP LCP before initiating the tunnel, the 418 initial connect notification may also include a copy of the LCP 419 CONFREQ's sent in each direction which completed LCP negotiation. 420 The LNS may use this information to initialize its own PPP state 421 (thus avoiding an additional LCP negotiation), or it may choose to 422 initiate a new LCP CONFREQ exchange. 424 If the LNS accepts the connection, it creates a "virtual interface" 425 for PPP in a manner analogous to what it would use for a direct- 426 dialed connection. With this "virtual interface" in place, link 427 layer frames may now pass over this tunnel in both directions. 428 Frames from the remote user are received at the POP, stripped of CRC, 429 link framing, and transparency bytes, encapsulated in L2TP, and 430 forwarded over the appropriate tunnel. 432 The LNS accepts these frames, strips L2TP, and processes them as 433 normal incoming frames for the appropriate interface and protocol. 434 The "virtual interface" behaves very much like a hardware interface, 435 with the exception that the hardware in this case is physically 436 located at the ISP POP. The other direction behaves analogously, 437 with the LNS encapsulating the packet in L2TP, and the LAC stripping 438 L2TP before transmitting it out the physical interface to the remote 439 user. 441 At this point, the connectivity is a point-to-point PPP session whose 442 endpoints are the remote user's networking application on one end and 443 the termination of this connectivity into the LNS's PPP support on 444 the other. Because the remote user has become simply another dial-up 445 client of the LNS, client connectivity can now be managed using 446 traditional mechanisms with respect to further authorization, 447 protocol access, and packet filtering. 449 Accounting can be performed at both the LAC as well as the LNS. This 450 document illustrates some Accounting techniques which are possible 451 using L2TP, but the policies surrounding such Accounting are outside 452 the scope of this specification. 454 L2TP offers optional facilities which maximize compatibility with 455 legacy client requirements; L2TP connect notifications for PPP 456 clients can contain sufficient information for an LNS to authenticate 457 and initialize its LCP state machine. With these facilities, the 458 remote user need not be queried a second time for PPP authentication, 459 nor undergo multiple rounds of LCP negotiation and convergence. 460 These techniques are intended to optimize connection setup, and are 461 not intended to deprecate any functions required by the PPP 462 specification. 464 3.0 Service Model Issues 466 There are several significant differences between the standard 467 Internet access service and the Virtual dial-up service with respect 468 to authentication, address allocation, authorization and accounting. 469 The details of the differences between these services and the 470 problems presented by these differences are described below. The 471 mechanisms used for Virtual Dial-up service are intended to coexist 472 with more traditional mechanisms; it is intended that an ISP's POP 473 can simultaneously service ISP clients as well as Virtual dial-up 474 clients. 476 3.1 Security 478 For the Virtual dial-up service, the ISP pursues authentication only 479 to the extent required to discover the user's apparent identity (and 480 by implication, their desired LNS). This may involve no more than 481 detecting DNIS information when a call arrives, or may involve full 482 LCP negotiation and initiation of PPP authentication. As soon as the 483 apparent identity is determined, a call request to the LNS is 484 initiated with any authentication information gathered by the ISP. 485 The LNS completes the authentication by either accepting the call, or 486 rejecting it. 488 The LNS may need to protect against attempts by third parties to 489 establish tunnels to the LNS. Tunnel establishment can include 490 authentication to protect against such attacks. 492 3.2 Address Allocation 494 For a traditional Internet service, the user typically accepts that 495 the IP address may be allocated dynamically from a pool of ISP 496 addresses. This model often means that the remote user has little or 497 no access to their home network's resources, due to firewalls and 498 other security policies applied by the home network to accesses from 499 external IP addresses. 501 For the Virtual dial-up service, the LNS can exist behind the home 502 firewall, allocating addresses which are internal (and, in fact, can 503 be RFC1918 addresses, or non-IP addresses). Because L2TP tunnels 504 exclusively at the frame layer, the actual policies of such address 505 management are irrelevant to correct Virtual dial-up service; for all 506 purposes of PPP protocol handling, the dial-in user appears to have 507 connected at the LNS. 509 3.3 Authentication 511 The authentication of the user occurs in three phases; the first at 512 the ISP, and the second and optional third at the LNS. 514 The ISP uses DNIS, CLID, or username to determine that a Virtual 515 dial-up service is required and initiates the tunnel connection to 516 the appropriate LNS. Once a tunnel is established, The ISP NAS 517 allocates a new Call ID and initiates a session by forwarding the 518 gathered authentication information. 520 The LNS undertakes the second phase by deciding whether or not to 521 accept the call. The call start indication may include CHAP, PAP, 522 EAP, or textual authentication information. Based on this 523 information, the LNS may accept the call request, or may reject it 524 (for instance, it was a PAP request and the username/password are 525 found to be incorrect). 527 Once the call is accepted, the LNS is free to pursue a third phase of 528 authentication at the PPP layer. These activities are outside the 529 scope of this specification, but might include an additional cycle of 530 LCP authentication, proprietary PPP extensions, or textual challenges 531 carried via a TCP/IP telnet session. 533 3.4 Accounting 535 It is a requirement that both the LAC and the LNS be capable of 536 providing accounting data and hence both may count packets, octets 537 and connection start and stop times. 539 Since Virtual dial-up is an access service, accounting of connection 540 attempts (in particular, failed connection attempts) is of 541 significant interest. The LNS can reject new connections based on 542 the authentication information gathered by the LAC, with 543 corresponding logging. For cases where the LNS accepts the 544 connection and then continues with further authentication, the LNS 545 might subsequently disconnect the client. For such scenarios, the 546 disconnection indication back to the LAC may also include a reason. 548 Because the LNS can decline a connection based on the authentication 549 information collected by the LAC, accounting can easily draw a 550 distinction between a series of failed call attempts and a series of 551 brief successful connections. Lacking this facility, the LNS must 552 always accept connection requests, and would need to exchange a 553 number of PPP packets with the remote system. Note that the LNS 554 could use this information to decide to accept the connection (which 555 protects against most invalid connection attempts) while still 556 insisting on running its own CHAP authentication (for instance, to 557 protect against CHAP replay attacks). 559 4.0 Protocol Overview 561 There are two parallel components of L2TP operating over a given 562 tunnel: control messages between each LAC-LNS pair, and payload 563 packets between the same LAC-LNS pair. The latter are used to 564 transport L2TP encapsulated PPP packets for user sessions between the 565 pair. 567 Two fields important to the operation of L2TP are the Nr (Next 568 Received) and Ns (Next Sent) fields which are always present in 569 control messages, and are optionally present in payload packets. A 570 single sequence number state is maintained for all control messages, 571 and a distinct state is maintained for the payload of each user 572 session within the tunnel. In this document, the sequence number 573 state for a control connection and each user session is represented 574 for clarity in the following discussions by distinct pairs of state 575 variables, Sr and Ss. Sr represents the value of the next in- 576 sequence message expected to be received for a given session by a 577 peer. Ss represents the sequence number to be placed in the Ns field 578 of the next message sent for a given session by the sending peer. 579 Each state is initialized such that the first message sent and the 580 first message expected to be received for each session has an Ns 581 value of 0. This corresponds to initializing Ss and Sr in both peers 582 to 0 for each new session. 584 As messages are sent for a given session, Nr is set in these messages 585 to reflect one more than the Ns value of the highest (modulo 2**16) 586 in-order message received for that session; if sent before any packet 587 is received Nr will be 0, indicating that the peer expects the next 588 new Ns value received to be 0. When a non-zero-length message is 589 received with an Ns value that matches the session's current Sr 590 value, Sr is incremented by 1 (modulo 2**16). It is important to note 591 that, for both control and payload sessions, Sr is not modified if a 592 message is received with a value of Ns greater than the current Sr 593 value (exceptions to this rule being the permitted handling of out- 594 of-order payload packets by the "simple receiver" discussed in 595 Appendix C and handling of payload packets with the R-bit set). For 596 the control session, retransmission of outgoing messages should 597 eventually provide the receiving peer with the expected message. For 598 payload sessions, however, lost messages are never retransmitted so a 599 mechanism involving the use of the "Reset Sr" (R-bit) indicator in an 600 outgoing message is used to update the peer's value of Sr to the 601 value of Ns contained in the message. See Sec. 4.2 for details of 602 this mechanism. 604 Every time a peer sends a non-zero length message it increments its 605 corresponding Ss value for that session by 1 (modulo 2**16). This 606 increment takes place after the current Ss value is copied to Ns in 607 the message to be sent. Outgoing messages always include the current 608 value of Sr for the corresponding session in their Nr field. 610 A message (control or payload) with a zero-length body indicates that 611 the packet is only used to communicate Nr and Ns fields. The Nr and 612 Ns fields are filled in as above, but the sequence number state, Ss, 613 is not incremented. Thus a zero-length message sent after a non- 614 zero-length message will contain a new Ns value while a non-zero- 615 length message sent after a zero-length message will contain the same 616 value of Ns as the preceding zero-length message. Unless the Rbit is 617 set, a peer receiving a zero-length message does not update its Sr 618 variable. 620 Upon receipt of an in-order non-zero-length message, the receiving 621 peer must acknowledge the message by sending back the updated value 622 of Sr in the Nr field of the next outgoing message. This updated Sr 623 value can be piggybacked in the Nr field of any non-zero-length 624 outgoing messages that the peer may happen to send back. 626 If the peer does not have a message to transmit for a short period of 627 time after receiving a non-zero-length message then it should send a 628 zero-length message containing the latest values of Sr and Ss, as 629 described above. The suggested value for this time interval is 1/4 630 the receiving peer's value of Round-Trip-Time (RTT - see Appendix A), 631 if it computes RTT, or a maximum of 1/2 second otherwise. This 632 timeout should provide a reasonable opportunity for the receiving 633 peer to obtain a payload message destined for its peer, upon which 634 the ack of the received message can be piggybacked. 636 This timeout value should be treated as a suggested maximum; an 637 implementation could make this timeout quite small without adversely 638 affecting the protocol. To provide for better throughput, the 639 receiving peer should skip this timeout entirely and send a zero- 640 length message immediately in the case where its receive window fills 641 and it has no queued data to send for this connection or it can't 642 send queued data because the transmit window is closed. 644 A suggested implementation of this timer is as follows: Upon 645 receiving a non-zero-length message, the receiver starts a timer that 646 will expire in the recommended time interval. A variable, Lr (Last 647 Nr value sent), is used by the transmitter to store the last value 648 sent in the Nr field of a transmitted payload message for this 649 connection. Upon expiration of this timer, Sr is compared to Lr and, 650 if they are not equal, a zero-length ack is issued. If they are 651 equal, then no acks are outstanding and no action needs to be taken. 653 This timer should not be reinitialized if a new message is received 654 while it is active since such messages will be acked when the timer 655 expires. This ensures that periodic Acks are issued with a maximum 656 period equal to the recommended timeout interval. This interval 657 should be short enough to not cause false acknowledgment timeouts at 658 the transmitter when payload messages are being sent in one direction 659 only. Since such acks are being sent on what would otherwise be an 660 idle data path, their affect on performance should be small, if not 661 negligible. 663 See Appendix E for some examples of how sequence numbers progress. 665 4.1 Control Message Overview 667 Before PPP tunneling can occur between an LAC and LNS, control 668 messages must be exchanged between them. Control messages are 669 exchanged over the same tunnel which will be used to forward 670 payload data once L2TP call control and management information 671 have been passed. The control messages are responsible for 672 establishment, management, and release of sessions carried through 673 the tunnel, as well as status on the tunnel itself. It is the 674 means by which an LNS is notified of an incoming call at an 675 associated LAC, as well as the means by which an LAC is instructed 676 to place an outgoing call. 678 A tunnel may be established by either an LAC (for incoming calls) 679 or an LNS (for outgoing calls). Following the establishment of 680 the tunnel, the LNS and LAC configure the tunnel by exchanging 681 Start-Control-Connection-Request and -Reply messages. These 682 messages are also used to exchange information about basic 683 operating capabilities of the LAC and LNS. Once the control 684 message exchange is complete, the LAC may initiate sessions by 685 indicating inbound requests, or the LNS by requesting outbound 686 calls. If both ends of the tunnel have the ability to act as an 687 LAC and LNS concurrently, then nothing prohibits establishing 688 incoming or outgoing calls from both sides of the same tunnel. 689 Control messages may indicate changes in operating characteristics 690 of an individual user session with a Set-Link-Info message. 691 Individual sessions may be released by either the LAC or LNS, also 692 through control messages. 694 Independent Call ID values are established for each end of a user 695 session. The sender of a packet associated with a particular 696 session places the Call ID established by its peer in the Call ID 697 header field of all outgoing packets. For the cases where a Call 698 ID has not yet been assigned from the peer (i.e., during call 699 establishment of a new session), the Call ID field is sent as 0, 700 and further fields within the message are used to identify the 701 session. The Call ID value of 0 is thus special and MUST NOT be 702 used as an Assigned Call ID. 704 A mechanism for detection of tunnel connectivity problems is 705 provided by the reliable transport layer of L2TP. The transport 706 layer of L2TP performs control message retransmission. If the 707 number of retransmission attempts for a given control message 708 exceeds a configured maximum value, the tunnel is reset. This 709 retransmission mechanism exists in both the LNS and LAC ends of 710 the tunnel. 712 A keepalive mechanism is employed by the L2TP higher layer in 713 order to differentiate tunnel outages from extended periods of no 714 control or data activity on a tunnel. This is accomplished by the 715 higher layer injecting Hello control messages into the control 716 stream after a specified period of time elapses since the last 717 data or control message was received on the tunnel. As for any 718 other control message, if the transport does not receive an ACK 719 for the Hello message after the normal number of retransmissions 720 the tunnel is declared down and is reset. The transport layer 721 reset mechanism along with the injection of Hello messages ensures 722 that a connectivity failure between the LNS and the LAC will be 723 detected at both ends of a tunnel in a timely manner. 725 It is intended that control messages will also carry management 726 related information in the future, such as a message allowing the 727 LNS to request the status of a given LAC; these message types are 728 not defined in this document. 730 4.2 Payload Packet Overview 732 Once a tunnel is established and control messages have completed 733 tunnel setup, the tunnel can be used to carry user session PPP 734 packets for sessions involving a given LNS-LAC pair. The "Call 735 ID" field in the L2TP header indicates to which session a 736 particular PPP packet belongs. In this manner, PPP packets are 737 multiplexed and demultiplexed over a single tunnel between a given 738 LNS-LAC pair. The "Call ID" field value is established during the 739 exchange of call setup control messages. 741 It is legal for multiple tunnels to exist between a given LNS-LAC 742 pair. This is useful where each tunnel is used for a single user 743 session, and the tunnel media (an SVC, for instance) has specific 744 QOS attributes dedicated to a given user. L2TP provides a tunnel 745 identifier so that individual tunnels can be identified, even when 746 arriving from a single source LAC or LNS. 748 The L2TP header also contains optional acknowledgment and 749 sequencing information that can be used to perform congestion and 750 flow control over the tunnel (See section 4.3). Control messages 751 are used to determine rate and buffering parameters that are used 752 to regulate the flow of PPP packets for a particular session over 753 the tunnel. 755 The receiving peer indicates whether congestion control is to be 756 performed for payload packets sent to it. If a peer issues a 757 Receive Window Size AVP with a non-zero value during session 758 establishment then the sending peer MUST abide by the indicated 759 window size value as long as sequence numbers are provided. If a 760 receiving peer does not wish to flow control the payload packets 761 sent to it, it should not issue the Receive Window Size AVP with a 762 non-zero value. Issuing a Receive Window Size AVP with a zero 763 value has special significance. It indicates that the receiver 764 does not want to perform flow-control but it does want the sending 765 peer to provide Ns values in payload packets so that it can detect 766 (and perhaps reorder) packets received out of order. 768 In the case where neither peer issues a Receive Window Size AVP 769 during session establishment, the optional Nr and Ns fields are 770 absent in all payload packets for that session. In the case where 771 either peer wishes to perform flow-control or to detect out-of- 772 order receive messages (as indicated by the sending of the Receive 773 Window Size AVP with non-zero or zero value, respectively) the Nr 774 and Ns fields MUST be present in payload packets sent by both 775 peers. Both MUST begin the session providing proper Nr and Ns 776 values in all data packets transmitted. A proper Ns value starts 777 at 0 and increments by one for each transmitted payload message 778 and a proper Nr value is the current value of the receive sequence 779 number state variable, Sr. 781 Unless the LAC sends the Sequencing Required AVP (see section 6.7 782 and 6.8) in the ICCN or OCCN message, the LNS has the authority to 783 dynamically enable or disable sending of Ns/Nr and hence 784 controlling the capability of reordering and flow control over the 785 link. To disable sequence numbers, the LNS sends a packet with 786 the F-bit set to 0 and Ns/Nr fields not present. The LAC, upon 787 receiving such a data packet, MUST process the packet and 788 discontinue inclusion of Ns/Nr fields in any subsequent data 789 packets. Any packets which have been received by L2TP but are 790 being held in queue by for reordering SHOULD be flushed without 791 waiting for an ACK from the peer (as if an R-bit packet with Ns 792 equal to the current Sr value was received). Ss and Sr should be 793 updated and saved accordingly. 795 All data packets will continue to be exchanged without sequence 796 numbers until the end of the session or until the LNS resumes 797 sequence numbers by sending a packet with the F-bit set and Ns/Nr 798 present. The LAC, upon receiving a packet with the F bit set, MUST 799 resume sending sequence numbers in further packets. In order to 800 properly resume, the LNS and LAC MUST preserve the state of Ss and 801 Sr between periods of disabled sequencing. 803 While the LNS may initiate disabling of sequencing at any time 804 during the session (including the first data packet sent), it is 805 recommended that for links where reordering or packet loss may 806 occur, sequence numbers always be enabled during the initial 807 negotiation stages of PPP and disabled only when and if the risk 808 is considered acceptable. For instance, if the PPP session being 809 tunneled is not utilizing any stateful compression or encryption 810 protocols and is only carrying IP (as determined by the NCPs that 811 are established), then the LNS might decide to disable sequencing, 812 thus allowing higher level protocols to perform necessary flow 813 control end to end and reducing the per packet L2TP processing 814 burden on the LNS substantially. Note that this effectively 815 disables the ability of L2TP to detect or reorder PPP frames. 816 Further discussion of some of the tradeoffs associated with 817 disabling sequencing over media which may reorder or silently drop 818 packets is given in section 8.2. 820 4.3 Congestion Control 822 If a receiving peer offers a non-zero receive window size to a 823 sending peer then the sending peer MUST abide by this window size 824 value as long as sequence numbers are being exchanged. The 825 sending peer MUST stop sending payload packets when the window is 826 full; i.e., x consecutive messages have been sent but have not 827 been acknowledged, where x is the value of the Receive Window Size 828 AVP. Implementors should take care to avoid the situation where 829 loss of an ACK by a sending peer with a full transmit window 830 causes a session to hang forever, due to the fact there are no 831 retransmissions of payload packets. Steps must be taken to reopen 832 the transmit window (at least to a value of 1) upon expiration of 833 an ACK wait timeout. See Appendix B for more details. 835 When sending to a peer that has issued a non-zero receive window 836 size, the sending peer is responsible for resetting the receiver's 837 Sr value when a sent payload message is lost during transmission. 838 When a sent message is lost, the receiving peer's Sr value (and 839 hence the Nr value it sends) will "stick" at the Ns value of the 840 first missing payload message. The "Reset Sr" (R-bit) in the 841 payload message header (see Section 5.3) provides a mechanism for 842 the sending peer to indicate to the receiver that it (the sending 843 peer) recognizes that at least one payload message has been lost 844 and that the receiving peer should now reset its Sr value beyond 845 the lost message(s). If the sending peer is performing adaptive 846 window adjustment (see Appendix B.1) then it is this recognition 847 of a lost message that is used to indicate that a window 848 adjustment at the sending peer should be performed. 850 The sender may use a timer mechanism similar to that used to 851 retransmit lost control messages to determine when transmitted 852 payload packets have been lost. When the timer expires, a payload 853 message (zero or non-zero length) with the R-bit set can be issued 854 to indicate to the receiver that it needs to reset its Sr value. 855 Upon receipt of a payload message with the R-bit set, the receiver 856 resets Sr to the value of Ns contained in the message, or, if 857 highly congested, to a value between its current value and the 858 value of Ns contained in the message. 860 Upon receipt of a payload message with R-bit set, the receiver 861 takes the following actions: First, the receiver checks for the 862 presence of the R-bit in a received payload message before 863 comparing the message's Ns value to its Sr value. If the R-bit is 864 set, the receiver will typically set its Sr value equal to that of 865 Ns contained in the message and fall through to normal receive 866 message processing in which Sr will be incremented (modulo 2**16) 867 if the message is non-zero-length and will remain the same if it 868 is zero-length. However, if the receiver is known to be heavily 869 congested, it MAY choose to not update or set its new Sr value 870 between (modulo 2**16) the current Sr value and that of Ns 871 contained in the message. This effectively spoofs the transmitter 872 into believing that the R-bit packets that have been sent are not 873 being received, ultimately causing the transmitter to backoff more 874 quickly. 876 In order to prevent an R-bit message received out of order from 877 setting Sr to an old value, the receiving peer should compare the 878 value of Ns in an R-bit message to its current value of Sr. The 879 receiving peer should reset its Sr value only if Ns is greater 880 than (modulo 2**16) its current value of Sr. 882 The sender of the R-bit can decide whether it wishes to advance 883 the receiver's Sr value to the value just past the highest (modulo 884 2**16) Nr value received (the Ns value of the just past that of 885 the first lost message) or to its current value of Ss. Resetting 886 it to that just past the first lost message enables the sender to 887 determine if other messages in the same transmit window were also 888 lost. Setting it to the current Ss value of the sender treats 889 losses of multiple messages in the same window the same as the 890 loss of a single message. An implementation may use either, or a 891 combination of both methods. If the transmitter detects that the 892 receiver is heavily congested, piggybacking the R-bit on data 893 packets should be refrained in favor of a ZLB with the R-bit set 894 for resetting the receiver's Sr. 896 It is permissible for a sending peer to set the R-bit (and hence 897 reset the transmit window) in all transmitted payload packets as 898 an indication that flow control has been disabled at the 899 transmitter. 901 Receipt of an R-bit is NOT an explicit indication to immediately 902 flush all packets which might be in queue to PPP for processing. 903 There are a number of tradeoffs as to precisely when a receiver 904 should decide to pass packets from L2TP to PPP, many dependent on 905 what protocols are being carried by PPP. In general, packets 906 should be declared lost and passed to PPP in a timely enough 907 manner so as to not cause retransmissions by reliable higher layer 908 protocols due to packets that are held in queue by l2tp. 910 L2TP does not specify the particular timeout algorithms to use for 911 congestion control. Suggested algorithms for the determination of 912 adaptive timeouts to recover from dropped data or acknowledgments 913 on the tunnel are included in Appendix A of this document. 914 Additional examples for sequencing and congestion control are 915 included in Appendix E. 917 5.0 Message Format and Protocol Extensibility 919 L2TP defines a set of control messages sent in packets over the 920 tunnel between an LNS and a given LAC. The exact technique for 921 initiating a tunnel between an LNS-LAC pair is specific to the tunnel 922 media, and specific media are described in section 8.0. 924 Once media-level connectivity is reached, L2TP message formats define 925 the protocol for an LAC and LNS to manage the tunnel and its 926 associated sessions. 928 In each case where a field is optional, if the field is not present, 929 its space does not exist in the packet. Existing fields are placed 930 back-to-back to form the packet. 932 5.1 AVP 934 To maximize extensibility while still permitting interoperability, 935 a uniform method for encoding message types and bodies is used 936 throughout L2TP. This encoding will be termed an AVP (Attribute- 937 Value Pair) in the remainder of this document. Each AVP is 938 encoded as: 940 0 1 2 3 941 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 |M|H|0|0|0|0| Overall Length | Vendor ID | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Attribute | Value... | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | [until Overall Length is reached]... | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 The first six bits are a bit mask, describing the general 951 attributes of the AVP. 953 The 0 bits indicate reserved bit fields and MUST be set to 0. An 954 AVP received with a reserved bit set to 1 MUST be treated as an 955 unrecognized AVP, unless the reserved bit is defined for an 956 extension that is known to the implementation. 958 The M bit, known as the "mandatory" bit, controls the behavior 959 required of an implementation which receives an AVP which it does 960 not recognize. If M is set on an unrecognized AVP associated with 961 call (session) management, any session associated with this AVP 962 MUST be terminated. If M is set on an unrecognized AVP associated 963 with the overall tunnel, the entire tunnel (and all sessions 964 within) MUST be terminated. If M is not set, an unrecognized AVP 965 should be ignored. 967 The H bit, known as the "hidden" bit, controls the hiding of the 968 data in the value field of an AVP. This capability can be used to 969 avoid the passing of sensitive data, such as user passwords, as 970 cleartext in an AVP. Section 5.7 describes the procedure for 971 performing AVP value hiding. 973 Overall Length encodes the number of octets (including the Overall 974 Length field itself) contained in this AVP. It is 10 bits, 975 permitting a maximum of 1024 octets of data in a single AVP. 977 Vendor ID is the IANA assigned "SMI Network Management Private 978 Enterprise Codes" [12] value, encoded in network byte order. The 979 value 0, reserved in this table, corresponds to IETF adopted 980 Attribute values, defined within this document. Any vendor 981 wishing to implement L2TP extensions can use their own Vendor ID 982 along with private Attribute values, guaranteeing that they will 983 not collide with any other vendor's extensions, nor with future 984 IETF extensions. 986 Attribute is the actual attribute, a 16-bit value with a unique 987 interpretation across all AVP's defined under a given Vendor ID. 989 Value follows immediately after the Attribute field, and runs for 990 the remaining octets indicated in the Overall Length (i.e., 991 Overall Length minus six octets of header). 993 AVP's should be kept compact; the combined AVP's within a control 994 message MUST NOT ever cause a control message's total length to 995 exceed 1500 octets in length. 997 5.2 Control Message Format 999 Each L2TP control message begins with a 16 octet header portion 1000 followed by zero or more AVP's. This header is formatted: 1002 0 1 2 3 1003 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 |T|L|0|0|F|0|0|0|0|0|0|0|0| Ver | Length | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Tunnel ID | Call ID | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Ns | Nr | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Message Type AVP... 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 ... (8 octets) | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 The 0 bits indicate reserved bit fields and MUST be set to 0. A 1017 control message received with a reserved bit set to 1 in the 1018 header MUST be treated as an unrecognized AVP, unless the bit is 1019 defined for an extension that is known to the implementation. 1021 The L and F bits must be 1, indicating that the length, Ns and Nr 1022 fields are present. 1024 The T bit MUST be 1, indicating a control message. 1026 Ver MUST be the value 2, indicating a version 1 L2TP message 1027 (values 0 and 1 are reserved to permit detection of L2F [2] and 1028 PPTP [3] packets if they arrive intermixed). 1030 Length is the overall length of the message, including header, 1031 message type AVP, plus any additional AVP's associated with a 1032 given control message type. 1034 Tunnel ID and Call ID identify the tunnel and user session within 1035 the tunnel to which a control message applies. If a control 1036 message does not apply to a single user session within the tunnel 1037 (for instance, a Stop-Control-Connection-Notification message), 1038 Call ID MUST be set to 0. If an Assigned Tunnel ID has not yet 1039 been received from the peer, Tunnel ID MUST be set to 0. Once an 1040 Assigned Tunnel ID is received, all further packets MUST be sent 1041 with Tunnel ID set to the indicated value. Note that the Assigned 1042 Tunnel ID and Call ID MAY be selected in an unpredictable manner 1043 rather than sequentially or otherwise. Doing so will help to 1044 deter hijacking of a session by a malicious user who does not have 1045 access to packet traces between the LAC and LNS. 1047 Ns is copied from the send sequence number state variable, Ss, at 1048 the time the message is transmitted. Ss is incremented after 1049 copying if the length of the control message is non-zero. Nr is 1050 copied from the receive sequence number state variable, Sr, and 1051 indicates the sequence number, Ns, + 1 of the highest (modulo 1052 2**16) in-sequence message received. See section 4.0. 1054 5.3 Payload Message Format 1056 PPP payload packets tunneled within L2TP have a smaller 1057 encapsulation than the L2TP control message header, reducing 1058 overhead of L2TP during the life of a tunneled PPP session. The 1059 LNS is expected to be able to process user data packets of at 1060 least the default MRU for PPP, not including L2TP and media 1061 encapsulation. The smallest L2TP encapsulation is 6 octets; the 1062 largest is 14 octets (plus padding octets, if present). See 1063 section 8.1 for further MTU considerations. 1065 0 1 2 3 1066 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 |T|L|R|0|F|0|S|P|0|0|0|0|0| Ver | Length (opt) | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Tunnel ID | Call ID | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | Ns (opt) | Nr (opt) | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Offset Size (opt) | Offset pad... (opt) | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 The 0 bits indicate reserved bit fields and MUST be set to 0. A 1078 packet received with a reserved bit set to 1 in the payload 1079 message header MUST be silently discarded, unless the bit is 1080 defined for an extension that is known to the implementation. 1082 The T bit MUST be 0, indicating payload. 1084 Ver MUST be 2, indicating version 1 of the L2TP protocol. 1086 If the L bit is set, the Length field is present, indicating the 1087 total length of the received packet. 1089 The R bit, "Reset Sr", is used for congestion control and 1090 indicates that the receiver SHOULD reset its receive state variable, 1091 Sr, for this session to the value contained in the Ns field of 1092 this message header. Sr is reset to the value of Ns only if Ns is 1093 greater than (modulo 2**16) the receiver's current value of Sr. 1094 Normal receive processing of the message is performed after the 1095 value of Sr is reset. Note that if the F bit is not set, then 1096 this bit MUST be 0. See section 4.2 for a detailed discussion of 1097 the use of this bit for congestion control on the data channel. 1098 See Appendix E for examples of proper R bit usage. 1100 If the F bit is set, both the Nr and Ns fields MUST be present. 1101 Ns indicates the sequence number of the packet being sent. The Ns 1102 value of a message being transmitted is copied from the current 1103 value of the send sequence number state variable, Ss. Ss is 1104 incremented by one (modulo 2**16) after copying to the Ns field 1105 only if the payload size of the message being sent is non-zero. 1106 Nr indicates the sequence number of the next in-order message 1107 sequence number to be received (if the last in-order non-zero- 1108 length data packet had Ns set to 1, the Nr sent back would be 2). 1109 The value of Nr is copied from the current receive state variable, 1110 Sr. Together, Nr and Ns can be used to handle out-of-order 1111 packets and, together with the R-bit, to provide flow control for 1112 the connection. 1114 An L2TP peer setting the F bit, and placing Nr and Ns fields in 1115 its messages, MUST have previously received or sent a Receive 1116 Window Size AVP during establishment of the session. The Nr and 1117 Ns fields are present and updated as described in section 4.0 if 1118 either side has specified an intention to do payload flow control. 1120 The Offset Size field is present if the S bit is set in the header 1121 flags. This field specifies the number of octets past the L2TP 1122 header at which the payload data is expected to start. It is 1123 recommended that data thus skipped be initialized to 0's. If 1124 Offset Size is 0, or the S bit is not set, the first octet 1125 following the last octet of L2TP header is the first octet of 1126 payload data. 1128 If the P bit is set, this packet should receive preferential 1129 treatment at the LAC in its queuing for transmission to the 1130 client. LCP echo requests used as a keepalive for the link, for 1131 instance, should generally be sent from the LNS with this bit set. 1133 Without it, a temporary interval of congestion of the transmission 1134 queues could result in the interference with keepalive messages 1135 and unnecessary loss of the link. 1137 5.4 Control Message Types 1139 Control message and AVP types defined in this specification exist 1140 under Vendor ID 0, indicating IETF defined behavior. The actual 1141 message and AVP semantics are defined in the next section. This 1142 section includes tables that summarize all currently defined 1143 message and AVP types. 1145 Each message type entry in the table below indicates: the integer 1146 value assigned to the message type; the message type abbreviation 1147 used in the AVP Summary Table of Sec. 5.5; and the full name of 1148 the message type. 1150 The integer value assigned to each message type is placed in the 1151 Value field of the Message Type AVP. This AVP MUST be the first 1152 AVP in a message. The currently defined control message types, 1153 grouped by function, are: 1155 Control Connection Management 1157 1 (SCCRQ) Start-Control-Connection-Request 1158 2 (SCCRP) Start-Control-Connection-Reply 1159 3 (SCCCN) Start-Control-Connection-Connected 1160 4 (StopCCN) Stop-Control-Connection-Notification 1161 5 (reserved) 1162 6 Hello 1164 Call Management 1166 7 (OCRQ) Outgoing-Call-Request 1167 8 (OCRP) Outgoing-Call-Reply 1168 9 (OCCN) Outgoing-Call-Connected 1169 10 (ICRQ) Incoming-Call-Request 1170 11 (ICRP) Incoming-Call-Reply 1171 12 (ICCN) Incoming-Call-Connected 1172 13 (reserved) 1173 14 (CDN) Call-Disconnect-Notify 1175 Error Reporting 1177 15 (WEN) WAN-Error-Notify 1179 PPP Session Control 1181 16 (SLI) Set-Link-Info 1183 5.5 AVP Summary 1185 The following table lists all standard L2TP attributes currently 1186 defined. The "Attr" column indicates the integer value assigned 1187 to this attribute. The "M" column indicates the setting of the 1188 "Mandatory" bit of the AVP header for each attribute. The "Len" 1189 field indicates the size of the AVP including the AVP header. A 1190 "+" in this column indicates that the length varies depending upon 1191 the length of the actual contents of the value field. 1193 The "(usage)" list for each entry indicates the message types that 1194 utilize each AVP (See command table of Sec. 5.4). An abbreviation 1195 shown in mixed or upper case letters indicates that the 1196 corresponding AVP MUST be present in this message type; All lower 1197 case indicates that the AVP may optionally appear in this message 1198 type. Some AVPs MUST be present only when a corresponding optional 1199 AVP is present, these AVPs are shown in lower case as well. 1201 A brief summary of the type and contents of the value field for 1202 each attribute is also given for each entry. Refer to the 1203 individual message type descriptions that appear in Section 6 for 1204 further details about the use of a particular AVP in a particular 1205 message type. This table is provided only as a convienent overview 1206 of AVPs, individual message AVP descriptions always enjoy priority 1207 to summary descriptions provided in this table. 1209 Attr M Len Attribute Name (usage) 1211 0 1 8 Message Type (ALL MESSAGES) 1212 16 bit integer value indicating the message type, as defined in 1213 table above. MUST be the first AVP in each message 1215 1 1 10+ Result Code (CDN, StopCCN) 1216 16 bit Integer value indicating result of corresponding request 1217 or reason for issuing a request, 16 bit integer General Error 1218 code and an optional ASCII string error message. See Result 1219 and General Error code tables below. 1221 2 1 8 Protocol Version (SCCRP, SCCRQ) 1222 8 bit L2TP Protocol and Revision numbers 1224 3 1 10 Framing Capabilities (SCCRP, SCCRQ) 1225 32 bit bitmask indicating supported framing types (e.g., 1226 synchronous and asynchronous) 1228 4 1 10 Bearer Capabilities (sccrp, sccrq) 1229 32 bit bitmask indicating supported bearer types (e.g., analog 1230 and digital) 1232 5 0 14 Tie Breaker (sccrq) 1233 8 octet value used to break control connection establishment 1234 collisions 1236 6 0 8 Firmware Revision (sccrp, sccrq) 1237 16 bit integer representing vendor's firmware revision 1239 7 0 6+ Host Name (SCCRP, SCCRQ) 1240 ASCII string name (e.g., DNS name) of issuer 1242 8 1 6+ Vendor Name (sccrp, sccrq) 1243 ASCII string describing issuing device 1245 9 1 8 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 1246 16 bit integer tunnel ID assigned by sender 1248 10 1 8 Receive Window Size (iccn, icrp, occn, ocrq, sccrp, 1249 sccrq) 1250 16 bit integer receive window size offered by sender for a 1251 given call or control session 1253 11 1 6+ Challenge (sccrp, sccrq) 1254 1 or more octet value issued by sender wishing to authenticate 1255 control session peer 1257 12 0 9+ Q.931 Cause Code (cdn) 1258 16 bit cause code, 1 octet cause message, and optional ASCII 1259 advisory message 1261 13 1 22 Challenge Response (scccn, sccrp) 1262 16 octet CHAP type response to peer's Challenge 1264 14 1 8 Assigned Call ID (CCRQ, CDN, ICRP, ICRQ, OCRP, OCRQ) 1265 16 bit integer ID assigned to a call by sender 1267 15 1 6+ Call Serial Number (ICRQ, OCRQ) 1268 1 or more octet identifier assigned to a call 1270 16 1 10 Minimum BPS (OCRQ) 1271 32 bit integer indicating lowest acceptable line speed for call 1273 17 1 10 Maximum BPS (OCRQ) 1274 32 bit integer indicating highest acceptable line speed for 1275 call 1277 18 1 10 Bearer Type (icrq, OCRQ) 1278 Indicates bearer type (i.e., analog or digital) for call 1280 19 1 10 Framing Type (ICCN, OCCN, OCRQ) 1281 Indicates framing type (i.e., synchronous or asynchronous) for 1282 call 1284 20 1 8 Packet Processing Delay (iccn, icrp, occn, ocrq) 1285 16 bit integer estimate of processing time of full window of 1286 received packets by sender 1288 21 1 6+ Dialed Number (icrq, OCRQ) 1289 ASCII string phone number called or to be called 1291 22 1 6+ Dialing Number (icrq) 1292 ASCII string phone number of caller 1294 23 1 6+ Sub-Address (icrq, ocrq) 1295 ASCII string containing additional dialing information 1297 24 1 10 (Tx) Connect Speed (ICCN, OCCN) 1298 32 bit integer representing actual (or transmit) line speed of 1299 connection 1301 25 1 10 Physical Channel ID (icrq, ocrp) 1302 16 bit vendor specific physical device identifier used for call 1304 26 0 6+ Initial Received LCP Confreq (iccn) 1305 Octet string containing initial CONFREQ received from client 1307 27 0 6+ Last Sent LCP Confreq (iccn) 1308 Octet string containing final CONFREQ sent to client 1310 28 0 6+ Last Received LCP Confreq (iccn) 1311 Octet string containing final CONFREQ received from client 1313 29 1 8 Proxy Authen Type (iccn) 1314 16 bit integer code indicating client authentication type 1315 negotiated (e.g., PAP, CHAP) 1317 30 0 6+ Proxy Authen Name (iccn) 1318 ASCII string containing name returned by client in 1319 authentication response 1321 31 0 6+ Proxy Authen Challenge (iccn) 1322 Octet string Challenge presented by LAC to client 1324 32 0 8 Proxy Authen ID (iccn) 1325 16 bit integer of which low order octet is ID presented to 1326 client with Challenge. High order octet must be 0. 1328 33 1 6+ Proxy Authen Response (iccn) 1329 Octet string CHAP response or ASCII string password depending 1330 on authentication type used 1332 34 1 32 Call Errors (WEN) 1333 A reserved 16 bit word set to 0 followed by 6 32 bit integer 1334 connection error counters 1336 35 1 16 ACCM (SLI) 1337 A reserved 16 bit word set to 0 followed by 2 32 bit bitmasks 1338 containing Send and Receive ACCM values respectively 1340 36 1 6+ Random Vector (all messages) 1341 Variable length octet string containing a random sequence of 1342 values used to accomplish the optional "hiding" of other AVP 1343 values (See "H" bit description in Sec. 5.7). 1345 37 1 6+ Private Group ID (iccn) 1346 Variable length octet value used by the LAC or LNS to indicate 1347 that this call is to be associated with a particular customer 1348 group. 1350 38 0 10 Rx Connect Speed (iccn, occn) 1351 32 bit integer representing actual receive line speed of 1352 connection. Suggests possibility of asymmetric connection. 1354 39 1 6 Sequencing Required (iccn, occn) 1355 If present, indicates to the LNS that it MUST NOT dynamically 1356 disable sequencing. 1358 5.6 Result and Error Code Summary 1360 The StopCCN and CDN message types contain a Result Code AVP which 1361 indicates the result of the previously requested operation. The 1362 Result Code can indicate that additional information pertaining to an 1363 error situation can be found in the Error Code field of the Result 1364 Code AVP. The meaning of the result code is tabulated under the 1365 specific type of message containing the result. Each 16-bit Result 1366 Code is immediately followed (in the same AVP) by a 16-bit General 1367 Error code value. 1369 General error codes pertain to types of errors which are not specific 1370 to any particular L2TP request, but rather to protocol or message 1371 format errors. If an L2TP reply indicates in its Result Code that a 1372 general error occurred, the General Error value should be examined to 1373 determine what the error was. The currently defined General Error 1374 codes and their meanings are: 1376 0 - No general error 1377 1 - No control connection exists yet for this LAC-LNS pair 1378 2 - Length is wrong 1379 3 - One of the field values was out of range or reserved field was 1380 non-zero 1381 4 - Insufficient resources to handle this operation now 1382 5 - The Call ID is invalid in this context 1383 6 - A generic vendor-specific error occurred in the LAC 1384 7 - Try another. If LAC is aware of other possible LNS 1385 destinations, it should try one of them. This can be used to 1386 guide an LAC based on LNS policy, for instance, the existence 1387 of multilink PPP bundles. 1389 If the length of the Result Code AVP specifies that the Value field 1390 is more than four octets in length, the remaining octets after the 1391 General Error Code field are an arbitrary string providing further 1392 (possibly human readable) text associated with the condition. 1394 Generally, when a General Error Code of 6 is used, additional 1395 information about the error will be included in the Optional Message 1396 field that follows the Error Code field in the Result Code AVP. 1398 5.7 Hiding of AVP values 1400 The H ("Hidden") bit in the header of each AVP in a control message 1401 provides a mechanism to indicate to the receiving peer whether the 1402 contents of the AVP are hidden or present in cleartext. This feature 1403 can be used to hide sensitive control message data such as user 1404 passwords or user ID's. The H bit MUST NOT be set in the Random 1405 Vector AVP or Message Type AVP. 1407 The H bit MUST only be set if a shared secret exists between the 1408 peers on either end of the tunnel. If the H bit is set in any AVP(s) 1409 in a given command message, a Random Vector AVP must also be present 1410 in the message and MUST precede the first AVP having an H-bit of 1. 1412 The length of the AVP value to be hidden is first encoded in the form 1413 of a Hidden AVP Subformat as follows: 1415 0 1 2 3 1416 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | Length of Original Value | Original Value ... 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 ... | Padding ... 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 Length 1424 This is length of the Original Value to be obscured in octets. 1426 Original Value 1427 Value of hidden AVP that is to be obscured. 1429 Padding 1430 Random additional octets used to obscure length of the Original 1431 Value. 1433 The resulting subformat MAY be padded to a multiple of 16 octets in 1434 length. For example, if the Original Value to be obscured is a string 1435 containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 1436 octects of padding would be applied. Padding does NOT alter the value 1437 placed in the Length of the Original Value, only the length of the 1438 AVP itself. 1440 Next, An MD5 hash is performed on the concatenation of: 1442 - the 2 octet Attribute number of the AVP 1443 - the shared authentication secret 1444 - an arbitrary length random vector 1446 The value of the random vector used in this hash is passed in the 1447 value field of a Random Vector AVP. This Random Vector AVP must be 1448 placed in the message by the sender before any hidden AVPs. The same 1449 random vector may be used for more than one hidden AVP in the same 1450 message. If a different random vector is used for the hiding of 1451 subsequent AVPs then a new Random Vector AVP must be placed in the 1452 command message before the first AVP to which it applies. 1454 The MD5 hash value is then XORed with the first 16 octet or less 1455 segment of the Hidden AVP Subformat and placed in the Value field of 1456 the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, 1457 the Subformat is transformed as if the Value field had been padded to 1458 16 octets before the XOR, but only the actual octets present in the 1459 Subformat are modified, and the length of the AVP is not altered. 1461 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1462 is calculated over a stream of octets consisting of the shared secret 1463 followed by the result of the first XOR. That hash is XORed with the 1464 second 16 octet or less segment of the Subformat and placed in the 1465 corresponding octets of the Value field of the Hidden AVP. 1467 If necessary, this operation is repeated, with each XOR result being 1468 used along with the shared secret to generate the next hash to XOR 1469 the next segment of the value with. This technique results in the 1470 content of the AVP being obscured, although the length of the AVP is 1471 still known. 1473 On receipt, the random vector is taken from the last Random Vector 1474 AVP encountered in the message prior to the AVP to be unhidden. The 1475 above process is then reversed to yield the original value. For more 1476 details on this hiding method, consult RFC2058 [8]. 1478 The Random Vector AVP has the following format: 1480 Random Vector 1482 0 1 2 3 1483 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 |1|0|0|0| 6 + String length | 0 | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | 36 | Random Octet String ... 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 The Random Vector AVP may be used in any message type. The Attribute 1491 value is 36 and it is marked mandatory. It is used to enable the 1492 hiding of the values of arbitrary AVPs. It MUST precede any AVP 1493 containing an AVP with the H-bit set but it MUST NOT itself have the 1494 H-bit set. More than one Random Vector AVP may appear in a message, 1495 in which case the one most closely preceding an AVP with the H-bit 1496 set pertains to that AVP. The Random Octet String is the random 1497 vector value to use in computing the MD5 hash to retrieve the 1498 original value of a hidden AVP. This string can be of arbitrary 1499 length, although a random vector of at least 16 octets is 1500 recommended. The only AVP that the Random Vector AVP MUST NOT precede 1501 is the Message Type AVP (which is always the first AVP in a message). 1503 6.0 Control Connection Protocol Specification 1505 Control Connection messages are used to establish and clear user 1506 sessions. The first set of Control Connection messages are used to 1507 maintain the control connection itself. The control connection is 1508 initiated by an LAC or LNS after establishing the underlying tunnel- 1509 over-media connection. 1511 6.0.1 Control Connection Collision 1513 For the case where an LAC and LNS both initiate tunnels to each 1514 other concurrently, and where the LAC and LNS both determine that 1515 a single tunnel suffices (generally because of media 1516 characteristic considerations, for instance, whether individual 1517 tunnels are needed to gain QOS guarantees for each tunnel), a "tie 1518 breaker" may be undertaken. The details of breaking a tie are 1519 documented with the tunnel establishment messages (Sec. 6.1). 1521 6.0.2 Reliable Delivery of Control Messages 1523 Since L2TP may run across media where packets may be lost, an L2TP 1524 peer sending a control message will retransmit the control message 1525 after deciding that its remote peer has not received it. The 1526 reliable transport mechanism built into L2TP is essentially a 1527 lower layer transport service; the Nr and Ns fields of the control 1528 message header belong to this transport layer. The higher layer 1529 functions of L2TP are not concerned with retransmission or 1530 ordering of control messages. 1532 Each tunnel maintains a queue of control messages to be 1533 transmitted to the peer. The message at the front of the queue is 1534 sent with a given Ns value, and is held until a control message 1535 arrives from the peer in which the Nr field indicates receipt of 1536 this message. After a fixed (recommended default is 1 second) or 1537 adaptive (see Appendix D) timeout interval expires without 1538 receiving such an acknowledgment, the control message packet is 1539 retransmitted. The retransmitted packet contains the same Ns 1540 value, but the Nr value MUST be updated with the current value of 1541 Sr to reflect any packets received in the interim. 1543 If no peer response is detected after several retransmissions (a 1544 recommended default is 5, but may be altered due to media 1545 considerations), the tunnel and all sessions within MUST be 1546 cleared. 1548 When a tunnel is being shut down for reasons other than loss of 1549 connectivity, the state and reliable delivery mechanisms MUST be 1550 maintained and operated for the full retransmission interval after 1551 the final message exchange has occurred. This permits reliable 1552 delivery of closing messages in environments where these closing 1553 messages might be dropped. 1555 A peer MUST NOT withhold acknowledgment of packets as a technique 1556 for flow controlling control messages. An L2TP implementation is 1557 expected to be able to keep up with incoming control messages, 1558 possibly responding to some with errors reflecting an inability to 1559 honor the requested action. 1561 A sliding window mechanism is used, by default, for control 1562 message transmission. The default is to permit four control 1563 messages to be outstanding on a given tunnel. If a peer specifies 1564 a Receive Window Size AVP in the Start-Control-Connection-Request 1565 and -Reply packets, up to the indicated number of control messages 1566 may be sent and held outstanding. An implementation may only 1567 support a receive window of 1, but MUST accept at least a window 1568 of 4 from its peer. Unlike payload sessions, a value of 0 for the 1569 Receive Window Size AVP is invalid for a control session. 1571 The transport layer at a receiving peer is responsible for making 1572 sure that control messages are delivered in order to the higher 1573 layer and that duplicate messages are not delivered to the higher 1574 layer. Messages arriving out of order may be queued for in-order 1575 delivery when the missing messages are received or they may be 1576 discarded, requiring a retransmission. 1578 6.0.3 Control Message Format 1580 The following Control Connection messages are all sent as packets 1581 on the established tunnel connection between a given LNS-LAC pair. 1582 All data is sent in network order (high order octets first). Any 1583 "reserved" or "empty" fields MUST be sent as 0 values to allow for 1584 protocol extensibility. 1586 Each control message has a header, specified in section 5.2, 1587 including an AVP indicating the type of control message, followed 1588 by zero or more AVP's appropriate for the given type of control 1589 message. Each control message is described first at a block 1590 level, and then with details of each AVP. 1592 6.1 Start-Control-Connection-Request (SCCRQ) 1594 The Start-Control-Connection-Request is an L2TP control message used 1595 to initialize the tunnel between an LNS and an LAC. The tunnel must 1596 be initialized through the exchange of these control messages before 1597 any other L2TP messages can be issued. The establishment of the 1598 control connection is started by the initiator of the underlying 1599 tunnel. 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | L2TP Control Message Header | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Start-Control-Connection-Request | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | Protocol Version | 1607 | Framing Capabilities | 1608 | Bearer Capabilities | 1609 | Tie Breaker | 1610 | Firmware Revision | 1611 | Host Name | 1612 | Vendor Name | 1613 | Assigned Tunnel ID | 1614 | Receive Window Size | 1615 | Challenge | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+ 1617 Start-Control-Connection-Request 1619 0 1 2 3 1620 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 |1|0|0|0|0|0| 8 | 0 | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | 0 | 1 | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 The Message Type AVP contains a Value of 1, indicating Start- 1628 Control-Connection-Request. The Flags indicate a mandatory 1629 option. Details associated with this tunneled session follow in 1630 additional AVP's within the packet. 1632 Protocol Version 1634 0 1 2 3 1635 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 |1|0|0|0|0|0| 8 | 0 | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | 2 | 0x01 | 0x00 | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 The Protocol Version AVP within a Start-Control-Connection-Request 1643 packet indicates the L2TP protocol version available. The 1644 Attribute value is 2, indicating Protocol Version, and is marked 1645 mandatory. This AVP MUST be present. The Value field is a 16-bit 1646 hexadecimal value 0x100, indicating L2TP protocol version 1, 1647 revision 0. 1649 Framing Capabilities 1651 0 1 2 3 1652 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 |1|0|0|0|0|0| 10 | 0 | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | 3 | 0x00 | 0x00 | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | 0x00 |0|0|0|0|0|0|A|S| 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 The Framing Capabilities AVP within a Start-Control-Connection- 1662 Request indicates the type of framing that the sender of this 1663 message can provide. The Attribute value is 3, indicating Framing 1664 Capabilities, and is marked mandatory. This AVP MUST be present. 1665 The Value field is a 32-bit quantity, with two bits defined. If 1666 bit A is set, asynchronous framing is supported. If bit S is set, 1667 synchronous framing is supported. 1669 This AVP provides the peer with an indication of the types of 1670 framing that will be accepted or initiated by the sender. A peer 1671 should not initiate an incoming or outgoing call with a Framing 1672 Type AVP specifying a value not advertised in the Framing 1673 Capabilities AVP it received during control connection 1674 establishment. Attempts to do so will result in the call being 1675 rejected. 1677 Bearer Capabilities 1679 0 1 2 3 1680 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 |1|0|0|0|0|0| 10 | 0 | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 | 4 | 0x00 | 0x00 | 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 | 0x00 |0|0|0|0|0|0|A|D| 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 The Bearer Capabilities AVP within a Start-Control-Connection- 1690 Request indicates the bearer capabilities that the sender of this 1691 message can provide for outgoing calls. The Attribute value is 4, 1692 indicating Bearer Capabilities, and is marked mandatory. This AVP 1693 MUST be present if the sender can place outgoing calls when 1694 requested. The Value field is a 32-bit quantity with two bits 1695 defined. If bit A is set, analog access is supported. If bit D 1696 is set, digital access is supported. 1698 This AVP provides the peer with an indication of the bearer device 1699 types supported by the hardware interfaces of the sender for 1700 outgoing calls. An LNS should not initiate an outgoing call 1701 specifying a value in the Bearer Type AVP for a device type not 1702 advertised in the Bearer Capabilities AVP it received from the LAC 1703 during control connection establishment. Attempts to do so will 1704 result in the call being rejected. 1706 Note that an LNS that cannot act as an LAC as well will not 1707 support hardware devices for handling incoming and outgoing calls 1708 and should therefore set the A and D bits in the Value field of 1709 this AVP to 0, or should not send the AVP at all. An LNS that can 1710 also act as an LAC and place outgoing calls should set the 1711 appropriate bits in the Value field of this AVP. Presence of this 1712 message is not a guarantee that a given outgoing call will be 1713 placed by the sender if requested, just that the physical 1714 capability exists. 1716 Tie Breaker 1718 0 1 2 3 1719 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 |0|0|0|0|0|0| 14 | 0 | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | 5 | Tie Break Value... | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | Value... | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | ...(64 bits) | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 The Tie Breaker AVP within a Start-Control-Connection-Request 1731 contains a 64-bit Value used to break ties in tunnel establishment 1732 between an LAC-LNS pair. The Attribute value is 5, indicating Tie 1733 Breaker, and is marked optional. This AVP itself is optional. 1734 The 8 octet Value is used as a 64-bit tie breaker value. 1736 If present, it indicates the sender wishes a single tunnel to 1737 exist between the given LAC-LNS pair, and this value will be used 1738 to choose a single tunnel where both LAC and LNS initiate a tunnel 1739 concurrently. The recipient of a Start-Control-Connection-Request 1740 must check to see if a Start-Control-Connection-Request has been 1741 sent to the peer, and if so, must compare its Tie Breaker value 1742 with the received one. The lower value "wins", and the "loser" 1743 MUST silently discard its tunnel. In the case where a tie breaker 1744 is present on both sides, and the value is equal, both sides MUST 1745 discard their tunnels. 1747 If a tie breaker is received, and the outstanding Start-Control- 1748 Connection-Request had no tie breaker value, the initiator which 1749 included the Tie Breaker AVP "wins". If neither side issues a Tie 1750 breaker, then two separate tunnels are opened. 1752 It is recommended that the Value be set to the MAC address of a 1753 LAN interface on the sender. If no MAC address is available, a 1754 64-bit random number should be used instead. 1756 Firmware Revision 1758 0 1 2 3 1759 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 |0|0|0|0|0|0| 8 | 0 | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 | 6 | Firmware Revision | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 The Firmware Revision AVP within a Start-Control-Connection- 1767 Request indicates the firmware revision of the issuing device. 1768 The Attribute value is 6, indicating Firmware Revision, and is 1769 marked optional. This AVP itself is optional. The Value field is 1770 a 16-bit integer encoded in a vendor specific format. For devices 1771 which do not have a firmware revision (general purpose computers 1772 running L2TP software modules, for instance), the revision of the 1773 L2TP software module may be reported instead. 1775 Host Name 1777 0 1 2 3 1778 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 |1|0|0|0|0|0| 6 + Host name len | 0 | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | 7 | Host name... 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 The Host Name AVP within a Start-Control-Connection-Request 1786 indicates the name of the issuing LAC or LNS. The Attribute value 1787 is 7, indicating Host Name, and is marked mandatory. This AVP 1788 itself MUST be present. This name should be as broadly unique as 1789 possible; for hosts participating in DNS [4], a hostname with 1790 fully qualified domain would be appropriate. 1792 Vendor Name 1794 0 1 2 3 1795 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 3|0|0|0|0|0|0| 6+Vendor Name len| 0 | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | 8 | Vendor name... 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 The Vendor Name AVP within a Start-Control-Connection-Request 1803 contains a vendor specific string describing the type of LAC or 1804 LNS being used. The Attribute value is 8, indicating Vendor Name, 1805 and is marked optional. This AVP itself is optional. The Value 1806 is the indicated number of octets representing the vendor string. 1808 Assigned Tunnel ID 1810 0 1 2 3 1811 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 |1|0|0|0|0|0| 8 | 0 | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | 9 | Tunnel ID | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1818 The Assigned Tunnel ID AVP within a Start-Control-Connection- 1819 Request specifies the Tunnel ID which the receiving peer MUST use 1820 in the Tunnel ID field of all subsequent packets. The Attribute 1821 value is 9, indicating Assigned Tunnel ID, and is marked 1822 mandatory. This AVP MUST be present. Before the Assigned Tunnel 1823 ID AVP is received, packets MUST be sent with a Tunnel ID value of 1824 0. The Value is a 16-bit non-zero Tunnel ID value. 1826 Receive Window Size 1828 0 1 2 3 1829 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 |1|0|0|0|0|0| 8 | 0 | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | 10 | Size | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 The Receive Window Size AVP within a Start-Control-Connection- 1837 Request specifies the receive window size being offered to the 1838 remote peer. The Attribute value is 10, indicating Receive Window 1839 Size, and is mandatory. This AVP itself is optional. Value is a 1840 16-bit word indicating the offered window size. If absent, the 1841 peer must assume a value of 4 for its transmit window. The remote 1842 peer may send the specified number of control messages before it 1843 must wait for an acknowledgment. 1845 Challenge 1847 0 1 2 3 1848 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 |1|0|0|0|0|0| 6 + Challenge len | 0 | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | 11 | Challenge... 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 The Challenge AVP within a Start-Control-Connection-Request 1856 indicates that the issuing peer wishes to authenticate the tunnel 1857 endpoints using a CHAP-style authentication mechanism. The 1858 Attribute value is 11, indicating Challenge, and is marked 1859 mandatory. This AVP is optional. The Value is one or more octets 1860 of challenge value. 1862 6.2 Start-Control-Connection-Reply (SCCRP) 1864 The Start-Control-Connection-Reply is an L2TP control message sent in 1865 reply to a received Start-Control-Connection-Request message. Sending 1866 this message indicates that the request was successful. 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | L2TP Control Message Header | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | Start-Control-Connection-Reply | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | Protocol Version | 1874 | Framing Capabilities | 1875 | Bearer Capabilities | 1876 | Firmware Revision | 1877 | Host Name | 1878 | Vendor Name | 1879 | Assigned Tunnel ID | 1880 | Receive Window Size | 1881 | Challenge | 1882 | Challenge Response | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+ 1885 Start-Control-Connection-Reply 1887 0 1 2 3 1888 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 |1|0|0|0|0|0| 8 | 0 | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | 0 | 2 | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 The Message Type AVP contains a Value of 2, indicating Start- 1896 Control-Connection-Reply. The Flags indicate a mandatory option. 1898 Protocol Version 1900 0 1 2 3 1901 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 |1|0|0|0|0|0| 8 | 0 | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | 2 | 0x01 | 0x00 | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 The Protocol Version AVP within a Start-Control-Connection-Reply 1909 packet indicates the L2TP protocol version available. The 1910 Attribute value is 2, indicating Protocol Version, and the Value 1911 field is a 16-bit hexadecimal value 0x100, indicating L2TP 1912 protocol version 1, revision 0. This AVP MUST be present. 1914 Framing Capabilities 1916 0 1 2 3 1917 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 |1|0|0|0|0|0| 10 | 0 | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | 3 | 0x00 | 0x00 | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | 0x00 |0|0|0|0|0|0|A|S| 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 The Framing Capabilities AVP within a Start-Control-Connection- 1927 Reply indicates the type of framing that the sender of this 1928 message can provide. The Attribute is 3, it is a mandatory AVP, 1929 the Value field is a 32-bit quantity, with two bits defined. If 1930 bit A is set, asynchronous framing is supported. If bit S is set, 1931 synchronous framing is supported. This AVP MUST be present. 1933 More details on the use of this AVP can be found in Sec. 6.1. 1935 Bearer Capabilities 1937 0 1 2 3 1938 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 |1|0|0|0|0|0| 10 | 0 | 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 | 4 | 0x00 | 0x00 | 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | 0x00 |0|0|0|0|0|0|A|D| 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 The Bearer Capabilities AVP within a Start-Control-Connection- 1948 Reply indicates the bearer capabilities that the sender of this 1949 message can provide for outgoing calls. The Attribute is 4, it is 1950 a mandatory AVP, the Value field is a 32-bit quantity with two 1951 bits defined. If bit A is set, analog access is supported. If 1952 bit D is set, digital access is supported. This AVP MUST be 1953 present if outgoing calls can be placed by the sender of this 1954 message. 1956 More details on the use of this AVP can be found in Sec. 6.1. 1958 Firmware Revision 1960 0 1 2 3 1961 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 |0|0|0|0|0|0| 8 | 0 | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | 6 | Firmware Revision | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 The Firmware Revision AVP within a Start-Control-Connection-Reply 1968 indicates the firmware revision of the issuing device. The 1969 Attribute is 6, it is not a mandatory AVP, the Value field is a 1970 16-bit integer encoded in a vendor specific format. For devices 1971 which do not have a firmware revision (general purpose computers 1972 running L2TP software modules, for instance), the revision of the 1973 L2TP software module may be reported instead. This AVP is 1974 optional. 1976 Host Name 1978 0 1 2 3 1979 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 |1|0|0|0|0|0| 6 + Host Name len | 0 | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | 7 | Host Name... 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 The Host Name AVP within a Start-Control-Connection-Reply 1987 indicates the name of the issuing LAC or LNS. See the notes in 1988 section 6.1 concerning Host Name contents. It is encoded as the 1989 Attribute 7, mandatory, with the indicated number of octets 1990 representing the host name string. This AVP MUST be present. 1992 Vendor Name 1994 0 1 2 3 1995 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 |0|0|0|0|0|0| 6+Vendor Name len | 0 | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | 8 |Vendor Name... 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 The Vendor Name AVP within a Start-Control-Connection-Reply 2003 contains a vendor specific string describing the type of LAC or 2004 LNS being used. It is encoded as the Attribute 8, not mandatory, 2005 with the indicated number of octets representing the vendor 2006 string. This AVP is optional. 2008 Assigned Tunnel ID 2010 0 1 2 3 2011 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 |1|0|0|0|0|0| 8 | 0 | 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 | 9 | Tunnel ID | 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply 2019 specifies the Tunnel ID which the receiving peer MUST use in all 2020 subsequent packets. It is encoded as the Attribute 9, mandatory, 2021 with a 16-bit non-zero Tunnel ID value. This AVP MUST be present. 2023 Receive Window Size 2025 0 1 2 3 2026 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 |1|0|0|0|0|0| 8 | 0 | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | 10 | size | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 The Receive Window Size AVP within a Start-Control-Connection- 2034 Reply specifies the receive window size being offered to the 2035 remote peer. The Attribute value is 10, indicating Receive Window 2036 Size, and is mandatory. This AVP itself is optional. Value is a 2037 16-bit word indicating the offered window size. If absent, the 2038 peer must assume a value of 4 for its transmit window. The remote 2039 peer may send the specified number of control messages before it 2040 must wait for an acknowledgment. 2042 Challenge 2044 0 1 2 3 2045 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 |1|0|0|0|0|0| 6 + Challenge len | 0 | 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 | 11 | Challenge... 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 The Challenge AVP within a Start-Control-Connection-Reply 2053 indicates that the peer wishes to authenticate the tunnel 2054 initiator using a CHAP-style authentication mechanism. It is 2055 encoded as the Attribute 11, mandatory, with at least one octet of 2056 challenge value embedded. If this AVP is not present, it 2057 indicates to the receiving peer that the sender does not wish to 2058 authenticate that peer. 2060 Challenge Response 2062 0 1 2 3 2063 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 |1|0|0|0|0|0| 22 | 0 | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | 13 | Response... | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | Response... (128 bits) | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 The Response AVP within a Start-Control-Connection-Reply packet 2073 provides a response to a challenge received. The Attribute value 2074 is 13, indicating Response, and the Value field is a 128-bit value 2075 reflecting the CHAP-style response to the challenge. This AVP 2076 marked mandatory, and MUST be present if a challenge was received 2077 and this Start-Control-Connection-Reply indicates success. For 2078 purposes of the ID value in the CHAP response calculation, the 2079 value 2 (corresponding to the Value field of the Start-Control- 2080 Connection-Reply AVP) MUST be used. 2082 6.3 Start-Control-Connection-Connected (SCCCN) 2084 The Start-Control-Connection-Connected message is an L2TP control 2085 message sent in reply to a received Start-Control-Connection-Reply 2086 message. This message provides closure to the tunnel establishment 2087 process, and includes a challenge response if the peer sent a 2088 challenge in the Start-Control-Connection-Reply message. 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 | L2TP Control Message Header | 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2093 | Start-Control-Connection-Connected | 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | Challenge Response | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+ 2098 Start-Control-Connection-Connected 2100 0 1 2 3 2101 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 |1|0|0|0|0|0| 8 | 0 | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | 0 | 3 | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 The Message Type AVP contains a Value of 3, indicating Start- 2109 Control-Connection-Connected. The Flags indicate a mandatory 2110 option. 2112 Challenge Response 2114 0 1 2 3 2115 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 |1|0|0|0|0|0| 22 | 0 | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | 13 | Response... | 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 | Response... (128 bits) | 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 The Challenge Response AVP within a Start-Control-Connection- 2125 Connected packet provides a response to a challenge received. The 2126 Attribute value is 13, indicating Response, and the Value field is 2127 a 128-bit value reflecting the CHAP-style response to the 2128 challenge. This AVP is marked mandatory, and MUST be present if a 2129 challenge was received, otherwise MUST be omitted. For purposes 2130 of the ID value in the CHAP response calculation, the value 3 2131 (corresponding to the Value field of the Start-Control- 2132 Connection-Connected AVP) MUST be used. 2134 6.4 Stop-Control-Connection-Notification (StopCCN) 2136 The Stop-Control-Connection-Notification is an L2TP control message 2137 sent by one peer of an LAC-LNS control connection to inform the other 2138 peer that the control connection should be closed. In addition to 2139 closing the control connection, all active user calls are implicitly 2140 cleared. The reason for issuing this request is indicated in the 2141 Result Code AVP. 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 | L2TP Control Message Header | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | Stop-Control-Connection-Notification| 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | Assigned Tunnel ID | 2149 | Result Code | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+ 2152 Stop-Control-Connection-Notification AVP 2154 0 1 2 3 2155 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 |1|0|0|0|0|0| 8 | 0 | 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 | 0 | 4 | 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 The Message Type AVP contains a Value of 4, indicating Stop- 2163 Control-Connection-Notification. The Flags indicate a mandatory 2164 option. 2166 Assigned Tunnel ID 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|0|0| 8 | 0 | 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | 9 | Tunnel ID | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 The Attribute value is 9, indicating Assigned Tunnel ID, and is 2177 marked mandatory. This AVP MUST be present. The Value MUST be 2178 the same Assigned Tunnel ID first sent to the receiving peer. 2179 This AVP permits the peer to identify the appropriate tunnel even 2180 if Stop-Control-Connection-Notification must be sent before an 2181 Assigned Tunnel ID is received. 2183 Result Code 2185 0 1 2 3 2186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 |1|0|0|0|0|0| 10 + Message len | 0 | 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 | 1 | Result Code | 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 | Error Code | Optional Message ... 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 The Result Code AVP within a Stop-Control-Connection-Notification 2196 packet indicates the reason for terminating the control channel. 2197 It is encoded as Attribute 1, indicating a Result Code AVP. This 2198 AVP is mandatory and MUST be present. The Result Code is a 16-bit 2199 word. The 16-bit word following the Result Code field contains 2200 the Error Code value, which for a Stop-Control-Connection- 2201 Notification is always 0. An optional message can follow the 2202 Error Code field. Its presence and length is indicated by the 2203 value of the AVP length field. Defined Result Code values are: 2205 1 - General request to clear control connection 2206 2 - General error--Error Code indicates the problem 2207 3 - Control channel already exists 2208 4 - Requester is not authorized to establish a control channel 2209 5 - The protocol version of the requester is not supported 2210 Error Code indicates highest version supported 2211 6 - Requester is being shut down 2212 7 - Finite State Machine error 2214 6.5 Hello 2216 The Hello message is an L2TP control message sent by either peer of a 2217 LAC-LNS control connection. This control message is used as a 2218 "keepalive" for the tunnel. 2220 The sending of Hello messages and the policy for sending them are 2221 left up to the implementation. A peer MUST NOT "expect" Hello 2222 messages at any time or interval. When a Hello is received, it MUST 2223 be silently discarded (after updating any effects of the indicated 2224 Nr/Ns values). 2226 Keepalives for the tunnel MAY be implemented by sending a Hello once 2227 every 60 seconds if 60 seconds have passed without receiving any 2228 message (payload or control, including zero-length messages) from the 2229 peer. 2231 Because a Hello is a control message, and control messages are 2232 reliably sent by the lower level transport, this keepalive function 2233 operates by causing the transport level to reliably deliver a 2234 message. If a media interruption has occurred, the reliable 2235 transport will be unable to deliver the Hello across, and will clean 2236 up the tunnel. 2238 Hello messages are global to the tunnel; the Call ID field of these 2239 control messages MUST be 0. 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | L2TP Control Message Header | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | Hello | 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 Hello 2249 0 1 2 3 2250 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 |1|0|0|0|0|0| 8 | 0 | 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 | 0 | 6 | 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 The Message Type AVP contains a Value of 6, indicating Hello The 2258 Flags indicate a mandatory option. 2260 6.6 Outgoing-Call-Request (OCRQ) 2262 The Outgoing-Call-Request is an L2TP control message sent by the LNS 2263 to the LAC to indicate that an outbound call from the LNS is to be 2264 established. This request provides the LAC with information required 2265 to make the call. It also provides information to the LAC that is 2266 used to regulate the transmission of data to the LNS for this session 2267 once it is established. 2269 This message is the first in the "three-way handshake" used by L2TP 2270 for establishing outgoing calls. The first message requests the 2271 call; the second indicates that the call was successfully initiated. 2272 The third and final message indicates that the call was established. 2274 An LNS MUST have received a Bearer Capabilities AVP during tunnel 2275 establishment from an LAC in order to request an outgoing call to 2276 that LAC. 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | L2TP Control Message Header | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | Outgoing-Call-Request | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | Assigned Call ID | 2284 | Call Serial Number | 2285 | Minimum BPS | 2286 | Maximum BPS | 2287 | Bearer Type | 2288 | Framing Type | 2289 | Receive Window Size | 2290 | Packet Processing Delay | 2291 | Dialed Number | 2292 | Sub-Address | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 Outgoing-Call-Request 2297 0 1 2 3 2298 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 |1|0|0|0|0|0| 8 | 0 | 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2302 | 0 | 7 | 2303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 The Message Type AVP contains a Value of 7, indicating Outgoing- 2306 Call-Request. The Outgoing-Call-Request encodes a request to an 2307 LAC to establish an outgoing call. The flags indicate a mandatory 2308 option. 2310 Assigned Call ID 2312 0 1 2 3 2313 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 |1|0|0|0|0|0| 8 | 0 | 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 | 14 | Call ID | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 The Assigned Call ID AVP encodes the ID being assigned to this 2321 call by the LNS. The Attribute value is 14, indicating Assigned 2322 Call ID, and is marked mandatory. This AVP MUST be present. The 2323 LAC places this value in the Call ID header field of all command 2324 and payload packets that it subsequently transmits over the tunnel 2325 that belong to this call. The Call ID value is an identifier 2326 assigned by the LNS to this session. It is used to multiplex and 2327 demultiplex data sent over that tunnel between the LNS and LAC. 2329 Call Serial Number 2331 0 1 2 3 2332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 |1|0|0|0|0|0| 10 | 0 | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | 15 | CSN (H) | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | CSN (L) | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 Call Serial Number AVP encodes an identifier assigned by the LNS to 2342 this call. Attribute is 15, indicating Call Serial Number, and is 2343 marked mandatory. This AVP MUST be present. The Call Serial Number 2344 is intended to be an easy reference for administrators on both ends of 2345 a tunnel to use when investigating call failure problems. Call Serial 2346 Numbers should be set to progressively increasing values, which are 2347 likely to be unique for a significant period of time across all 2348 interconnected LNS and LACs. Other identification information may 2349 also be prepended. 2351 Minimum BPS 2353 0 1 2 3 2354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 |1|0|0|0|0|0| 10 | 0 | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | 16 | BPS (H) | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | BPS (L) | 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 Minimum BPS AVP encodes the lowest acceptable line speed for this 2364 call. Attribute is 16, Minimum BPS, and is marked mandatory. 2365 This AVP MUST be present. The BPS value indicates the speed in 2366 bits/second. 2368 Maximum BPS 2370 0 1 2 3 2371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 |1|0|0|0|0|0| 10 | 0 | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 | 17 | BPS (H) | 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 | BPS (L) | 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 Maximum BPS AVP encodes the highest acceptable line speed for this 2381 call. Attribute is 17, indicating Maximum BPS, and is marked 2382 mandatory. This AVP MUST be present. The BPS value indicates the 2383 speed in bits/second. 2385 Bearer Type 2387 0 1 2 3 2388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 |1|0|0|0|0|0| 10 | 0 | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 Bearer Type AVP encodes the bearer type for the requested call. 2398 The Attribute is 18, indicating Bearer Type, and is marked 2399 mandatory. This AVP MUST be present. The Value is a 32-bit 2400 quantity indicating the bearer capability required for this 2401 outgoing call. If set, bit A indicates that the call should be on 2402 an analog channel. If set, bit D indicates that the call should 2403 be on a digital channel. Both may be set, indicating that the 2404 call can be of either type. 2406 A particular bit in the Value field of this AVP MAY only be set by 2407 the LNS if it was set in the Bearer Capabilities AVP received from 2408 the LAC during control session establishment. 2410 Framing Type 2412 0 1 2 3 2413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 |1|0|0|0|0|0| 10 | 0 | 2416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2417 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 Framing Type AVP encodes the framing type for the requested call. 2423 Attribute is 19, indicating Framing Type, and is marked mandatory. 2424 This AVP MUST be present. The 32-bit field indicates the type of 2425 PPP framing to be used for the outgoing call. If set, Bit A 2426 indicates that asynchronous framing should be used. If set, Bit S 2427 indicates that synchronous framing should be used. Both may be 2428 set, indicating that either type of framing may be used for the 2429 call. 2431 A particular bit in the Value field of this AVP MAY only be set by 2432 the LNS if it was set in the Framing Capabilities AVP received 2433 from the LAC during control session establishment. 2435 Receive Window Size 2437 0 1 2 3 2438 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 |1|0|0|0|0|0| 8 | 0 | 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 | 10 | Size | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 Receive Window Size AVP encodes the window size being advertised 2446 by the LNS for this call. Attribute is 10, indicating Receive 2447 Window Size, and is marked mandatory. This AVP is optional. The 2448 Size value indicates the number of received data packets the LNS 2449 will buffer for this call, which is also the maximum number of 2450 data packets the LAC should send before waiting for an 2451 acknowledgment. The absence of this AVP indicates that Sequence 2452 and Acknowledgment Numbers are not to be used in the payload 2453 session for this call. 2455 Packet Processing Delay 2457 0 1 2 3 2458 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2460 |1|0|0|0|0|0| 8 | 0 | 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 | 20 | Delay | 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2465 The Packet Processing Delay AVP encodes the delay that is expected 2466 at the LNS in processing a window full of packets sent by the LAC. 2467 Attribute is 20, indicating Packet Processing Delay, and is marked 2468 mandatory. This AVP is optional. The Delay value is specified in 2469 units of 1/10 seconds. Refer to Appendix A for a description of 2470 how this value is determined and used. 2472 Dialed Number 2474 0 1 2 3 2475 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 |1|0|0|0|0|0| 6+Phone Number len| 0 | 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 | 21 | Phone Number.. 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 Phone Number AVP encodes the phone number to be called. Attribute 2483 is 21, indicating Phone Number, and is marked mandatory. This AVP 2484 MUST be present. The Phone Number value is an ASCII string. 2486 Sub-Address 2488 0 1 2 3 2489 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 |1|0|0|0|0|0| 6+Sub-Address len | 0 | 2492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2493 | 23 |Sub-Address ... 2494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 Sub-Address AVP encodes additional dialing information. Attribute 2497 is 23, indicating Sub-Address, and is marked mandatory. This AVP 2498 is optional. The Sub-Address value is an ASCII string. 2500 6.7 Outgoing-Call-Reply (OCRP) 2502 The Outgoing-Call-Reply is an L2TP control message sent by the LAC to 2503 the LNS in response to a received Outgoing-Call-Request message. The 2504 reply indicates that the LAC is able to attempt the outbound call and 2505 also returns certain parameters regarding the call attempt. 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 | L2TP Control Message Header | 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | Outgoing-Call-Reply | 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 | Assigned Call ID | 2513 | Physical Channel Id | 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 Outgoing-Call-Reply 2518 0 1 2 3 2519 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 |1|0|0|0|0|0| 8 | 0 | 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 | 0 | 8 | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 The Message Type AVP contains a Value of 8, indicating Outgoing- 2527 Call-Reply. The Outgoing-Call-Reply message encodes the immediate 2528 result of attempting an outgoing call request. The flags indicate a 2529 mandatory option. 2531 Assigned Call ID 2533 0 1 2 3 2534 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 |1|0|0|0|0|0| 8 | 0 | 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 | 14 | Call ID | 2539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2540 The Assigned Call ID AVP encodes the ID being assigned to this call 2541 by the LAC. Attribute is 14, indicating Assigned Call ID, and is 2542 marked mandatory. This AVP MUST be present. Call ID value is an 2543 identifier, unique within the tunnel, assigned by the sender to this 2544 session. The remote peer MUST place this Call ID in the Call ID 2545 portion of all future packets it sends associated with this session. 2546 It is used to multiplex and demultiplex data sent over that tunnel 2547 between the LNS and LAC. 2549 Physical Channel ID 2551 0 1 2 3 2552 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 |1|0|0|0|0|0| 10 | 0 | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 | 25 | ID (H) | 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | ID (L) | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2561 Physical Channel ID AVP encodes the vendor specific physical channel 2562 number used for the call. The Attribute value is 25, indicating 2563 Physical Channel ID, and is marked optional. This AVP itself is 2564 optional. ID is a 32-bit value in network byte order. The value is 2565 used for logging purposes only. 2567 6.8 Outgoing-Call-Connected (OCCN) 2569 Outgoing-Call-Connected is an L2TP control message sent by the LAC to 2570 the LNS to indicate that the result of a requested outgoing call was 2571 successful. The LAC MUST send the corresponding Outgoing-Call-Reply 2572 to the LNS before sending this message. This message provides 2573 information to the LNS about the particular parameters used for the 2574 call. It provides information to allow the LNS to regulate the 2575 transmission of data to the LAC for this session. 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | L2TP Control Message Header | 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 | Outgoing-Call-Connected | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 | (Tx) Connect Speed | 2583 | Framing Type | 2584 | Receive Window Size | 2585 | Packet Processing Delay | 2586 | Rx Connect Speed | 2587 | Sequencing Required | 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 Outgoing-Call-Connected 2591 0 1 2 3 2592 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 |1|0|0|0|0|0| 8 | 0 | 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 | 0 | 9 | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 The Message Type AVP contains a Value of 9, indicating Outgoing- 2600 Call-Connected. The Outgoing-Call-Connected message encodes the 2601 final result of an outgoing call request. The flags indicate a 2602 mandatory option. 2604 (Tx) Connect Speed 2606 0 1 2 3 2607 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 |1|0|0|0|0|0| 10 | 0 | 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 | 24 | BPS (H) | 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 | BPS (L) | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen 2617 for the connection attempt. The Attribute value is 24, indicating 2618 (Tx) Connect Speed, and is marked mandatory. This AVP MUST be 2619 present. BPS is a 32-bit value indicating the speed in bits/second. 2621 When the optional Rx Connect Speed AVP is present, the value in this 2622 AVP represents the transmit connect speed, from the perspective of 2623 the LAC (e.g. data flowing from the LAC to the client). When the 2624 optional Rx Connect Speed AVP is NOT present, the connection speed 2625 between the client and LAC is assumed to be symmetric and is 2626 represented by the single value in this AVP. 2628 Framing Type 2630 0 1 2 3 2631 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 |1|0|0|0|0|0| 10 | 0 | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 Framing Type AVP encodes the framing type for the call. The 2641 Attribute value is 19, indicating Framing Type, and is marked 2642 mandatory. This AVP MUST be present. The bit field indicates the 2643 type of PPP framing used for the call. If set, bit A indicates that 2644 asynchronous framing is being used. If set, bit S indicates that 2645 synchronous framing is being used. A particular type of framing may 2646 be used only if it was specified in the Framing Type AVP of the 2647 Outgoing-Call-Request issued by the LNS. 2649 Receive Window Size 2651 0 1 2 3 2652 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2654 |1|0|0|0|0|0| 8 | 0 | 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 | 10 | Size | 2657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 Receive Window Size AVP encodes the window size being offered by the 2660 LNS for this call. The Attribute value is 10, indicating Receive 2661 Window Size, and is marked mandatory. The Size is a 16-bit value 2662 indicating the number of received data packets the LAC will buffer 2663 for this call, which is also the maximum number of data packets the 2664 LNS should send before waiting for an acknowledgment. This AVP is 2665 present only if Sequence and Acknowledgment Numbers are to be used in 2666 the payload session for this call. 2668 Packet Processing Delay 2670 0 1 2 3 2671 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 |1|0|0|0|0|0| 8 | 0 | 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 | 20 | Delay | 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 Packet Processing Delay AVP encodes the delay the LAC expects for 2679 processing a window full of packets sent by the LNS. The Attribute 2680 value is 20, indicating Packet Processing Delay, and is marked 2681 mandatory. This AVP is optional. The Delay value is specified in 2682 units of 1/10 seconds. Refer to Appendix A to see a description of 2683 how this value is determined and used. 2685 Rx Connect Speed 2687 0 1 2 3 2688 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 |0|0|0|0|0|0| 10 | 0 | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 | 38 | BPS (H) | 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 | BPS (L) | 2695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 Rx Connect Speed BPS AVP encodes the receive speed of the facility 2697 chosen for the connection attempt. The Attribute value is 38, 2698 indicating Rx Connect Speed, and is marked optional. The Rx Connect 2699 Speed represents the speed of the connection from the perspective of 2700 the LAC (e.g. data flowing from the client to the LAC). Presence of 2701 this AVP implies that the connection speed may be asymmetric, with 2702 the transmit connect speed given in the (Tx) Connect Speed AVP. BPS 2703 is a 32-bit value indicating the speed in bits/second. 2705 Sequencing Required 2707 0 1 2 3 2708 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 |1|0|0|0|0|0| 6 | 0 | 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 | 39 | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 The Sequencing Required AVP indicates to the LNS that Sequence 2716 Numbers MUST always be present, thus the ability to dynamically drop 2717 sequencing as described in section 4.2 is not an available option. 2718 The Attribute value is 38, Sequencing Required, and is marked 2719 mandatory. The presence of this AVP is optional. This AVP MUST NOT 2720 be present if the Receive Window Size AVP is not present. There is no 2721 value field. 2723 6.9 Incoming-Call-Request (ICRQ) 2725 Incoming-Call-Request is an L2TP control message sent by the LAC to 2726 the LNS to indicate that an inbound call is to be established from 2727 the LAC. This request provides the LNS with parameter information 2728 for the incoming call. 2730 This message is the first in the "three-way handshake" used by L2TP 2731 for establishing incoming calls. The LAC may defer answering the 2732 call until it has received an Incoming-Call-Reply from the LNS 2733 indicating that the call should be established. This mechanism 2734 allows the LNS to obtain sufficient information about the call before 2735 determining whether the call should be answered or not. 2736 Alternatively, the LAC may answer the call, negotiate LCP and PPP 2737 authentication, and use the information gained to choose the LNS. In 2738 this case, the call has already been answered by the time the 2739 Incoming-Call-Reply message is received; the LAC simply spoofs the 2740 "call indication/answer call" phase in this case. 2742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 | L2TP Control Message Header | 2744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 | Incoming-Call-Request | 2746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 | Assigned Call ID | 2748 | Call Serial Number | 2749 | Bearer Type | 2750 | Physical Channel ID | 2751 | Dialed Number | 2752 | Dialing Number | 2753 | Sub-Address | 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 Incoming-Call-Request 2758 0 1 2 3 2759 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2761 |1|0|0|0|0|0| 8 | 0 | 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 | 0 | 10 | 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 The Message Type AVP contains a Value of 10, indicating Incoming- 2767 Call-Request. The Incoming-Call-Request message encodes an incoming 2768 call being indicated by the LAC. The flags indicate a mandatory 2769 option. 2771 Assigned Call ID 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|0|0| 8 | 0 | 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | 14 | Call ID | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 The Assigned Call ID AVP encodes the ID being assigned to this call 2782 by the LAC. The Attribute value is 14, indicating Assigned Call ID, 2783 and is marked mandatory. This AVP MUST be present. The LNS places 2784 this value in the Call ID header field of all command and payload 2785 packets that belong to this call and are subsequently transmitted 2786 over the tunnel. The Call ID value is an identifier assigned by the 2787 LAC to this session. It is used to multiplex and demultiplex data 2788 sent over that tunnel between the LNS and LAC. 2790 Call Serial Number 2792 0 1 2 3 2793 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 |1|0|0|0|0|0| 10 | 0 | 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2797 | 15 | CSN (H) | 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 | CSN (L) | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 Call Serial Number AVP encodes an identifier assigned by the LAC to 2803 this call. The Attribute value is 15, Call Serial Number, and is 2804 marked mandatory. This AVP MUST be present. Please refer to section 2805 6.6 for a description of the contents of this AVP. 2807 Bearer Type 2809 0 1 2 3 2810 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 |1|0|0|0|0|0| 10 | 0 | 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2814 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2816 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 Bearer Type AVP encodes the bearer type for the incoming call. The 2820 Attribute value is 18, Bearer Type, and is marked mandatory. This 2821 AVP is optional. The Value is a 32-bit field indicating the bearer 2822 capability being used by the incoming call. If set, bit A indicates 2823 that the call is on an analog channel. If set, bit D indicates that 2824 the call is on a digital channel. 2826 Physical Channel ID 2828 0 1 2 3 2829 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2831 |1|0|0|0|0|0| 10 | 0 | 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 | 25 | ID (H) | 2834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 | ID (L) | 2836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2838 Physical Channel ID AVP encodes the vendor specific physical channel 2839 number used for the call. The Attribute value is 25, Physical 2840 Channel ID, and is marked mandatory. The presence of this AVP is 2841 optional. ID is a 32-bit value in network byte order. The value is 2842 used for logging purposes only. 2844 Dialed Number 2846 0 1 2 3 2847 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 |1|0|0|0|0|0| 6+Phone Number len| 0 | 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 | 21 | Phone Number.. 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 Dialed Number AVP encodes the dialed number for the incoming call, 2855 that is, DNIS. The Attribute value is 21, Dialed Number, and is 2856 marked mandatory. The presence of this AVP is optional. The value 2857 is an ASCII string. 2859 Dialing Number 2861 0 1 2 3 2862 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2864 |1|0|0|0|0|0| 6+Phone Number len| 0 | 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2866 | 22 |Phone Number... 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 Dialing Number AVP encodes the originating number for the incoming 2870 call, that is, CLID. The Attribute value is 22, Dialing Number, and 2871 is marked mandatory. The presence of this AVP is optional. The 2872 value is an ASCII string. 2874 Sub-Address 2876 0 1 2 3 2877 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2879 |1|0|0|0|0|0| 6+Sub-Address len | 0 | 2880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2881 | 23 |Sub-Address ... 2882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2884 Sub-Address AVP encodes additional dialing information. The 2885 Attribute value is 23, Sub-Address, and is marked mandatory. The 2886 presence of this AVP is optional. The Sub-Address value is an ASCII 2887 string. 2889 6.10 Incoming-Call-Reply (ICRP) 2891 The Incoming-Call-Reply is an L2TP control message sent by the LNS to 2892 the LAC in response to a received Incoming-Call-Request message. The 2893 reply indicates that the request was successful. It also provides 2894 information to allow the LAC to regulate the transmission of data to 2895 the LNS for this session. 2897 This message is the second in the three-way handshake used by L2TP 2898 for establishing incoming calls. It indicates to the LAC that the 2899 call should be answered. 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 | L2TP Control Message Header | 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2904 | Incoming-Call-Reply | 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2906 | Assigned Call ID | 2907 | Receive Window Size | 2908 | Packet Processing Delay | 2909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2911 Incoming-Call-Reply 2913 0 1 2 3 2914 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2916 |1|0|0|0|0|0| 8 | 0 | 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2918 | 0 | 11 | 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 The Message Type AVP contains a Value of 11, indicating Incoming- 2922 Call-Reply. The Incoming-Call-Reply message encodes a response by 2923 the LNS to the incoming call indication given by the LAC. The flags 2924 indicate a mandatory option. 2926 Assigned Call ID 2928 0 1 2 3 2929 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 |1|0|0|0|0|0| 8 | 0 | 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 | 14 | Call ID | 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2936 The Assigned Call ID AVP encodes the ID being assigned to this call 2937 by the LNS. The Attribute value is 14, indicating Assigned Call ID, 2938 and is marked mandatory. This AVP MUST be present. The LAC places 2939 this value in the Call ID header field of all command and payload 2940 packets that it subsequently transmits over the tunnel that belong to 2941 this call. The Call ID value is an identifier assigned by the LNS to 2942 this session. It is used to multiplex and demultiplex data sent over 2943 that tunnel between the LNS and LAC. 2945 Receive Window Size 2947 0 1 2 3 2948 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2950 |1|0|0|0|0|0| 8 | 0 | 2951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2952 | 10 | Size | 2953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 Receive Window Size AVP encodes the receive window size being offered 2956 by the LNS for this call. The Attribute value is 10, Receive Window 2957 Size, and is marked mandatory. The Size value indicates the number 2958 of received data packets the LNS will buffer for this call, which is 2959 also the maximum number of data packets the LAC should send before 2960 waiting for an acknowledgment. This AVP is present only if Sequence 2961 and Acknowledgment Numbers are to be used in the payload session for 2962 this call. 2964 Packet Processing Delay 2966 0 1 2 3 2967 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 |1|0|0|0|0|0| 8 | 0 | 2970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2971 | 20 | Delay | 2972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 Packet Processing Delay AVP encodes the expected delay that occurs at 2975 the LNS in processing a window full of packets sent by the LAC. The 2976 Attribute value is 20, Packet Processing Delay AVP, and is marked 2977 mandatory. The presence of this AVP is optional. The Delay value is 2978 specified in units of 1/10 seconds. Refer to Appendix A to see a 2979 description of how this value is determined and used. 2981 6.11 Incoming-Call-Connected (ICCN) 2983 The Incoming-Call-Connected message is an L2TP control message sent 2984 by the LAC to the LNS in response to a received Incoming-Call-Reply. 2985 It provides information to the LNS about particular parameters used 2986 for the call. It also provides information to allow the LNS to 2987 regulate the transmission of data to the LAC for this session. 2989 This message is the third in the three-way handshake used by L2TP for 2990 establishing incoming calls. It provides a mechanism for providing 2991 the LNS with additional information about the call that cannot, in 2992 general, be obtained at the time the Incoming-Call-Request is issued 2993 by the LAC. 2995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2996 | L2TP Control Message Header | 2997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2998 | Incoming-Call-Connected | 2999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3000 | (Tx) Connect Speed | 3001 | Framing Type | 3002 | Receive Window Size | 3003 | Packet Processing Delay | 3004 | Initial Received LCP Confreq | 3005 | Last Sent LCP Confreq | 3006 | Last Received LCP Confreq | 3007 | Proxy authen type | 3008 | Proxy authen name | 3009 | Proxy authen challenge | 3010 | Proxy authen ID | 3011 | Proxy authen response | 3012 | Private Group ID | 3013 | Rx Connect Speed | 3014 | Sequencing Required | 3015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3017 Incoming-Call-Connected 3019 0 1 2 3 3020 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3022 |1|0|0|0|0|0| 8 | 0 | 3023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3024 | 0 | 12 | 3025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3027 The Message Type AVP contains a Value of 12, indicating Incoming- 3028 Call-Connected. The Incoming-Call-Connected message encodes a 3029 response by the LAC to the Incoming-Call-Reply message sent by the 3030 LAC. The flags indicate a mandatory option. 3032 (Tx) Connect Speed 3034 0 1 2 3 3035 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3037 |1|0|0|0|0|0| 10 | 0 | 3038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3039 | 24 | BPS (H) | 3040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3041 | BPS (L) | 3042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3044 (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen 3045 for the connection attempt. The Attribute value is 24, indicating 3046 (Tx) Connect Speed, and is marked mandatory. This AVP MUST be 3047 present. BPS is a 32-bit value indicating the speed in bits/second. 3049 When the optional Rx Connect Speed AVP is present, the value in this 3050 AVP represents the transmit connect speed, from the perspective of 3051 the LAC (e.g. data flowing from the LAC to the client). When the 3052 optional Rx Connect Speed AVP is NOT present, the connection speed 3053 between the client and LAC is assumed to be symmetric and is 3054 represented by the single value in this AVP. 3056 Framing Type 3058 0 1 2 3 3059 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3061 |1|0|0|0|0|0| 10 | 0 | 3062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3063 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 3064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 3066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3068 Framing Type AVP encodes the framing type for the call. The 3069 Attribute value is 19, Framing Type, and is marked mandatory. This 3070 AVP MUST be present. The value is a 32-bit bit field indicating the 3071 type of PPP framing used for the call. If set, bit A indicates that 3072 asynchronous framing is being used. If set, bit S indicates that 3073 synchronous framing is being used. A particular type of framing may 3074 be used only if was specified in the Value field of the Framing 3075 Capabilities AVP received from the LNS during control session 3076 establishment. 3078 Receive Window Size 3080 0 1 2 3 3081 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3083 |1|0|0|0|0|0| 8 | 0 | 3084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3085 | 10 | Size | 3086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 Receive Window Size AVP encodes the window size being offered by the 3089 LAC for this call. The Attribute value is 10, Receive Window Size, 3090 and is marked mandatory. This AVP is present only if Sequence and 3091 Acknowledgment Numbers are to be used in the payload session for this 3092 call. The 16-bit Size value indicates the number of received data 3093 packets the LAC will buffer for this call, which is also the maximum 3094 number of data packets the LNS should send before waiting for an 3095 acknowledgment. 3097 Packet Processing Delay 3099 0 1 2 3 3100 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3102 |1|0|0|0|0|0| 8 | 0 | 3103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 | 20 | Delay | 3105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3107 Packet Processing Delay AVP encodes the delay the LAC expects for 3108 processing a window full of packets sent by the LNS. The Attribute 3109 value is 20, Packet Processing Delay, and is marked mandatory. The 3110 presence of this AVP is optional. The 16-bit Delay value is 3111 specified in units of 1/10 seconds. Refer to Appendix A to see a 3112 description of how this value is determined and used. 3114 Initial Received LCP Confreq 3116 0 1 2 3 3117 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3119 |0|0|0|0|0|0| 6+LCP Confreq len | 0 | 3120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3121 | 26 | LCP confreq... 3122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3124 The LAC may have answered the phone call and negotiated LCP with the 3125 dial-in client in order to establish the client's apparent identity. 3126 In this case, this option may be included to indicate the link 3127 properties the client requested in its initial LCP CONFREQ request. 3128 The Attribute value is 26, Initial Received LCP Confreq, and is 3129 marked optional. The presence of this AVP is optional. The Value 3130 field is a copy of the body of the initial CONFREQ received, starting 3131 at the first option within this packet's body. 3133 Last Sent LCP Confreq 3135 0 1 2 3 3136 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3138 |0|0|0|0|0|0| 6+LCP Confreq len | 0 | 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3140 | 27 | LCP confreq... 3141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3143 See Initial Received LCP Confreq above for rationale. The Attribute 3144 value is 27, Last Sent LCP Confreq, and is marked optional. The 3145 presence of this AVP is optional. The Value field is a copy of the 3146 body of the final CONFREQ sent to the client to complete LCP 3147 negotiation, starting at the first option within this packet's body. 3149 Last Received LCP Confreq 3151 0 1 2 3 3152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3154 |0|0|0|0|0|0| 6+LCP Confreq len | 0 | 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 | 28 | LCP confreq... 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3159 See Initial Received LCP Confreq above for rationale. The Attribute 3160 value is 28, Last Received LCP Confreq, and is marked optional. The 3161 presence of this AVP is optional. The Value field is a copy of the 3162 body of the final CONFREQ received from the client to complete LCP 3163 negotiation, starting at the first option within this packet's body. 3165 Proxy Authen Type 3167 0 1 2 3 3168 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 |0|0|0|0|0|0| 8 | 0 | 3171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3172 | 29 | Type | 3173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 The Attribute value is 29, Proxy Authen Type, and is optional. This 3176 AVP MUST be present if proxy authentication is to be utilized. If it 3177 is not present, then it is assumed that this peer cannot perform 3178 proxy authentication, perhaps requiring a restart of the 3179 authentication phase at the LNS if the client has already entered 3180 this phase with the LAC. The value Type is a 16-bit word, holding a 3181 value: 3183 1 - Textual username/password exchange 3184 2 - PPP CHAP 3185 3 - PPP PAP 3186 4 - None 3187 5 - Microsoft CHAP (MSCHAP) 3189 Associated AVP's for each type of authentication follow. 3191 Proxy Authen Name 3193 0 1 2 3 3194 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3196 |0|0|0|0|0|0| 6 + Name length | 0 | 3197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3198 | 30 | Name... 3199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3201 The Attribute value is 30, Proxy Authen Name, and is marked optional. 3202 This AVP MUST be present for Proxy Authen Type values 1, 2, 3 and 5. 3204 The Name field contains the name specified in the client's 3205 authentication response. Note that the AVP H bit may be desirable 3206 for obscuring the cleartext name. 3208 Proxy Authen Challenge 3210 0 1 2 3 3211 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3213 |0|0|0|0|0|0| 6 + Challenge len | 0 | 3214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3215 | 31 | Challenge... 3216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3218 The Attribute value is 31, Proxy Authen Challenge, and is marked 3219 optional. The AVP itself MUST be present for Proxy authen types 2 3220 and 5. The Challenge field contains the value presented to the 3221 client by the LAC. 3223 Proxy Authen ID 3225 0 1 2 3 3226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3228 |0|0|0|0|0|0| 8 | 0 | 3229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3230 | 32 | ID | 3231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3233 The Attribute value is 32, Proxy Authen ID, and is marked optional. 3234 The AVP itself MUST be present for Proxy authen types 2, 3 and 5. 3235 For CHAP and MSCHAP, the ID field contains the byte ID value 3236 presented to the client by the LAC in its Challenge. For PAP, it is 3237 the Identifier value of the Authenticate-Request. The most 3238 significant 8 bits of ID MUST be 0, and are reserved. 3240 Proxy Authen Response 3242 0 1 2 3 3243 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3245 |1|0|0|0|0|0| 6 + Response len | 0 | 3246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3247 | 33 | Response... 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3250 The Attribute value is 33, Proxy Authen Response, and is marked 3251 mandatory. The AVP itself MUST be present for Proxy authen types 1, 3252 2, 3 and 5. The Response field contains the client's response to the 3253 challenge. For Proxy authen types 2 and 5, this field contains the 3254 response value received by the LAC. For types 1 or 3, it contains 3255 the clear text password received from the client by the LAC. In the 3256 case of cleartext passwords, use of the AVP H bit is recommended. 3258 Private Group ID 3260 0 1 2 3 3261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3263 |0|0|0|0|0|0| 6+Private ID len | 0 | 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 | 37 | Private Group ID ... 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3268 PrivateGroup ID AVP is used by the LAC to indicate that this call is 3269 to be associated with a particular customer group. The Attribute is 3270 37, Private Group ID, and is marked optional. The presence of this 3271 AVP is optional. The LNS MAY treat the PPP session as well as 3272 network traffic through this session specially in a manner determined 3273 by the peer. For example, if the LNS is individually connected to 3274 several private networks using unregistered addresses, this AVP may 3275 be included by the LAC to indicate that a given call should be 3276 associated with one of the private networks. 3278 The Private Group ID is a string corresponding to a table in the LNS 3279 that defines the particular characteristics of the selected group. A 3280 LAC MAY determine the Private Group ID from a RADIUS response 3281 containing the PrivateGroupID attribute [13]. 3283 Rx Connect Speed 3285 0 1 2 3 3286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3288 |0|0|0|0|0|0| 10 | 0 | 3289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3290 | 38 | BPS (H) | 3291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3292 | BPS (L) | 3293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3295 Rx Connect Speed BPS AVP encodes the receive speed of the facility 3296 chosen for the connection attempt. The Attribute value is 38, 3297 indicating Rx Connect Speed, and is marked optional. The Rx Connect 3298 Speed represents the speed of the connection from the perspective of 3299 the LAC (e.g. data flowing from the client to the LAC). Presence of 3300 this AVP implies that the connection speed may be asymmetric, with 3301 the transmit connect speed given in the (Tx) Connect Speed AVP. BPS 3302 is a 32-bit value indicating the speed in bits/second. 3304 Sequencing Required 3306 0 1 2 3 3307 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3309 |1|0|0|0|0|0| 6 | 0 | 3310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3311 | 39 | 3312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3314 The Sequencing Required AVP indicates to the LNS that Sequence 3315 Numbers MUST always be present, thus the ability to dynamically drop 3316 sequencing as described in section 4.2 is not an available option. 3317 The Attribute value is 38, Sequencing Required, and is marked 3318 mandatory. The presence of this AVP is optional. This AVP MUST NOT 3319 be present if the Receive Window Size AVP is not present. There is no 3320 value field. 3322 6.12 Call-Disconnect-Notify (CDN) 3324 The Call-Disconnect-Notify message is an L2TP control message sent to 3325 request disconnection of a specific call within the tunnel. Its 3326 purpose is to inform the peer of the disconnection and the reason why 3327 the disconnection occurred. The peer MUST clean up any resources, 3328 and does not send back any indication of success or failure for such 3329 cleanup. 3331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3332 | L2TP Control Message Header | 3333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3334 | Call-Disconnect-Notify | 3335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3336 | Result Code | 3337 | Q.931 Cause Code | 3338 | Assigned Call ID | 3339 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 Call-Disconnect-Notify 3343 0 1 2 3 3344 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3346 |1|0|0|0|0|0| 8 | 0 | 3347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3348 | 0 | 14 | 3349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 The Message Type AVP contains a Value of 14, indicating Call- 3352 Disconnect-Notify. The Call-Disconnect-Notify message encodes a 3353 disconnect indication for a specific call within the tunnel. The 3354 flags indicate a mandatory option. 3356 Result Code 3358 0 1 2 3 3359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 |1|0|0|0|0|0| 10 + Message len | 0 | 3362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 | 1 | Result Code | 3364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3365 | Error Code | Optional Message ... 3366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3368 The Result Code AVP within a Call-Disconnect-Notify message 3369 indicates the reason for the call disconnect. It is encoded as 3370 Attribute 1, indicating a Result Code AVP. This AVP is mandatory 3371 and MUST be present. The Result Code is a 16-bit word. The 16- 3372 bit word following the Result Code field contains the Error Code 3373 value. The Result Code value indicates whether the Error Code 3374 value is meaningful or not. If Error Code is not meaningful it 3375 MUST be set to 0. An optional error message can follow the Error 3376 Code field; its presence and length is indicated by the value of 3377 the AVP length field. Defined Result Code values are: 3379 1 - Call disconnected due to loss of carrier 3380 2 - Call disconnected for the reason indicated in Error Code. 3381 3 - Call disconnected for administrative reasons 3382 4 - Call failed due to no appropriate facilities being 3383 available (temporary condition) 3384 5 - Call failed due to no appropriate facilities being 3385 available (permanent condition) 3386 6 - Invalid destination 3387 7 - Call failed due to no carrier detected 3388 8 - Call failed due to detection of a busy signal 3389 9 - Call failed due to lack of a dial tone 3390 10 - Call was not established within time allotted by LAC 3391 11 - Call was connected but no appropriate framing was detected 3393 Q.931 Cause Code 3395 0 1 2 3 3396 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3398 |0|0|0|0|0|0| 9+Advisory Msg len| 0 | 3399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3400 | 12 | Cause Code | 3401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3402 | Cause Msg |Advisory Msg...| 3403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3405 The Q.931 Cause Code AVP is used to give additional information in 3406 case of unsolicited call disconnection. The Attribute value is 12, 3407 Cause Code, and is marked mandatory. The presence of this AVP is 3408 optional. The Cause Code AVP is used to give additional information 3409 about the reason for disconnecting. It is only relevant when the LAC 3410 is using Q.931/DSS1 for the call. This AVP is optional. Cause Code 3411 is the returned Q.931 Cause code and Cause Msg is the returned Q.931 3412 message code (e.g., DISCONNECT) associated with the Cause Code. Both 3413 values are returned in their native ITU encodings. An additional 3414 ASCII text Advisory Message may also be included (presence indicated 3415 by the AVP length) to further explain the reason for disconnecting. 3417 Assigned Call ID 3419 0 1 2 3 3420 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3422 |1|0|0|0|0|0| 8 | 0 | 3423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3424 | 14 | Call ID | 3425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3427 The Assigned Call ID which was provided to the LNS from this LAC is 3428 included in the Call-Disconnect-Notify message. This permits a 3429 connection to be terminated even before the LNS has provided its own 3430 Assigned Call ID to this LAC (the Call ID field in the control 3431 message header is 0). The Attribute value is 14, Assigned Call ID, 3432 and is marked mandatory. This AVP MUST be present. 3434 6.13 WAN-Error-Notify (WEN) 3436 The WAN-Error-Notify message is an L2TP control message sent by the 3437 LAC to the LNS to indicate WAN error conditions (conditions that 3438 occur on the interface supporting PPP). The counters in this message 3439 are cumulative. This message should only be sent when an error 3440 occurs, and not more than once every 60 seconds. The counters are 3441 reset when a new call is established. 3443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3444 | L2TP Control Message Header | 3445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 | WAN-Error-Notify | 3447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3448 | Call Errors | 3449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3451 WAN-Error-Notify 3453 0 1 2 3 3454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3456 |1|0|0|0|0|0| 8 | 0 | 3457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3458 | 0 | 15 | 3459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3461 The Message Type AVP contains a Value of 15, indicating WAN-Error- 3462 Notify. The WAN-Error-Notify message encodes information about line 3463 and other errors detected on the LAC's physical interface to the 3464 client. This message is sent by the LAC to the LNS. The flags 3465 indicate a mandatory option. 3467 Call Errors 3469 0 1 2 3 3470 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3472 |1|0|0|0|0|0| 32 | 0 | 3473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3474 | 34 | Reserved | 3475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3476 | CRC Errors | 3477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3478 | Framing Errors | 3479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3480 | Hardware Overruns | 3481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3482 | Buffer Overruns | 3483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3484 | Time-out Errors | 3485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3486 | Alignment Errors | 3487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3489 The Call Errors AVP is used by the LAC to send error information to 3490 the LNS. The Attribute value is 34, WAN-Error-Notify, and is marked 3491 mandatory. This AVP MUST be present. The value contains the 3492 following fields: 3494 Reserved - Not used, MUST be 0 3495 CRC Errors - Number of PPP frames received with CRC errors since 3496 session was established 3497 Framing Errors - Number of improperly framed PPP packets received 3498 Hardware Overruns - Number of receive buffer over-runs since 3499 session was established 3500 Buffer Overruns - Number of buffer over-runs detected since 3501 session was established 3502 Time-out Errors - Number of time-outs since call was established 3503 Alignment Errors - Number of alignment errors since call was 3504 established 3506 6.14 Set-Link-Info (SLI) 3508 The Set-Link-Info message is an L2TP control message sent by the LNS 3509 to the LAC to set PPP-negotiated options. Because these options can 3510 change at any time during the life of the call, the LAC MUST be able 3511 to update its internal call information dynamically and update its 3512 behavior on an active PPP session. 3514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3515 | L2TP Control Message Header | 3516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3517 | Set-Link-Info | 3518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3519 | ACCM | 3520 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3522 Set-Link-Info 3524 0 1 2 3 3525 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3527 |1|0|0|0|0|0| 8 | 0 | 3528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3529 | 0 | 16 | 3530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3532 The Message Type AVP contains a Value of 16, indicating Set-Link- 3533 Info. The Set-Link-Info message encodes ACCM information sent from 3534 the LNS to the LAC after it is negotiated in LCP. The flags indicate 3535 a mandatory option. 3537 ACCM 3539 0 1 2 3 3540 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3542 |1|0|0|0|0|0| 16 | 0 | 3543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3544 | 35 | Reserved | 3545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3546 | Send ACCM | 3547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3548 | Receive ACCM | 3549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3551 The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. 3552 The Attribute value is 35, ACCM, and is marked mandatory. This 3553 attribute MUST be present. The value contains Send ACCM and Receive 3554 ACCM fields. The send ACCM value should be used by the LAC to 3555 process packets it is sends on the connection. The receive ACCM 3556 value should be used by the LAC to process incoming packets on the 3557 connection. The default values used by the LAC for both these fields 3558 are 0xFFFFFFFF. The LAC should honor these fields unless it has 3559 specific configuration information to indicate that the requested 3560 mask must be modified to permit operation. 3562 7.0 Control Connection State Machines 3564 The control messages defined in section 6 are exchanged by way of state 3565 tables defined in this section. Tables are defined for incoming call 3566 placement, outgoing call placement, as well as for initiation of the 3567 tunnel itself. The state tables do not encode timeout and 3568 retransmission behavior, as this is handled in the underlying semantics 3569 defined in 6.0.2. 3571 7.1 Control Connection Protocol Operation 3573 This section describes the operation of various L2TP control 3574 connection functions and the Control Connection messages which are 3575 used to support them. 3577 Receipt of an invalid or malformed Control Connection message should 3578 be logged appropriately, and the control connection should be closed 3579 and restarted to ensure recovery into a known state. 3581 In several cases in the following tables, a protocol message is sent, 3582 and then a "clean up" occurs. Note that regardless of the initiator 3583 of the tunnel destruction, the reliable delivery mechanism must be 3584 allowed to run (see 6.0.2) before destroying the tunnel. This 3585 permits the tunnel management messages to be reliably delivered to 3586 the peer. 3588 7.2 Control Connection States 3590 Control messages are carried over the same media as the payload 3591 messages which are carried following successful connection 3592 establishment. The L2TP control connection protocol is not 3593 distinguishable between the LNS and LAC, but is distinguishable 3594 between the originator and receiver. The originating peer is the one 3595 which first initiates establishment of the tunnel (in a tie breaker 3596 situation, this is the winner of the tie). Since either LAC or LNS 3597 can be the originator, a collision can occur. See Section 6.0.1 for 3598 a description of this and its resolution. 3600 7.2.1 Control Connection Establishment 3602 State Event Action New State 3603 ----- ----- ------ --------- 3604 idle Local Send SCCRQ wait-ctl-reply 3605 Open request 3607 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3608 acceptable 3610 idle Receive SCCRQ, Send StopCCN, idle 3611 not acceptable Clean up 3613 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3614 acceptable Send tunnel-open 3615 event to waiting 3616 sessions 3618 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3619 not acceptable Clean up 3621 wait-ctl-reply Receive SCCRQ, Clean up, idle 3622 lose tie-breaker Re-queue SCCRQ 3623 for idle state 3625 wait-ctl-conn Receive SCCCN, Send tunnel-open established 3626 acceptable event to waiting 3627 sessions 3629 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3630 not acceptable Clean up 3632 established Local Send tunnel-open established 3633 Open request event to waiting 3634 (new client) sessions 3636 established Admin Send StopCCN idle 3637 Tunnel Close Clean up 3639 wait-ctl-reply, 3640 wait-ctl-conn, 3641 established Receive StopCCN Clean up idle 3643 idle 3644 Both initiator and recipient start from this state. An initiator 3645 transmits a SCCRQ, while a recipient remains in the idle state 3646 until receiving a SCCRQ. 3648 wait-ctl-reply 3649 The originator checks to see if another connection has been 3650 requested from the same peer, and if so, handles the collision 3651 situation described in Section 6.0.1. 3653 When a SCCRP is received, it is examined for a compatible version. 3654 If the version of the reply is lower than the version sent in the 3655 request, the older (lower) version should be used provided it is 3656 supported. If the version in the reply is earlier and supported, 3657 the originator moves to the established state. If the version is 3658 earlier and not supported, a StopCCN MUST be sent to the peer and 3659 the originator cleans up and terminates the tunnel. 3661 wait-ctl-conn 3662 This is where an SCCCN is awaited; upon receipt, protocol version 3663 compatibility is checked. The tunnel is either established, or is 3664 torn down if a protocol mismatch is detected. 3666 established 3667 An established connection may be terminated by either a local 3668 condition or the receipt of a Stop-Control-Connection- 3669 Notification. In the event of a local termination, the originator 3670 MUST send a Stop-Control-Connection-Notification and clean up the 3671 tunnel. 3673 If the originator receives a Stop-Control-Connection-Notification 3674 it MUST also clean up the tunnel. 3676 7.3 Timing considerations 3678 Because of the real-time nature of telephone signaling, both the LNS 3679 and LAC should be implemented with multi-threaded architectures such 3680 that messages related to multiple calls are not serialized and 3681 blocked. The call and connection state figures do not specify 3682 exceptions caused by timers. These are addressed in Section 6.0.2. 3684 7.4 Incoming calls 3686 An Incoming-Call-Request message is generated by the LAC when an 3687 associated telephone line rings. The LAC selects a Call ID and 3688 serial number and indicates the call bearer type. Modems should 3689 always indicate analog call type. ISDN calls should indicate digital 3690 when unrestricted digital service or rate adaption is used and analog 3691 if digital modems are involved. CLID, DNIS, and subaddress may be 3692 included in the message if they are available from the telephone 3693 network. 3695 Once the LAC sends the Incoming-Call-Request, it waits for a response 3696 from the LNS but it does not necessarily answer the call from the 3697 telephone network yet. The LNS may choose not to accept the call if: 3699 - No resources are available to handle more sessions 3700 - The dialed, dialing, or subaddress fields do not correspond to 3701 an authorized user 3702 - The bearer service is not authorized or supported 3704 If the LNS chooses to accept the call, it responds with an Incoming- 3705 Call-Reply which may also indicate window sizes (see Appendix B). 3706 When the LAC receives the Incoming-Call-Reply, it attempts to connect 3707 the call. A final call connected message from the LAC to the LNS 3708 indicates that the call states for both the LAC and the LNS should 3709 enter the established state. If the call terminated before the LNS 3710 could accept it, a Call-Disconnect-Notify is sent by the LAC to 3711 indicate this condition. 3713 When the dialed-in client hangs up, the call is cleared normally and 3714 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 3715 clear a call, it sends a Call-Disconnect-Notify message and cleans up 3716 its session. 3718 7.4.1 LAC Incoming Call States 3720 State Event Action New State 3721 ----- ----- ------ --------- 3722 idle Bearer Ring or Initiate local wait-tunnel 3723 Ready to indicate tunnel open 3724 incoming conn. 3726 wait-tunnel tunnel-open Send ICRQ wait-reply 3728 wait-reply Receive ICRP, Answer call, established 3729 acceptable Send ICCN 3731 wait-reply Receive ICRP, Send CDN, idle 3732 not acceptable Clean up 3734 wait-reply Receive CDN Clean up idle 3736 wait-reply Local Send CDN, idle 3737 Close request Clean up 3739 established Receive CDN Hang up bearer, idle 3740 Clean up 3742 established Local Hang up bearer, idle 3743 Close request Send CDN, 3744 Clean up 3746 established Bearer Send CDN, idle 3747 Line drop Clean up 3749 The states associated with the LAC for incoming calls are: 3751 idle 3752 The LAC detects an incoming call on one of its interfaces. 3753 Typically this means an analog line is ringing or an ISDN TE has 3754 detected an incoming Q.931 SETUP message. The LAC initiates its 3755 tunnel establishment state machine, and moves to a state waiting 3756 for confirmation of the existence of a tunnel. 3758 wait-tunnel 3759 In this state the session is waiting for either the control tunnel 3760 to be opened or for verification that the tunnel is already open. 3761 Once an indication that the tunnel has/was opened, session control 3762 messages may be exchanged. The first of these is the Incoming- 3763 Call-Request. 3765 wait-reply 3766 The LAC receives an Incoming-Call-Reply message indicating non- 3767 willingness to accept the call (general error or don't accept) and 3768 moves back into the idle state. If the reply message indicates 3769 that the call is accepted, the LAC sends an Incoming-Call- 3770 Connected message and enters the established state. 3772 established 3773 Data is exchanged over the tunnel. The call may be cleared 3774 following: 3775 An event on the connected interface. The LAC sends a Call- 3776 Disconnect-Notify message 3777 Receipt of a Call-disconnect-Notify message. The LAC cleans 3778 up, disconnecting the call. 3779 A local reason. The LAC sends a Call-Disconnect-Notify 3780 message. 3782 7.4.2 LNS Incoming Call States 3783 State Event Action New State 3784 ----- ----- ------ --------- 3785 idle Receive ICRQ, Send ICRP wait-connect 3786 acceptable 3788 idle Receive ICRQ, Send CDN, idle 3789 not acceptable Clean up 3791 wait-connect Receive ICCN Prepare for established 3792 acceptable data 3794 wait-connect Receive ICCN Send CDN, idle 3795 not acceptable Clean up 3797 wait-connect, 3798 established Receive CDN Clean up idle 3800 established Local Send CDN, idle 3801 Close request Clean up 3803 The states associated with the LNS for incoming calls are: 3805 idle 3806 An Incoming-Call-Request message is received. If the request is 3807 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 3808 and the LNS remains in the idle state. If the Incoming-Call- 3809 Request message is acceptable, an Incoming-Call-Reply is sent. 3810 The session moves to the wait-connect state. 3812 wait-connect 3813 If the session is still connected on the LAC, the LAC sends an 3814 Incoming-Call-Connected message to the LNS which then moves into 3815 established state. The LAC may send a Call-Disconnect-Notify to 3816 indicate that the incoming caller could not be connected. This 3817 could happen, for example, if a telephone user accidentally places 3818 a standard voice call to an LAC resulting in a handshake failure 3819 on the called modem. 3821 established 3822 The session is terminated either by receipt of a Call-Disconnect- 3823 Notify message from the LAC or by sending a Call-Disconnect- 3824 Notify. Clean up follows on both sides regardless of the 3825 initiator. 3827 7.5 Outgoing calls 3829 Outgoing calls are initiated by an LNS and instruct an LAC to place a 3830 call. There are three messages for outgoing calls: Outgoing-Call- 3831 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 3832 sends an Outgoing-Call-Request specifying the dialed party phone 3833 number and subaddress as well as speed and window parameters. The 3834 LAC MUST respond to the Outgoing-Call-Request message with an 3835 Outgoing-Call-Reply message once the LAC determines that the proper 3836 facilities exist to place the call and the call is administratively 3837 authorized. For example, is this LNS allowed to dial an 3838 international call? Once the outbound call is connected, the LAC 3839 sends an Outgoing-Call-Connected message to the LNS indicating the 3840 final result of the call attempt: 3842 7.5.1 LAC Outgoing Call States 3844 State Event Action New State 3845 ----- ----- ------ --------- 3846 idle Receive OCRQ, Send OCRP, wait-cs-answer 3847 acceptable Open bearer 3849 idle Receive OCRQ, Send CDN, idle 3850 not acceptable Clean up 3852 wait-cs-answer Bearer answer, Send OCCN established 3853 framing detected 3855 wait-cs-answer Bearer failure Send CDN, idle 3856 Clean up 3858 wait-cs-answer, 3859 established Receive CDN Hang up bearer, idle 3860 Clean up 3862 The states associated with the LAC for outgoing calls are: 3864 idle 3865 Received Outgoing-Call-Request. If this is received in error, 3866 respond with a Call-Disconnect-Notify. Otherwise, allocate a 3867 physical channel and send an Outgoing-Call-Reply. Place the 3868 outbound call and move to the wait-cs-answer state. 3870 wait-cs-answer 3871 If the call is not completed or a timer expires waiting for the 3872 call to complete, send a Call-Disconnect-Notify with the 3873 appropriate error condition set and go to idle state. If a 3874 circuit switched connection is established and framing is 3875 detected, send an Outgoing-Call-Connected indicating success and 3876 go to established state. 3878 established 3879 If a Call-Disconnect-Notify is received by the LAC, the telco call 3880 MUST be released via appropriate mechanisms and the session 3881 cleaned up. If the call is disconnected by the client or the 3882 called interface, a Call-Disconnect-Notify message MUST be sent to 3883 the LNS. The sender of the Call-Disconnect-Notify message returns 3884 to the idle state after sending of the message is complete. 3886 7.5.2 LNS Outgoing Call States 3888 State Event Action New State 3889 ----- ----- ------ --------- 3890 idle Local Initiate local wait-tunnel 3891 Open request tunnel-open 3893 wait-tunnel tunnel-open Send OCRQ wait-reply 3895 wait-reply Receive OCRP, none wait-connect 3896 acceptable 3898 wait-reply Receive OCRP, Send CDN idle 3899 not acceptable 3901 wait-connect Receive OCCN none established 3903 established, 3904 wait-connect Receive CDN Clean up idle 3906 wait-reply, 3907 wait-connect, 3908 established Local Send CDN idle 3909 Close request 3911 The states associated with the LNS for outgoing calls are: 3913 idle, wait-tunnel 3914 When an outgoing call is initiated, a tunnel is first created, 3915 much as the idle and wait-tunnel states for an LAC incoming call. 3916 Once a tunnel is established, an Outgoing-Call-Request message is 3917 sent to the LAC and the session moves into the wait-reply state. 3919 wait-reply 3920 If a Call-Disconnect-Notify is received, an error occurred, and 3921 the session is cleaned up and returns to idle. If an Outgoing- 3922 Call-Reply is received, the call is in progress and the session 3923 moves to the wait-connect state. 3925 wait-connect 3926 If a Call-Disconnect-Notify is received, the call failed; the 3927 session is cleaned up and returns to idle. If an Outgoing-Call- 3928 Connected is received, the call has succeeded and the session may 3929 now exchange data. 3931 established 3932 If a Call-Disconnect-Notify is received, the call has been 3933 terminated for the reason indicated in the Result and Cause Codes; 3934 the session moves back to the idle state. If the LNS chooses to 3935 terminate the session, it sends a Call-Disconnect-Notify to the 3936 LAC and then cleans up and idles its session. 3938 7.6 Tunnel Disconnection 3940 The disconnection of a tunnel consists of either peer issuing a 3941 Stop-Control-Connection-Notification. The sender of this 3942 Notification should wait a finite period of time for the 3943 acknowledgment of this message before releasing the control 3944 information associated with the tunnel. The recipient of this 3945 Notification should send an acknowledgment of the Notification and 3946 then release the associated control information. 3948 When to release a tunnel is an implementation issue and is not 3949 specified in this document. A particular implementation may use 3950 whatever policy is appropriate for determining when to release a 3951 control connection. Some implementations may leave a tunnel open for 3952 a period of time or perhaps indefinitely after the last user session 3953 for that tunnel is cleared. Others may choose to disconnect the 3954 tunnel immediately after the last user connection on the tunnel 3955 disconnects. 3957 8.0 L2TP Over Specific Media 3959 L2TP tries to be self-describing, operating at a level above the 3960 particular media over which it is carried. However, some details of 3961 its connection to media are required to permit interoperable 3962 implementations. The following sections describe details needed to 3963 permit interoperability over specific media. 3965 8.1 IP/UDP 3967 L2TP uses the well-known UDP port 1701 [3]. The entire L2TP packet, 3968 including payload and L2TP header, is sent within a UDP datagram. 3969 The initiator of an L2TP tunnel picks an available source UDP port, 3970 and sends to the desired destination at port 1701. The recipient 3971 picks a free port on its own system (which may or may not be 1701), 3972 and sends its reply to the initiator's UDP port, setting its own UDP 3973 source port set to the free port it found. 3975 It is legal for a peer's IP address and/or UDP port used for a given 3976 tunnel to change over the life of a connection; this may correspond 3977 to a peer with multiple IP interfaces responding to a network 3978 topology change. Responses should reflect the last source IP address 3979 and UDP port for that Tunnel ID. 3981 IP fragmentation may occur as the L2TP packet travels over the IP 3982 substrate. L2TP makes no special efforts to optimize this. A LAC 3983 implementation MAY cause its LCP to negotiate for a specific MRU, 3984 which could optimize for LAC environments in which the MTUs of the 3985 path over which the L2TP packets are likely to travel have a 3986 consistent value. 3988 The default for any L2TP implementation is that UDP checksums MUST be 3989 enabled for both control and payload messages. An L2TP 3990 implementation MAY provide an option to disable UDP checksums for 3991 payload packets. It is recommended that UDP checksums always be 3992 enabled on control packets. 3994 Port 1701 is used for both L2F [5] and L2TP packets. The two types 3995 of packets may be detected by their headers; L2TP has a Vers field of 3996 2, L2F has a Vers field of 1. An L2TP implementation running on a 3997 system which does not support L2F MUST silently discard all packets 3998 whose Vers field is set to 1. 4000 To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP media 4001 has the characteristics of being able to reorder or silently drop 4002 packets. The former may break non-IP protocols being carried by PPP, 4003 especially LAN-centric ones such as bridging. The latter may break 4004 protocols which assume per-packet indication of error, such as TCP 4005 header compression. The former may be handled by using L2TP payload 4006 sequence numbers if any PPP protocol is used which cannot tolerate 4007 reordering. 4009 The latter characteristic of silently dropping packets is perhaps 4010 more problematic. If RFC 1663 reliable delivery [10] is enabled, no 4011 upper PPP protocol will encounter lost packets. If L2TP sequence 4012 numbers are enabled, L2TP can detect the packet loss. In the case of 4013 an LNS, the PPP and L2TP stacks are both present within the LNS, and 4014 packet loss signaling may occur precisely as if a packet was received 4015 with a CRC error. Where the LAC and PPP stack are co-resident, this 4016 technique also applies. Where the LAC and PPP client are physically 4017 distinct, the analogous signaling MAY be accomplished by sending a 4018 packet with a CRC error to the PPP client. Note that this would 4019 greatly increase the complexity of debugging client line problems, 4020 since the client statistics can not distinguish between true media 4021 errors and LAC-initiated ones. This technique is also not possible 4022 on all hardware. 4024 If neither RFC 1663 nor sequence numbers are enabled, each lost 4025 packet results in a 1 in 2**16 chance of a TCP segment being 4026 forwarded with incorrect contents [11]. Where the combination of the 4027 packet loss rate with this statistical exposure is unacceptable, TCP 4028 header compression SHOULD NOT be used in this configuration. 4030 In general, it is wise to remember that the L2TP/UDP/IP transport is 4031 an unreliable transport. As with any PPP media which is subject to 4032 loss, care should be taken when using protocols which are 4033 particularly sensitive this. Such protocols might include stateful 4034 compression or encryption protocols. 4036 8.2 IP 4038 When operating in IP environments, L2TP MUST offer the UDP 4039 encapsulation described in 8.1 as its default configuration for IP 4040 operation. Other configurations (perhaps corresponding to a 4041 compressed header format) may be defined, and made available as a 4042 configurable option. 4044 9.0 Security Considerations 4046 L2TP encounters several security issues in its operation. The 4047 general approach of L2TP to these issues is documented here. 4049 9.1 Tunnel Endpoint Security 4051 The tunnel endpoints may authenticate each other during tunnel 4052 establishment. This authentication has the same security 4053 attributes as CHAP, and has reasonable protection against replay 4054 and snooping during the tunnel establishment process. This 4055 mechanism is not designed to provide any authentication beyond 4056 tunnel establishment; it is fairly simple for a malicious user who 4057 can snoop and inject packets to hijack a tunnel once an 4058 authenticated tunnel establishment has been completed 4059 successfully. In environments where some L2TP peers will be 4060 authenticated, but others not, a mechanism should be provided to 4061 control when tunnel endpoint authentication will be active. 4063 The LAC and LNS MUST share a single secret for authentication of 4064 both ends of the tunnel. Each side uses this same secret when 4065 acting as authenticatee as well as authenticator. Since a single 4066 secret it used, the tunnel authentication AVPs include 4067 differentiating values in the CHAP ID fields for each message 4068 digest calculation to guard against replay attacks. 4070 For L2TP tunnels over IP, IP-level packet security provides very 4071 strong protection of the tunnel. This requires no modification to 4072 the L2TP protocol, and leverages extensive IETF work in this area. 4074 For L2TP tunnels over Frame Relay or other switched networks, 4075 current practice indicates that these media are much less likely 4076 to experience attacks of in-transit data. If these attacks become 4077 prevalent, either the media or the L2TP packets would have to be 4078 encrypted or authenticated. 4080 Because the shared secret used for endpoint authentication is the 4081 same shared secret used to obscure AVP contents using the H 4082 (Hidden) bit, tunnel authentication must be used in all cases 4083 where the H bit will be used. Proxy authentication involving PAP 4084 may be usable without the H bit if PAP is only carrying one-time 4085 passwords; if clear text passwords are carried in the proxy 4086 authentication, the H bit (and, by implication, tunnel 4087 authentication) should be used. 4089 To protect against exhaustive attack during tunnel authentication, 4090 no tunnel authentication response should ever be accepted if it 4091 corresponds to a challenge more than one minute old. 4093 9.2 Client Security 4095 A more systematic method of protection in tunneled PPP 4096 environments may be achieved through client security. PPP layer 4097 encryption would provide end-to-end security for both direct 4098 dial-in clients as well as PPP clients carried within a tunnel. 4099 With this level of client security, sessions are protected against 4100 attacks against the carrying tunnel, as well as attacks on the LAC 4101 itself. Because both encryption and compression can occur at the 4102 PPP layer, the two can be coordinated, permitting compression to 4103 precede encryption. 4105 9.3 Proxy Authentication 4107 The optional proxy CHAP function of L2TP can permit an entirely 4108 transparent PPP tunnel, with a single LCP and CHAP sequence being 4109 seen by the client. For cases where the LAC and the entire path 4110 to the LNS are operated by a single entity, this function may 4111 provide acceptable security. For cases where LNS-initiated 4112 authentication is required, proxy CHAP still permits an initial 4113 access decision to be made before accepting the tunnel, permitting 4114 the LNS in most cases to reject tunnel initiations rather than 4115 accept them and later disconnect. 4117 The optional proxy PAP may result in the cleartext password 4118 traversing the tunnel. Where PAP is being used in conjunction 4119 with static passwords, this may pose a significant security issue. 4120 Where PAP is only used to transport one-time passwords, such 4121 issues may be greatly mitigated. The H bit of the carrying AVP 4122 may be used to protect against this. 4124 All implementations MUST accept proxy authentication AVP's, but 4125 are free to silently discard them and initiate an entirely new 4126 authentication with the PPP client. 4128 10.0 Acknowledgments 4130 The AVP construct comes from Glen Zorn, who thought up the framework 4131 for permitting multiple vendors to contribute to a common attribute 4132 space in a relatively orderly fashion. 4134 Dory Leifer of Ascend Communications made valuable refinements to the 4135 protocol definition of L2TP and contributed to the editing of this 4136 document. 4138 Steve Cobb and Evan Caves redesigned the state machine tables. 4140 Barney Wolff provided a great deal of design input on the endpoint 4141 authentication mechanism. 4143 11.0 Contacts 4145 Kory Hamzeh, Allan Rubens 4146 Ascend Communications 4147 1275 Harbor Bay Parkway 4148 Alameda, CA 94502 4149 kory@ascend.com 4150 acr@del.com 4152 Tim Kolar, Morgan Littlewood, Bill Palter, Andrew J. Valencia 4153 Cisco Systems 4154 170 West Tasman Drive 4155 San Jose CA 95134-1706 4156 tkolar@cisco.com 4157 littlewo@cisco.com 4158 palter@zev.net 4159 vandys@cisco.com 4161 W. Mark Townsley 4162 Cisco Systems 4163 7025 Kit Creek Road 4164 PO Box 14987 4165 Research Triangle Park, NC 27709 4166 townsley@cisco.com 4168 Gurdeep Singh Pall 4169 Microsoft Corporation 4170 Redmond, WA 4171 gurdeep@microsoft.com 4173 Jeff Taarud 4174 Copper Mountain Networks 4175 jtaarud@coppermountain.com 4177 William Verthein 4178 3COM Corporation 4179 wverthei@usr.com 4181 12.0 References 4183 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 4184 07/21/1994 4186 [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet 4187 draft, April 1996 4189 [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point 4190 Tunneling Protocol", Internet draft, June 1996 4192 [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC1034, 4193 November 1987 4195 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, 4196 USC/Information Sciences Institute, July 1992. 4198 [6] Sally Floyd, Van Jacobson, "Random Early Detection Gateways for 4199 Congestion Avoidance", IEEE/ACM Transactions on Networking, 4200 August 1993 4202 [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, 4203 October 1996 4205 [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens, "Remote Authentication 4206 Dial In User Service (RADIUS)." RFC 2058, January 1997. 4208 [9] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, RFC 1990, 4209 "The PPP Multilink Protocol (MP)", August 1996. 4211 [10] D. Rand, "PPP Reliable Transmission", RFC 1663, July, 1994 4213 [11] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links", 4214 RFC 1144, February, 1990 4216 [12] "SMI Network Management Private Enterprise Codes", 4217 ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers 4219 [13] G. Zorn, D. Leifer, A. Rubens, J. Shriver, "RADIUS Attributes for 4220 Tunnel Protocol Support," draft-ietf-radius-tunnel-auth-04.txt, 4221 November 1997 4223 Appendix A: Acknowledgment Timeouts 4225 L2TP uses sliding windows and timeouts to provide session and control 4226 flow-control across the underlying medium (which may be an 4227 internetwork) and to perform efficient data buffering to keep the 4228 LAC-LNS data channels full without causing receive buffer overflow. 4229 L2TP requires that a timeout be used to recover from dropped data or 4230 acknowledgment packets for both control and data messages. The only 4231 real difference between the flow-control mechanism used for the two 4232 message types is that control messages are retransmitted upon 4233 expiration of the acknowledgment timeout in order to assure reliable 4234 transport while payload messages are never retransmitted. Because 4235 payload messages are not retransmitted, the action taken upon 4236 expiration of the acknowledgment timeout for each message type also 4237 differs. 4239 When the timeout for a control session expires the previously 4240 transmitted control message with Ns value equal to the highest in- 4241 sequence value of Nr received from the peer is retransmitted. The 4242 receiving peer does not advance its value for the receive sequence 4243 number state, Sr, for either a control session or payload session 4244 until it receives a message with Ns equal to its current value of Sr 4245 (except for the simple receiver described in Appendix C and payload 4246 packets with the R-bit set). This rule assures that all subsequent 4247 acknowledgments for this session will contain an Nr value equal to 4248 the Ns value of the first missing message until a message with the 4249 missing Ns value is received. This rule also assures that when a 4250 payload message is lost anywhere within the current transmit window, 4251 the payload session acknowledgment timeout will expire, allowing the 4252 transmitter to adjust transmission parameters such as those suggested 4253 in this appendix. 4255 According to the above rule for updating of the receiving peer's Sr 4256 value, the loss of a transmitted payload message (due to non- 4257 retransmission of payload messages) will cause Sr to remain at the 4258 value of the first lost payload message. In order to cause the 4259 receiving peer to advance its value of Sr beyond that of a lost 4260 message's Ns value, upon expiration of a payload session 4261 acknowledgment timeout, the sending peer MUST transmit a payload 4262 message with R-bit set and Ns value greater than or equal to Ns of 4263 the lost message. Refer to Section 4 for more details on the use of 4264 the R-bit. 4266 The exact implementation of the acknowledgment timeout is vendor- 4267 specific. It is suggested that an adaptive timeout be implemented 4268 with backoff for congestion control. The timeout mechanism proposed 4269 here has the following properties: 4271 Independent timeouts for each session. A device (LAC or LNS) will 4272 have to maintain and calculate timeouts for every active session. 4274 An administrator-adjustable maximum timeout, MaxTimeOut, unique to 4275 each device. 4277 An adaptive timeout mechanism that compensates for changing 4278 throughput. To reduce packet processing overhead, vendors may 4279 choose not to recompute the adaptive timeout for every received 4280 acknowledgment. The result of this overhead reduction is that the 4281 timeout will not respond as quickly to rapid network changes. 4283 Timer backoff on timeout to reduce congestion. The backed-off 4284 timer value is limited by the configurable maximum timeout value. 4285 Timer backoff is done every time an acknowledgment timeout occurs. 4287 In general, this mechanism has the desirable behavior of quickly 4288 backing off upon a timeout and of slowly decreasing the timeout value 4289 as packets are delivered without timeouts. 4291 Some definitions: 4293 Packet Processing Delay, "PPD", is the amount of time required for 4294 each peer to process the maximum amount of data buffered in its 4295 offered receive packet window. The PPD is the value exchanged 4296 between the LAC and LNS when a call is established. For the LNS, 4297 this number should be small. For an LAC supporting modem 4298 connections, this number could be significant. 4300 "Sample" is the actual amount of time incurred receiving an 4301 acknowledgment for a packet. The Sample is measured, not 4302 calculated. 4304 Round-Trip Time, "RTT", is the estimated round-trip time for an 4305 Acknowledgment to be received for a given transmitted packet. 4306 When the network link is a local network, this delay will be 4307 minimal (if not zero). When the network link is the Internet, 4308 this delay could be substantial and vary widely. RTT is adaptive: 4309 it will adjust to include the PPD and whatever shifting network 4310 delays contribute to the time between a packet being transmitted 4311 and receiving its acknowledgment. 4313 Adaptive Timeout, "ATO", is the time that must elapse before an 4314 acknowledgment is considered lost. After a timeout, the sliding 4315 window is partially closed and the ATO is backed off. 4317 Packet Processing Delay (PPD) 4319 The PPD parameter is a 16-bit time value exchanged during the Call 4320 Control phase expressed in units of tenths of a second (64 means 6.4 4321 seconds). The protocol only specifies that the parameter is 4322 exchanged, it does not specify how it is calculated. The way values 4323 for ATO are calculated is implementation-dependent and need not be 4324 variable (static timeouts are allowed). If adaptive timeouts are to 4325 be used then the PPD should be exchanged in the call connect 4326 sequences. A possible way to calculate the PPD is: 4328 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 4329 + LACFudge (for an LAC) 4330 or 4331 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4332 + LNSFudge (for an LNS) 4334 Header is the total size of the L2TP and media dependent headers. 4335 MTU is the overall MTU for the link between the LAC and LNS. 4336 WindowSize represents the number of packets in the sliding window, 4337 and is implementation-dependent. The latency of the underlying 4338 connection path between the LAC and LNS could be used to pick a 4339 window size sufficient to keep the current session's pipe full. The 4340 constant 8 converts octets to bits (assuming ConnectRate is in bits 4341 per second). LACFudge and LNSFudge are not required but can be used 4342 to take overall processing overhead of the LAC or LNS into account. 4344 In the case of the computed PPD for an LNS, AvePathRate is the 4345 average bit rate of the path between the LNS and LAC. Given that 4346 this number is probably very large and WindowSize is relatively 4347 small, LNSFudge will be the dominant factor in the computation of 4348 PPD. It is recommended that the minimum value of PPD be on the order 4349 of 0.5 second. 4351 The value of PPD is used to seed the adaptive algorithm with the 4352 initial RTT[n-1] value. 4354 A.1 Calculating Adaptive Acknowledgment Timeout 4356 We still must decide how much time to allow for acknowledgments to 4357 return. If the timeout is set too high, we may wait an unnecessarily 4358 long time for dropped packets. If the timeout is too short, we may 4359 time out just before the acknowledgment arrives. The acknowledgment 4360 timeout should also be reasonable and responsive to changing network 4361 conditions. 4363 The suggested adaptive algorithm detailed below is based on the TCP 4364 1989 implementation and is explained in Richard Steven's book TCP/IP 4365 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 4366 calculation, and 'n-1' refers to values from the last calculation. 4368 DIFF[n] = SAMPLE[n] - RTT[n-1] 4369 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 4370 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 4371 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 4373 DIFF represents the error between the last estimated round-trip 4374 time and the measured time. DIFF is calculated on each iteration. 4376 DEV is the estimated mean deviation. This approximates the 4377 standard deviation. DEV is calculated on each iteration and 4378 stored for use in the next iteration. Initially, it is set to 0. 4380 RTT is the estimated round-trip time of an average packet. RTT is 4381 calculated on each iteration and stored for use in the next 4382 iteration. Initially, it is set to PPD. 4384 ATO is the adaptive timeout for the next transmitted packet. ATO 4385 is calculated on each iteration. Its value is limited, by the MIN 4386 function, to be a maximum of the configured MaxTimeOut value. 4388 Alpha is the gain for the round trip estimate error and is 4389 typically 1/8 (0.125). 4391 Beta is the gain for the deviation and is typically 1/4 (0.250). 4393 Chi is the gain for the timeout and is typically set to 4. 4395 To eliminate division operations for fractional gain elements, the 4396 entire set of equations can be scaled. With the suggested gain 4397 constants, they should be scaled by 8 to eliminate all division. To 4398 simplify calculations, all gain values are kept to powers of two so 4399 that shift operations can be used in place of multiplication or 4400 division. The above calculations are carried out each time an 4401 acknowledgment is received for a packet that was not retransmitted 4402 (no timeout occurs). 4404 A.2 Congestion Control: Adjusting for Timeout 4406 This section describes how the calculation of ATO is modified in the 4407 case where a timeout does occur. When a timeout occurs, the timeout 4408 value should be adjusted rapidly upward. Although L2TP payload 4409 packets are not retransmitted when a timeout occurs, the timeout 4410 should be adjusted up toward a maximum limit. To compensate for 4411 shifting internetwork time delays, a strategy must be employed to 4412 increase the timeout when it expires. A simple formula called Karn's 4413 Algorithm is used in TCP implementations and may be used in 4414 implementing the backoff timers for the LNS or the LAC. Notice that 4415 in addition to increasing the timeout, we also shrink the size of the 4416 window as described in the next section. 4418 Karn's timer backoff algorithm, as used in TCP, is: 4420 NewTIMEOUT = delta * TIMEOUT 4422 Adapted to our timeout calculations, for an interval in which a 4423 timeout occurs, the new timeout interval ATO is calculated as: 4425 RTT[n] = delta * RTT[n-1] 4426 DEV[n] = DEV[n-1] 4427 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 4429 In this modified calculation of ATO, only the two values that 4430 contribute to ATO and that are stored for the next iteration are 4431 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 4432 not carried forward and is not used in this scenario. A value of 2 4433 for Delta, the timeout gain factor for RTT, is suggested. 4435 Appendix B: Acknowledgment Timeout and Window Adjustment 4437 B.1 Initial Window Size 4439 Although each side has indicated the maximum size of its receive 4440 window, it is recommended that a slow start method be used to begin 4441 transmitting data. The initial maximum window size on the 4442 transmitter is set to half the maximum size the receiver requested, 4443 with a minimum size of one packet. The transmitter stops sending 4444 packets when the number of packets awaiting acknowledgment is equal 4445 to the current maximum window size. As the receiver successfully 4446 digests each window, the maximum window size on the transmitter is 4447 bumped up by one packet until the maximum specified by the receiver 4448 is reached. This method prevents a system from flooding an already 4449 congested network because no history has been established. 4451 When for any reason an LAC or LNS receives more data than it can 4452 queue for the tunnel, a packet must be discarded. In this case, it 4453 is recommended that a "random early discard" algorithm [6] be used 4454 rather than the obvious "drop last" algorithm. 4456 B.2 Closing the Window 4458 When a timeout does occur on a packet, the sender adjusts the size of 4459 the transmit window down to one half its maximum value when it 4460 failed. Fractions are rounded up, and the minimum window size is 4461 one. 4463 B.3 Opening the Window 4465 With every successful transmission of a window's worth of packets 4466 without a timeout, the maximum transmit window size is increased by 4467 one packet until it reaches the maximum window size that was sent by 4468 its peer when the call was connected. As stated earlier, no 4469 retransmission is done on a timeout. After a timeout, transmission 4470 resumes with the maximum transmit window starting at one half the 4471 size of the maximum transmit window when the timeout occurred (with a 4472 minimum window size of 1) and adjusting upward by one each time the 4473 current maximum transmit window is filled with packets that are all 4474 acknowledged without timeouts. 4476 B.4 Window Overflow 4478 When a receiver's window overflows with too many incoming packets, 4479 excess packets are thrown away. This situation should not arise if 4480 the sliding window procedures are being properly followed by the 4481 transmitter and receiver. It is assumed that, on the transmit side, 4482 packets are buffered for transmission and are no longer accepted from 4483 the packet source when the transmit buffer fills. 4485 Appendix C: Handling of out-of-order packets 4487 When the Sequence Number and Acknowledgment Number fields are present 4488 in payload packets, they are used to manage packet rate. In 4489 addition, they may be used to handle out-of-order arrival of packets. 4490 A simple L2TP receiver may choose to skip the test for the Ns value 4491 of a received message being equal to Sr, simply updating Sr if Ns is 4492 greater than the current value of Sr. For example, if packets 1, 2, 4493 3 arrived as 1, 3, 2, this simple implementation would silently 4494 discard packet 2 without informing the sender in any way that packet 4495 2 was discarded. Even though packet 2 is dropped by the receiver, the 4496 transmitter will perceive all transmitted packets as being received 4497 without loss by its peer. 4499 Such behavior does not affect the L2TP protocol itself, but 4500 significantly improved throughput in such environments may be 4501 attained by queueing and reordering packets when they arrive out of 4502 order. The number of packets to be queued is a function of memory 4503 resources on the L2TP implementation, but should never be more than 4504 1/4 of the total sequence number space (i.e., 16384 packets), to 4505 avoid the possibility of sequence number aliasing. 4507 It is suggested that receiving peer implementations implement the Sr 4508 state variable for payload sessions and that they update Sr only when 4509 receiving the next in-sequence Ns value or when receiving a message 4510 with the R-bit set. Doing so allows a mechanism for reporting of lost 4511 payload messages to the transmitter, which is necessary for the 4512 transmitter to implement algorithms such as those suggested in 4513 Appendix A and B. 4515 Note that while payload messages received out-of-order may either be 4516 queued, discarded, or delivered out-of-order, queueing is preferred. 4517 PPP does not expect to receive packets out-of-order so, if queueing 4518 is not provided by a receiver, it is preferable for it to discard 4519 out-of-order packets rather than deliver them to PPP. 4521 Appendix D: Transport Layer Adaptive Timeouts and Window Adjustment 4523 Appendixes A, B, and C deal primarily with operation of the payload 4524 packet sessions of L2TP. This Appendix explains how these three 4525 algorithms pertain to the transport layer for L2TP control sessions. 4526 Appendix B, Time-out Window Management, directly applies to the 4527 Transport Layer except in the case where a window size of 1 is being 4528 used. Appendix C, does not really apply because, for the Control 4529 Session, control messages MUST always be processed by the receiver in 4530 order. Also, there are no lost control packets because they are 4531 retransmitted by the L2TP Transport Layer. Thus, the main topic of 4532 this Appendix is how to adapt the example adaptive timeout algorithm 4533 of Appendix A to the Control Session Transport Layer. 4535 There are two main differences between the Control Session and 4536 payload sessions: 1) Unlike lost payload packets, lost control 4537 messages are retransmitted and 2) There is no Packet Processing Delay 4538 value provided in the control session setup messages. The latter 4539 affects the manner in which the initial value of the RTT estimate is 4540 determined. The former really doesn't affect the algorithm at all, 4541 except that upon a timeout, retransmission of unacknowledged control 4542 messages should be attempted, up to the number that fit in the 4543 sliding window with size computed as in Appendix B. 4545 Using the symbol definitions of Appendix A, the calculation of the 4546 value for the PPD of the remote peer can be estimated as: 4548 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4549 + Fudge 4551 This is simply the number of bits in a full control session window 4552 divided by the average speed of the path between the LAC and LNS with 4553 a fudge factor added on to make it work. In cases where the average 4554 rate of the connection between LAC and LNS isn't known, it is 4555 suggested that some value be configured that is associated with each 4556 possible peer. Because Control Session windows will most likely be 4557 small and the connection speed will be quite high, fudge will be the 4558 dominant factor in this calculation. For this reason, just 4559 configuring a single fixed initial PPD estimate to be used for all 4560 possible peers will probably provide adequate results. This fudge 4561 factor should be at least 0.5 second. 4563 Appendix E: Examples of L2TP sequence numbering 4565 Although sequence numbers serve distinct purposes for control and 4566 data messages, both types of messages use identical techniques for 4567 assigning sequence numbers. This appendix shows several common 4568 scenarios, and illustrates how sequence number state progresses and 4569 is interpreted. 4571 E.1: Lock-step tunnel establishment 4573 In this example, an LAC establishes a tunnel, with the exchange 4574 involving each side alternating in sending messages. This example 4575 is contrived, in that the final acknowledgment in the example is 4576 explicitly sent within a zero-length message, although most 4577 typically the acknowledgment would have been included in the 4578 processing of the Incoming-Call-Request which had prompted the LAC 4579 to initiate the tunnel in the first place. 4581 LAC LNS 4582 -> Start-Control-Connection-Request 4583 Nr: 0, Ns: 0 4585 Start-Control-Connection-Reply <- 4586 Nr: 1, Ns: 0 4588 -> Start-Control-Connection-Connected 4589 Nr: 1, Ns: 1 4591 (delay) 4592 (zero-length) <- 4593 Nr: 2, Ns: 1 4595 E.2: Multiple packets acknowledged 4597 This example shows a flow of payload packets from the LNS to the 4598 LAC, with the LAC having no traffic of its own. The LAC is 4599 waiting 1/4 of its timeout interval, and then acknowledging all 4600 packets seen since the last interval. 4602 (previous packet flow precedes this) 4604 LAC LNS 4605 -> (zero-length) 4606 Nr: 7000, Ns: 1000 4607 (payload) <- 4608 Nr: 1000, Ns: 7000 4609 (payload) <- 4610 Nr: 1000, Ns: 7001 4611 (payload) <- 4612 Nr: 1000, Ns: 7002 4614 (LAC's timer indicates it should acknowledge pending traffic) 4616 -> (zero-length) 4617 Nr: 7003, Ns: 1000 4619 E.3: Lost packet with retransmission 4621 An existing tunnel has a new session requested by the LAC. The 4622 Incoming-Call-Reply is lost and must be retransmitted by the LNS. 4623 This example continues from the sequence state reached at the end 4624 of example E.1. Note that loss of the -Reply has two impacts: not 4625 only does it keep the upper level state machine from progressive, 4626 but it also keeps the LAC from seeing a timely lower level 4627 acknowledgment of its -Request packet. 4629 LAC LNS 4630 -> Incoming-Call-Request 4631 Nr: 1, Ns: 2 4633 (packet lost) Incoming-Call-Reply <- 4634 Nr: 3, Ns: 1 4636 (pause; LAC's timer started first, so fires first) 4638 -> Incoming-Call-Request 4639 Nr: 1, Ns: 2 4641 (LNS realizes it has already seen this packet) 4642 (LNS might use this as a cue to retransmit, as in this example) 4644 Incoming-Call-Reply <- 4645 Nr: 3, Ns: 1 4647 -> Incoming-Call-Connected 4648 Nr: 2, Ns: 3 4650 (delay) 4652 (zero-length) <- 4653 Nr: 4, Ns: 2 4655 E.4: Lost payload packet with ZLB congestion control 4657 In this example, a packet sent from Peer A to Peer B is lost. Peer 4658 B's receive window is 4, so after Peer A realizes that it has 4659 filled Peer B's window, it waits. After timing out, Peer A sends a 4660 ZLB with the R-bit set to reset Peer B, telling it to give up on 4661 3001. If performing window adjustment, Peer A should now reduce 4662 its effective transmit window size until a full window is digested 4663 by Peer B. 4665 Peer A Peer B (RW=4) 4666 -> Payload Packet 4667 Nr: 7000, Ns: 3000 4669 Payload Packet <- 4670 Nr: 3001, Ns: 7000 4672 -> Payload packet (packet lost) 4673 Nr: 7001, Ns: 3001 4675 Payload Packet <- 4676 Nr: 3001, Ns: 7001 4678 -> Payload packet 4679 Nr: 7002, Ns: 3002 4680 -> Payload packet 4681 Nr: 7002, Ns: 3003 4682 -> Payload packet 4683 Nr: 7002, Ns: 3004 4685 (window full, waiting) 4687 -> Timeout, send ZLB w/R-bit set 4688 Nr: 7002 Ns: 3001 4690 Payload Packet <- 4691 Nr: 3005 Ns: 7002 4693 E.5: Lost payload packet with piggyback congestion control 4695 In this example, two packets sent from Peer A to Peer B are lost. 4696 Peer B's receive window is 4, so after Peer A realizes that it has 4697 filled Peer B's window, it waits. After timing out, Peer A sends a 4698 payload packet with the R-bit set to reset Peer B, telling it to 4699 give up on 3001 and 3002. If performing window adjustment, Peer A 4700 should now reduce its effective transmit window size until a full 4701 window is digested by Peer B. Note that in this scenerio Peer A 4702 has no way of knowing that more than one packet was lost. 4704 Peer A Peer B (RW=4) 4705 -> Payload Packet 4706 Nr: 7000, Ns: 3000 4708 Payload Packet <- 4709 Nr: 3001, Ns: 7000 4711 -> Payload packet (packet lost) 4712 Nr: 7001, Ns: 3001 4713 -> Payload packet (packet lost) 4714 Nr: 7001, Ns: 3002 4716 Payload Packet <- 4717 Nr: 3001, Ns: 7001 4719 -> Payload packet 4720 Nr: 7002, Ns: 3003 4721 -> Payload packet 4722 Nr: 7002, Ns: 3004 4724 (window full, waiting) 4726 -> Timeout, send Payload w/R-bit set 4727 Nr: 7002 Ns: 3005 4729 Payload Packet <- 4730 Nr: 3006 Ns: 7002 4732 ~