idnits 2.17.1 draft-ietf-pppext-l2tp-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 92 longer pages, the longest (page 1) being 63 lines 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 30 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1477 has weird spacing: '...ng with each ...' == Line 3765 has weird spacing: '...e local wai...' == Line 3766 has weird spacing: '...ndicate tunne...' == Line 3935 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: 'LNS' on line 347 -- Looks like a reference, but probably isn't: 'R' on line 356 -- Looks like a reference, but probably isn't: 'User' on line 360 -- 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: 14 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group A. Valencia 3 INTERNET DRAFT Cisco Systems 4 Category: Internet Draft K. Hamzeh, A. Rubens 5 Title: draft-ietf-pppext-l2tp-10.txt Ascend Communications 6 Date: March 1998 T. Kolar, M. Littlewood 7 W. M. Townsley 8 Cisco Systems 9 J. Taarud 10 Copper Mountain Networks 11 G. S. Pall 12 Microsoft Corporation 13 B. Palter 14 Network Alchemy 15 W. Verthein 16 3COM Corporation 18 Layer Two Tunneling Protocol "L2TP" 20 Status of this Memo 22 This document is an Internet-Draft. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months. Internet-Drafts may be updated, replaced, or obsoleted by 29 other documents at any time. It is not appropriate to use Internet- 30 Drafts as reference material or to cite them other than as a 31 ``working draft'' or ``work in progress.'' 33 To view the entire list of current Internet-Drafts, please check 34 the "1id-abstracts.txt" listing contained in the Internet-Drafts 35 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 36 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 37 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 38 (US West Coast). 40 Abstract 42 Virtual dial-up allows many separate and autonomous protocol domains 43 to share common access infrastructure including modems, Access 44 Servers, and ISDN routers. RFC 1661 specifies multi-protocol dial-up 45 via PPP [1]. This document describes the Layer Two Tunneling 46 Protocol (L2TP) which permits the tunneling of the link layer (i.e., 47 HDLC, async HDLC) of PPP. Using such tunnels, it is possible to 48 divorce the location of the initial dial-up server from the location 49 at which the dial-up protocol connection is terminated and access to 50 the network provided. 52 Table of Contents 54 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.0 Problem Space Overview . . . . . . . . . . . . . . . . . . 6 58 2.1 Initial Assumptions . . . . . . . . . . . . . . . . . . . 6 59 2.2 Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.3 Providing Virtual Dial-up Services--a walk-through . . . . 7 61 3.0 Service Model Issues . . . . . . . . . . . . . . . . . . . 9 62 3.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.2 Address Allocation . . . . . . . . . . . . . . . . . . . . 10 64 3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 10 65 3.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.0 Protocol Overview . . . . . . . . . . . . . . . . . . . . 11 67 4.1 Control Message Overview . . . . . . . . . . . . . . . . . 13 68 4.2 Payload Packet Overview . . . . . . . . . . . . . . . . . 14 69 4.3 Congestion Control . . . . . . . . . . . . . . . . . . . . 16 70 5.0 Message Format and Protocol Extensibility . . . . . . . . 18 71 5.1 AVP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 5.2 Control Message Format . . . . . . . . . . . . . . . . . . 20 73 5.3 Payload Message Format . . . . . . . . . . . . . . . . . . 21 74 5.4 Control Message Types . . . . . . . . . . . . . . . . . . 22 75 5.5 AVP Summary . . . . . . . . . . . . . . . . . . . . . . . 23 76 5.6 Result and Error Code Summary . . . . . . . . . . . . . . 26 77 5.7 Hiding of AVP values . . . . . . . . . . . . . . . . . . . 27 78 6.0 Control Connection Protocol Specification . . . . . . . . 29 79 6.0.1 Control Connection Collision . . . . . . . . . . . . . . 29 80 6.0.2 Reliable Delivery of Control Messages . . . . . . . . . 30 81 6.0.3 Control Message Format . . . . . . . . . . . . . . . . . 31 82 6.1 Start-Control-Connection-Request . . . . . . . . . . . . . 31 83 6.2 Start-Control-Connection-Reply . . . . . . . . . . . . . . 36 84 6.3 Start-Control-Connection-Connected . . . . . . . . . . . . 41 85 6.4 Stop-Control-Connection-Notification . . . . . . . . . . . 42 86 6.5 Hello . . . . . . . . . . . . . . . . . . . . . . . . . . 43 87 6.6 Outgoing-Call-Request . . . . . . . . . . . . . . . . . . 44 88 6.7 Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . 49 89 6.8 Outgoing-Call-Connected . . . . . . . . . . . . . . . . . 50 90 6.9 Incoming-Call-Request . . . . . . . . . . . . . . . . . . 53 91 6.10 Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 57 92 6.11 Incoming-Call-Connected . . . . . . . . . . . . . . . . . 58 93 6.12 Call-Disconnect-Notify . . . . . . . . . . . . . . . . . 65 94 6.13 WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . 67 95 6.14 Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 68 96 7.0 Control Connection State Machines . . . . . . . . . . . . 69 97 7.1 Control Connection Protocol Operation . . . . . . . . . . 70 98 7.2 Control Connection States . . . . . . . . . . . . . . . . 70 99 7.2.1 Control Connection Establishment . . . . . . . . . . . . 70 100 7.3 Timing considerations . . . . . . . . . . . . . . . . . . 72 101 7.4 Incoming Calls . . . . . . . . . . . . . . . . . . . . . . 72 102 7.4.1 LAC Incoming Call States . . . . . . . . . . . . . . . . 72 103 7.4.2 LNS Incoming Call States . . . . . . . . . . . . . . . . 74 104 7.5 Outgoing calls . . . . . . . . . . . . . . . . . . . . . . 74 105 7.5.1 LAC Outgoing Call States . . . . . . . . . . . . . . . . 75 106 7.5.2 LNS Outgoing Call States . . . . . . . . . . . . . . . . 76 107 7.6 Tunnel Disconnection . . . . . . . . . . . . . . . . . . . 77 108 8.0 L2TP Over Specific Media . . . . . . . . . . . . . . . . . 77 109 8.1 IP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 77 110 8.2 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 111 9.0 Security Considerations . . . . . . . . . . . . . . . . . 79 112 9.1 Tunnel Endpoint Security . . . . . . . . . . . . . . . . . 79 113 9.2 Client Security . . . . . . . . . . . . . . . . . . . . . 79 114 9.3 Proxy Authentication . . . . . . . . . . . . . . . . . . . 80 115 10.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 80 116 11.0 Contacts . . . . . . . . . . . . . . . . . . . . . . . . 80 117 12.0 References . . . . . . . . . . . . . . . . . . . . . . . 81 118 Appendix A: Acknowledgment Time-Outs . . . . . . . . . . . . . 82 119 Appendix B: Acknowledgment Time-Out and Window Adjustment . . 86 120 Appendix C: Handling of out-of-order packets . . . . . . . . . 87 121 Appendix D: Transport Layer Adaptive Time-Outs 122 and Window Adjustment . . . . . . . . . . . . . . 88 123 Appendix E: Examples of L2TP sequence numbering . . . . . . . 88 125 1.0 Introduction 127 The traditional dial-up network service on the Internet is for 128 registered IP addresses only. A new class of virtual dial-up 129 application which allows multiple protocols and unregistered IP 130 addresses is also desired on the Internet. Examples of this class of 131 network application are support for privately addressed IP, IPX, and 132 AppleTalk dial-up via PPP across existing Internet infrastructure. 134 The support of these multi-protocol virtual dial-up applications is 135 of significant benefit to end users, enterprises, and Internet 136 Service providers as it allows the sharing of very large investments 137 in access and core infrastructure and allows local calls to be used. 138 It also allows existing investments in non-IP protocol applications 139 to be supported in a secure manner while still leveraging the access 140 infrastructure of the Internet. 142 It is the purpose of this document to identify the issues encountered 143 in integrating multi-protocol dial-up services into an existing 144 Internet Service Provider's Point of Presence (hereafter referred to 145 as ISP and POP, respectively), and to describe the L2TP protocol 146 which permits the leveraging of existing access protocols. 148 This protocol may solve the "multilink hunt-group splitting" problem. 149 Multilink PPP [9], often used to aggregate ISDN B channels, requires 150 that all channels composing a multilink bundle be grouped at a single 151 NAS. Because L2TP makes a PPP session terminate at a location other 152 than the point at which the session was physically received, it can 153 be used to make all channels terminate at a single NAS, allowing 154 multilink operation even when the physical calls are spread across 155 distinct physical NAS's. 157 1.1 Conventions 159 The following language conventions are used in the items of 160 specification in this document: 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [15]. 166 1.2 Terminology 168 Analog Channel 170 A circuit-switched communication path which is intended to carry 171 3.1 kHz audio in each direction. 173 Control Connection 175 A control connection operates in-band over a tunnel to control the 176 establishment, release, and maintenance of sessions and of the 177 tunnel itself. 179 Digital Channel 181 A circuit-switched communication path which is intended to carry 182 digital information in each direction. 184 Call 186 A connection or attempted connection between two terminal 187 endpoints. For example, a telephone call through the PSTN between 188 two modems. (See also: Session). 190 CHAP 192 Challenge Authentication Protocol, a PPP cryptographic 193 challenge/response authentication protocol in which the cleartext 194 password is not passed over the line. 196 CLID 198 Calling Line ID, an indication to the receiver of a call as to the 199 phone number of the caller. 201 Control Messages 203 Control messages are exchanged between LAC and LNS pairs, 204 operating in-band within the tunnel protocol. Control messages 205 govern aspects of the tunnel and sessions within the tunnel. 207 Dial User 209 An end-system or router attached to an on-demand PSTN or ISDN 210 which is either the initiator or recipient of a call. Also 211 referred to as a dial-up or Virtual dial-up client. 213 DNIS 215 Dialed Number Information String, an indication to the receiver of 216 a call as to what phone number the caller used to reach it. 218 EAP 220 Extensible Authentication Protocol, a framework for a family of 221 PPP authentication protocols, including cleartext, 222 challenge/response, and arbitrary dialog sequences. 224 L2TP Access Concentrator (LAC) 226 A device attached to the switched network fabric (e.g. PSTN or 227 ISDN) or co-located with a PPP end system capable of handling the 228 L2TP protocol. The LAC needs only implement the media over which 229 L2TP is to operate to pass traffic to one or more LNS's. It may 230 tunnel any protocol carried within PPP. The LAC is the initiator 231 of incoming calls and the receiver of outgoing calls. 233 L2TP Network Server (LNS) 235 An LNS operates on any platform capable of PPP termination. The 236 LNS handles the server side of the L2TP protocol. Since L2TP 237 relies only on the single media over which L2TP tunnels arrive, 238 the LNS may have only a single LAN or WAN interface, yet still be 239 able to terminate calls arriving at any LAC's full range of PPP 240 interfaces (async, synchronous ISDN, V.120, etc.). The LNS is the 241 initiator of outgoing calls and the receiver of incoming calls. 243 Network Access Server (NAS) 245 A device providing temporary, on-demand network access to users. 246 This access is point-to-point typically using PSTN or ISDN lines. 247 A NAS may also serve as an LAC, LNS or both. 249 PAP 251 Password Authentication Protocol, a simple PPP authentication 252 mechanism in which a cleartext username and password are 253 transmitted to prove identity. 255 POP 257 An Internet Service Provider's Point of Presence. 259 Quality of Service (QOS) 261 A given Quality of Service level is sometimes required for a given 262 user being tunneled between an LNS-LAC pair. For this scenario, a 263 unique L2TP tunnel is created (generally on top of a new SVC) and 264 encapsulated directly on top of the media providing the indicated 265 QOS. 267 Session 269 L2TP is connection-oriented. The LNS and LAC maintain state for 270 each user that is attached to an LAC. A session is created when 271 an end-to-end PPP connection is attempted between a dial user and 272 the LNS, or when an outbound call is initiated. The datagrams 273 related to a session are sent over the tunnel between the LAC and 274 LNS. (See also: Call). 276 Switched Virtual Circuit (SVC) 278 An L2TP-compatible media on top of which L2TP is directly 279 encapsulated. SVC's are dynamically created, permitting tunnel 280 media to be created dynamically in response to desired LNS-LAC 281 connectivity requirements. 283 Tunnel 285 A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP 286 datagrams between the LAC and the LNS; many sessions can be 287 multiplexed over a single tunnel. A control connection operating 288 in-band over the same tunnel controls the establishment, release, 289 and maintenance of sessions and of the tunnel itself. A tunnel is 290 sometimes referred to as a control connection. 292 Zero-Length Body (ZLB) Message 294 A control or payload packet with only an L2TP header, and no 295 control message information or PPP payload. ZLB messages are used 296 for explicitly acknowledging packets on the control or data 297 channel. 299 2.0 Problem Space Overview 301 In this section we describe in high level terms the scope of the 302 problem that will be explored in more detail in later sections. 304 2.1 Initial Assumptions 306 We begin by assuming that Internet access is provided by an ISP and 307 that the ISP wishes to offer services other than traditional 308 registered IP address based services to dial-up users of the network. 310 We also assume that the user of such a service wants all of the 311 security facilities that are available to him or her in a dedicated 312 dial-up configuration. In particular, the end user requires: 314 + End System transparency: Neither the remote end system nor his 315 home site hosts should require any special software to use this 316 service in a secure manner. 318 + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or 319 through other dialogs, for instance, a textual exchange on V.120 320 before starting PPP. This will include TACACS+ [7] and RADIUS [8] 321 solutions as well as support for smart cards and one-time passwords. 322 The authentication should be manageable by the user independently of 323 the ISP. 325 + Addressing should be as manageable as dedicated dial-up solutions. 326 The address should be assigned by the home site and not the ISP. 328 + Authorization should be managed by the home site as it would in a 329 direct dial-up solution. 331 + Accounting should be performed both by the ISP (for billing 332 purposes) and by the user (for charge-back and auditing). 334 2.2 Topology 336 Shown below is a generic Internet with Public switched Telephone 337 Network (PSTN) access (i.e., async PPP via modems) and Integrated 338 Services Digital Network (ISDN) access (i.e., synchronous PPP 339 access). Remote users (either async or ISDN PPP) will access the 340 Home LAN as if they were dialed into the L2TP Network Server (LNS), 341 although their physical dial-up is via the ISP Network Access Server 342 (acting as the LAC). 344 ...----[LAN]----+---[LAN]-----... 345 | 346 | 347 [LNS] 348 | 349 ________|________________________ 350 | | 351 ________|__ ______|________ 352 | | | | 353 | PSTN [R] [R] ISDN | 354 | Cloud | | Cloud [LAC]--[User] 355 | | Internet | | 356 | | [R] | 357 [LAC]____[R] |_____________| 358 | | | 359 | | | 360 [User] |________________________________| 362 2.3 Providing Virtual dial-up Services--a walk-through 364 To motivate the following discussion, this section walks through an 365 example of what might happen when a Virtual dial-up client initiates 366 access. 368 A Network Access Server (NAS) operating as a peer to an LNS is 369 referred to as an L2TP Access Concentrator, or "LAC". 371 The remote user initiates a PPP connection to an ISP via either the 372 PSTN or ISDN. The LAC accepts the connection and the PPP link is 373 established (L2TP also permits the LAC to check with an LNS after 374 call indication prior to accepting the call. This is useful where 375 DNIS or CLID information is available in the incoming call 376 notification). 378 The ISP may now undertake a partial authentication of the end 379 system/user. Only the username field would be interpreted to 380 determine whether the user requires a Virtual dial-up service. It is 381 expected, but not required, that usernames will be structured (e.g. 382 username@company.com). Alternatively, the ISP may maintain a 383 database mapping users to services. In the case of Virtual dial-up, 384 the mapping will name a specific endpoint, the LNS. 386 Alternatively, the ISP may have already determined the target LNS 387 from DNIS. If the LNS is willing to accept tunnel creation without 388 any authentication of the caller, the LAC may tunnel the PPP 389 connection without ever having communicated with the remote user. 391 If a virtual dial-up service is not required, standard access to the 392 Internet may be provided. 394 If no tunnel connection currently exists to the desired LNS, one is 395 initiated. L2TP is designed to be largely insulated from the details 396 of the media over which the tunnel is established; L2TP requires only 397 that the tunnel media provide packet oriented point-to-point 398 connectivity. Obvious examples of such media are UDP, Frame Relay 399 PVC's, or X.25 VC's. 401 Once the tunnel exists, an unused slot within the tunnel, a "Call 402 ID", is allocated, and a connect indication is sent to notify the LNS 403 of this new dial-up session. The LNS either accepts the connection, 404 or rejects it. Rejection MUST include a result condition and MAY 405 include an error indication, which may be displayed to the dial-up 406 user, after which the call should be disconnected. 408 The initial connect notification may include the authentication 409 information required to allow the LNS to authenticate the user and 410 decide to accept or decline the connection. In the case of CHAP, the 411 set-up packet includes the challenge, username and raw response. For 412 PAP or text dialog, it includes username and clear text password. 413 The LNS may choose to use this information to complete its 414 authentication, avoiding an additional cycle of authentication. 416 If the LAC negotiated PPP LCP before initiating the tunnel, the 417 initial connect notification may also include a copy of the LCP 418 CONFREQ's sent in each direction which completed LCP negotiation. 419 The LNS may use this information to initialize its own PPP state 420 (thus avoiding an additional LCP negotiation), or it may choose to 421 initiate a new LCP CONFREQ exchange. 423 If the LNS accepts the connection, it creates a "virtual interface" 424 for PPP in a manner analogous to what it would use for a direct- 425 dialed connection. With this "virtual interface" in place, link 426 layer frames may now pass over this tunnel in both directions. 427 Frames from the remote user are received at the POP, stripped of CRC, 428 link framing, and transparency bytes, encapsulated in L2TP, and 429 forwarded over the appropriate tunnel. 431 The LNS accepts these frames, strips L2TP, and processes them as 432 normal incoming frames for the appropriate interface and protocol. 433 The "virtual interface" behaves very much like a hardware interface, 434 with the exception that the hardware in this case is physically 435 located at the ISP POP. The other direction behaves analogously, 436 with the LNS encapsulating the packet in L2TP, and the LAC stripping 437 L2TP before transmitting it out the physical interface to the remote 438 user. 440 At this point, the connectivity is a point-to-point PPP session whose 441 endpoints are the remote user's networking application on one end and 442 the termination of this connectivity into the LNS's PPP support on 443 the other. Because the remote user has become simply another dial-up 444 client of the LNS, client connectivity can now be managed using 445 traditional mechanisms with respect to further authorization, 446 protocol access, and packet filtering. 448 Accounting can be performed at both the LAC as well as the LNS. This 449 document illustrates some Accounting techniques which are possible 450 using L2TP, but the policies surrounding such Accounting are outside 451 the scope of this specification. 453 L2TP offers optional facilities which maximize compatibility with 454 legacy client requirements; L2TP connect notifications for PPP 455 clients can contain sufficient information for an LNS to authenticate 456 and initialize its LCP state machine. With these facilities, the 457 remote user need not be queried a second time for PPP authentication, 458 nor undergo multiple rounds of LCP negotiation and convergence. 459 These techniques are intended to optimize connection setup, and are 460 not intended to deprecate any functions required by the PPP 461 specification. 463 3.0 Service Model Issues 465 There are several significant differences between the standard 466 Internet access service and the Virtual dial-up service with respect 467 to authentication, address allocation, authorization and accounting. 468 The details of the differences between these services and the 469 problems presented by these differences are described below. The 470 mechanisms used for Virtual Dial-up service are intended to coexist 471 with more traditional mechanisms; it is intended that an ISP's POP 472 can simultaneously service ISP clients as well as Virtual dial-up 473 clients. 475 3.1 Security 477 For the Virtual dial-up service, the ISP pursues authentication only 478 to the extent required to discover the user's apparent identity (and 479 by implication, their desired LNS). This may involve no more than 480 detecting DNIS information when a call arrives, or may involve full 481 LCP negotiation and initiation of PPP authentication. As soon as the 482 apparent identity is determined, a call request to the LNS is 483 initiated with any authentication information gathered by the ISP. If 484 the LNS receives proxy authentication information (see section 6.11), 485 it SHOULD assume that the PPP peer is in the authentication phase, 486 awaiting an indication of success or failure. The LNS completes the 487 authentication by either accepting the call, or rejecting it. 489 The LNS may need to protect against attempts by third parties to 490 establish tunnels to the LNS. Tunnel establishment can include 491 authentication to protect against such attacks. 493 3.2 Address Allocation 495 For a traditional Internet service, the user typically accepts that 496 the IP address may be allocated dynamically from a pool of ISP 497 addresses. This model often means that the remote user has little or 498 no access to their home network's resources, due to firewalls and 499 other security policies applied by the home network to accesses from 500 external IP addresses. 502 For the Virtual dial-up service, the LNS can exist behind the home 503 firewall, allocating addresses which are internal (and, in fact, can 504 be RFC 1918 addresses, or non-IP addresses). Because L2TP tunnels 505 exclusively at the frame layer, the actual policies of such address 506 management are irrelevant to correct Virtual dial-up service; for all 507 purposes of PPP protocol handling, the dial-in user appears to have 508 connected at the LNS. 510 3.3 Authentication 512 The authentication of the user occurs in three phases; the first at 513 the ISP, and the second and optional third at the LNS. 515 The ISP uses DNIS, CLID, or a username to determine that a Virtual 516 dial-up service is required and initiates the tunnel connection to 517 the appropriate LNS. Once a tunnel is established, The ISP NAS 518 allocates a new Call ID and initiates a session by forwarding the 519 gathered authentication information. 521 The LNS undertakes the second phase by deciding whether or not to 522 accept the call. The call start indication may include CHAP, PAP, 523 EAP, or textual authentication information. Based on this 524 information, the LNS may accept the call request, or may reject it 525 (for instance, it was a PAP request and the username/password are 526 found to be incorrect). 528 Once the call is accepted, the LNS is free to pursue a third phase of 529 authentication at the PPP layer. These activities are outside the 530 scope of this specification, but might include an additional cycle of 531 LCP authentication, proprietary PPP extensions, or textual challenges 532 carried via a TCP/IP TELNET session. 534 3.4 Accounting 536 It is a requirement that both the LAC and the LNS be capable of 537 providing accounting data and hence both may count packets, octets 538 and connection start and stop times. 540 Since Virtual dial-up is an access service, accounting of connection 541 attempts (in particular, failed connection attempts) is of 542 significant interest. The LNS can reject new connections based on 543 the authentication information gathered by the LAC, with 544 corresponding logging. For cases where the LNS accepts the 545 connection and then continues with further authentication, the LNS 546 might subsequently disconnect the client. For such scenarios, the 547 disconnection indication back to the LAC may also include a reason. 549 Because the LNS can decline a connection based on the authentication 550 information collected by the LAC, accounting can easily draw a 551 distinction between a series of failed call attempts and a series of 552 brief successful connections. Lacking this facility, the LNS must 553 always accept connection requests, and would need to exchange a 554 number of PPP packets with the remote system. Note that the LNS 555 could use this information to decide to accept the connection (which 556 protects against most invalid connection attempts) while still 557 insisting on running its own CHAP authentication (for instance, to 558 protect against CHAP replay attacks). 560 4.0 Protocol Overview 562 There are two parallel components of L2TP operating over a given 563 tunnel: control messages between each LAC-LNS pair, and payload 564 packets between the same LAC-LNS pair. The latter are used to 565 transport L2TP encapsulated PPP packets for user sessions between the 566 pair. 568 Two fields important to the operation of L2TP are the Nr (Next 569 Received) and Ns (Next Sent) fields which are always present in 570 control messages, and are optionally present in payload packets. A 571 single sequence number state is maintained for all control messages, 572 and a distinct state is maintained for the payload of each user 573 session within the tunnel. In this document, the sequence number 574 state for a control connection and each user session is represented 575 for clarity in the following discussions by distinct pairs of state 576 variables, Sr and Ss. Sr represents the value of the next in- 577 sequence message expected to be received for a given session by a 578 peer. Ss represents the sequence number to be placed in the Ns field 579 of the next message sent for a given session by the sending peer. 580 Each state is initialized such that the first message sent and the 581 first message expected to be received for each session has an Ns 582 value of 0. This corresponds to initializing Ss and Sr in both peers 583 to 0 for each new session. 585 As messages are sent for a given session, Nr is set in these messages 586 to reflect one more than the Ns value of the highest (modulo 2**16) 587 in-order message received for that session; if sent before any packet 588 is received Nr will be 0, indicating that the peer expects the next 589 new Ns value received to be 0. When a non-zero-length message is 590 received with an Ns value that matches the session's current Sr 591 value, Sr is incremented by 1 (modulo 2**16). It is important to note 592 that, for both control and payload sessions, Sr is not modified if a 593 message is received with a value of Ns greater than the current Sr 594 value (exceptions to this rule being the permitted handling of out- 595 of-order payload packets by the "simple receiver" discussed in 596 Appendix C and handling of payload packets with the R bit set). For 597 the control session, retransmission of outgoing messages should 598 eventually provide the receiving peer with the expected message. For 599 payload sessions, however, lost messages are never retransmitted so a 600 mechanism involving the use of the "Reset Sr" (R bit) indicator in an 601 outgoing message is used to update the peer's value of Sr to the 602 value of Ns contained in the message. See Sec. 4.2 for details of 603 this mechanism. 605 Every time a peer sends a non-zero length message it increments its 606 corresponding Ss value for that session by 1 (modulo 2**16). This 607 increment takes place after the current Ss value is copied to Ns in 608 the message to be sent. Outgoing messages always include the current 609 value of Sr for the corresponding session in their Nr field. 611 A message (control or payload) with a zero-length body indicates that 612 the packet is only used to communicate Nr and Ns fields. The Nr and 613 Ns fields are filled in as above, but the sequence number state, Ss, 614 is not incremented. Thus a zero-length message sent after a non- 615 zero-length message will contain a new Ns value while a non-zero- 616 length message sent after a zero-length message will contain the same 617 value of Ns as the preceding zero-length message. Unless the Rbit 618 (Reset Sr) is set, a peer receiving a zero-length message does not 619 update its Sr variable. 621 Upon receipt of an in-order non-zero-length message, the receiving 622 peer must acknowledge the message by sending back the updated value 623 of Sr in the Nr field of the next outgoing message. This updated Sr 624 value can be piggybacked in the Nr field of any non-zero-length 625 outgoing messages that the peer may happen to send back. 627 If the peer does not have a message to transmit for a short period of 628 time after receiving a non-zero-length message then it should send a 629 zero-length message containing the latest values of Sr and Ss, as 630 described above. The suggested value for this time interval is 1/4 631 the receiving peer's value of Round-Trip-Time (RTT - see Appendix A), 632 if it computes RTT, or a maximum of 1/2 second otherwise. This 633 timeout should provide a reasonable opportunity for the receiving 634 peer to obtain a payload message destined for its peer, upon which 635 the ACK of the received message can be piggybacked. 637 This timeout value should be treated as a suggested maximum; an 638 implementation could make this timeout quite small without adversely 639 affecting the protocol. To provide for better throughput, the 640 receiving peer should skip this timeout entirely and send a zero- 641 length message immediately in the case where its receive window fills 642 and it has no queued data to send for this connection or it can't 643 send queued data because the transmit window is closed. 645 A suggested implementation of this timer is as follows: Upon 646 receiving a non-zero-length message, the receiver starts a timer that 647 will expire in the recommended time interval. A variable, Lr (Last 648 Nr value sent), is used by the transmitter to store the last value 649 sent in the Nr field of a transmitted payload message for this 650 connection. Upon expiration of this timer, Sr is compared to Lr and, 651 if they are not equal, a zero-length ACK is issued. If they are 652 equal, then no ACK's are outstanding and no action needs to be taken. 654 This timer should not be reinitialized if a new message is received 655 while it is active since such messages will be acknowledged when the 656 timer expires. This ensures that periodic ACK's are issued with a 657 maximum period equal to the recommended timeout interval. This 658 interval should be short enough to not cause false acknowledgment 659 timeouts at the transmitter when payload messages are being sent in 660 one direction only. Since such ACK's are being sent on what would 661 otherwise be an idle data path, their affect on performance should be 662 small, if not negligible. 664 See Appendix E for some examples of how sequence numbers progress. 666 4.1 Control Message Overview 668 Before PPP tunneling can occur between an LAC and LNS, control 669 messages must be exchanged between them. Control messages are 670 exchanged over the same tunnel which will be used to forward 671 payload data once L2TP call control and management information 672 have been passed. The control messages are responsible for 673 establishment, management, and release of sessions carried through 674 the tunnel, as well as status on the tunnel itself. It is the 675 means by which an LNS is notified of an incoming call at an 676 associated LAC, as well as the means by which an LAC is instructed 677 to place an outgoing call. 679 A tunnel may be established by either an LAC (for incoming calls) 680 or an LNS (for outgoing calls). Following the establishment of 681 the tunnel, the LNS and LAC configure the tunnel by exchanging 682 Start-Control-Connection-Request and -Reply messages. These 683 messages are also used to exchange information about basic 684 operating capabilities of the LAC and LNS. Once the control 685 message exchange is complete, the LAC may initiate sessions by 686 indicating inbound requests, or the LNS by requesting outbound 687 calls. If both ends of the tunnel have the ability to act as an 688 LAC and LNS concurrently, then nothing prohibits establishing 689 incoming or outgoing calls from both sides of the same tunnel. 690 Control messages may indicate changes in operating characteristics 691 of an individual user session with a Set-Link-Info message. 692 Individual sessions may be released by either the LAC or LNS, also 693 through control messages. 695 Independent Call ID values are established for each end of a user 696 session. The sender of a packet associated with a particular 697 session places the Call ID established by its peer in the Call ID 698 header field of all outgoing packets. For the cases where a Call 699 ID has not yet been assigned from the peer (i.e., during call 700 establishment of a new session), the Call ID field is sent as 0, 701 and further fields within the message are used to identify the 702 session. The Call ID value of 0 is thus special and MUST NOT be 703 used as an Assigned Call ID. 705 A mechanism for detection of tunnel connectivity problems is 706 provided by the reliable transport layer of L2TP. The transport 707 layer of L2TP performs control message retransmission. If the 708 number of retransmission attempts for a given control message 709 exceeds a configured maximum value, the tunnel is reset. This 710 retransmission mechanism exists in both the LNS and LAC ends of 711 the tunnel. 713 A keepalive mechanism is employed by the L2TP higher layer in 714 order to differentiate tunnel outages from extended periods of no 715 control or data activity on a tunnel. This is accomplished by the 716 higher layer injecting Hello control messages into the control 717 stream after a specified period of time elapses since the last 718 data or control message was received on the tunnel. As for any 719 other control message, if the transport does not receive an ACK 720 for the Hello message after the normal number of retransmissions 721 the tunnel is declared down and is reset. The transport layer 722 reset mechanism along with the injection of Hello messages ensures 723 that a connectivity failure between the LNS and the LAC will be 724 detected at both ends of a tunnel in a timely manner. 726 It is intended that control messages will also carry management 727 related information in the future, such as a message allowing the 728 LNS to request the status of a given LAC; these message types are 729 not defined in this document. 731 4.2 Payload Packet Overview 733 Once a tunnel is established and control messages have completed 734 tunnel setup, the tunnel can be used to carry user session PPP 735 packets for sessions involving a given LNS-LAC pair. The "Call 736 ID" field in the L2TP header indicates to which session a 737 particular PPP packet belongs. In this manner, PPP packets are 738 multiplexed and demultiplexed over a single tunnel between a given 739 LNS-LAC pair. The "Call ID" field value is established during the 740 exchange of call setup control messages. 742 It is legal for multiple tunnels to exist between a given LNS-LAC 743 pair. This is useful where each tunnel is used for a single user 744 session, and the tunnel media (an SVC, for instance) has specific 745 QOS attributes dedicated to a given user. L2TP provides a tunnel 746 identifier so that individual tunnels can be identified, even when 747 arriving from a single source LAC or LNS. 749 The L2TP header also contains optional acknowledgment and 750 sequencing information that can be used to perform congestion and 751 flow control over the tunnel (See section 4.3). Control messages 752 are used to determine rate and buffering parameters that are used 753 to regulate the flow of PPP packets for a particular session over 754 the tunnel. 756 The receiving peer indicates whether congestion control is to be 757 performed for payload packets sent to it. If a peer issues a 758 Receive Window Size AVP with a non-zero value during session 759 establishment then the sending peer MUST abide by the indicated 760 window size value as long as sequence numbers are provided. If a 761 receiving peer does not wish to flow control the payload packets 762 sent to it, it should not issue the Receive Window Size AVP with a 763 non-zero value. Issuing a Receive Window Size AVP with a zero 764 value has special significance. It indicates that the receiver 765 does not want to perform flow-control but it does want the sending 766 peer to provide Ns values in payload packets so that it can detect 767 lost packets or packets received out of order. A receiver SHOULD 768 NOT send any ZLB ACK's to the sender who advertizes a Receive 769 Window of zero, nor should the sender expect to receive such 770 explicit acknowledgements. 772 In the case where neither peer issues a Receive Window Size AVP 773 during session establishment, the optional Nr and Ns fields are 774 absent in all payload packets for that session. In the case where 775 either peer wishes to perform flow-control or to detect out-of- 776 order receive messages (as indicated by the sending of the Receive 777 Window Size AVP with non-zero or zero value, respectively) the Nr 778 and Ns fields MUST be present in payload packets sent by both 779 peers. Both MUST begin the session providing proper Nr and Ns 780 values in all data packets transmitted. A proper Ns value starts 781 at 0 and increments by one for each transmitted payload message 782 and a proper Nr value is the current value of the receive sequence 783 number state variable, Sr. 785 Unless the LAC sends the Sequencing Required AVP (see section 6.7 786 and 6.8) in the ICCN or OCCN message, the LNS has the authority to 787 dynamically enable or disable sending of Ns/Nr and hence 788 controlling the capability of reordering and flow control over the 789 link. To disable sequence numbers, the LNS sends a packet with 790 the F bit set to 0 and Ns/Nr fields not present. The LAC, upon 791 receiving such a data packet, MUST process the packet and 792 discontinue inclusion of Ns/Nr fields in any subsequent data 793 packets. Any packets which have been received by L2TP but are 794 being held in queue for reordering SHOULD be flushed without 795 waiting for an ACK from the peer (as if an R bit packet with Ns 796 equal to the current Sr value was received). Ss and Sr should be 797 updated and saved accordingly. 799 All data packets will continue to be exchanged without sequence 800 numbers until the end of the session or until the LNS resumes 801 sequence numbers by sending a packet with the F bit set and Ns/Nr 802 present. The LAC, upon receiving a packet with the F bit set, MUST 803 resume sending sequence numbers in further packets. In order to 804 properly resume, the LNS and LAC MUST preserve the state of Ss and 805 Sr between periods of disabled sequencing. 807 While the LNS may initiate disabling of sequencing at any time 808 during the session (including the first data packet sent), it is 809 recommended that for links where reordering or packet loss may 810 occur, sequence numbers always be enabled during the initial 811 negotiation stages of PPP and disabled only when and if the risk 812 is considered acceptable. For instance, if the PPP session being 813 tunneled is not utilizing any stateful compression or encryption 814 protocols and is only carrying IP (as determined by the NCP's that 815 are established), then the LNS might decide to disable sequencing, 816 thus allowing higher level protocols to perform necessary flow 817 control end to end and reducing the per packet L2TP processing 818 burden on the LNS substantially. Note that this effectively 819 disables the ability of L2TP to detect or reorder PPP frames. 820 Further discussion of some of the tradeoffs associated with 821 disabling sequencing over media which may reorder or silently drop 822 packets is given in section 8.2. 824 4.3 Congestion Control 826 If a receiving peer offers a non-zero receive window size to a 827 sending peer then the sending peer MUST abide by this window size 828 value as long as sequence numbers are being exchanged. The 829 sending peer MUST stop sending payload packets when the window is 830 full; i.e., x consecutive messages have been sent but have not 831 been acknowledged, where x is the value of the Receive Window Size 832 AVP. Implementors should take care to avoid the situation where 833 loss of an ACK by a sending peer with a full transmit window 834 causes a session to hang forever, due to the fact there are no 835 retransmissions of payload packets. Steps must be taken to reopen 836 the transmit window (at least to a value of 1) upon expiration of 837 an ACK wait timeout. See Appendix B for more details. 839 When sending to a peer that has issued a non-zero receive window 840 size, the sending peer is responsible for resetting the receiver's 841 Sr value when a sent payload message is lost during transmission. 842 When a sent message is lost, the receiving peer's Sr value (and 843 hence the Nr value it sends) will "stick" at the Ns value of the 844 first missing payload message. The "Reset Sr" (R bit) in the 845 payload message header (see Section 5.3) provides a mechanism for 846 the sending peer to indicate to the receiver that it (the sending 847 peer) recognizes that at least one payload message has been lost 848 and that the receiving peer should now reset its Sr value beyond 849 the lost message(s). If the sending peer is performing adaptive 850 window adjustment (see Appendix B.1) then it is this recognition 851 of a lost message that is used to indicate that a window 852 adjustment at the sending peer should be performed. 854 The sender may use a timer mechanism similar to that used to 855 retransmit lost control messages to determine when transmitted 856 payload packets have been lost. When the timer expires, a payload 857 message (zero or non-zero length) with the R bit set can be issued 858 to indicate to the receiver that it needs to reset its Sr value. 859 Upon receipt of a payload message with the R bit set, the receiver 860 resets Sr to the value of Ns contained in the message, or, if 861 highly congested, to a value between its current value and the 862 value of Ns contained in the message. 864 Upon receipt of a payload message with R bit set, the receiver 865 takes the following actions: First, the receiver checks for the 866 presence of the R bit in a received payload message before 867 comparing the message's Ns value to its Sr value. If the R bit is 868 set, the receiver will typically set its Sr value equal to that of 869 Ns contained in the message and fall through to normal receive 870 message processing in which Sr will be incremented (modulo 2**16) 871 if the message is non-zero-length and will remain the same if it 872 is zero-length. However, if the receiver is known to be heavily 873 congested, it MAY choose to not update or set its new Sr value 874 between (modulo 2**16) the current Sr value and that of Ns 875 contained in the message. This effectively spoofs the transmitter 876 into believing that the R bit packets that have been sent are not 877 being received, ultimately causing the transmitter to backoff more 878 quickly. 880 In order to prevent an R bit message received out of order from 881 setting Sr to an old value, the receiving peer should compare the 882 value of Ns in an R bit message to its current value of Sr. The 883 receiving peer should reset its Sr value only if Ns is greater 884 than (modulo 2**16) its current value of Sr. 886 The sender of the R bit can decide whether it wishes to advance 887 the receiver's Sr value to the value just past the highest (modulo 888 2**16) Nr value received (the Ns value of the message just past 889 that of the first lost message) or to its current value of Ss. 890 Resetting it to that just past the first lost message enables the 891 sender to determine if other messages in the same transmit window 892 were also lost. Setting it to the current Ss value of the sender 893 treats losses of multiple messages in the same window the same as 894 the loss of a single message. An implementation may use either, 895 or a combination of both methods. If the transmitter detects that 896 the receiver is heavily congested, piggybacking the R bit on data 897 packets should be refrained in favor of a ZLB with the R bit set 898 for resetting the receiver's Sr. 900 It is permissible for a sending peer to set the R bit (and hence 901 reset the transmit window) in all transmitted payload packets as 902 an indication that flow control has been disabled at the 903 transmitter. 905 Receipt of an R bit is NOT an explicit indication to immediately 906 flush all packets which might be in queue to PPP for processing. 907 There are a number of tradeoffs as to precisely when a receiver 908 should decide to pass packets from L2TP to PPP, many dependent on 909 what protocols are being carried by PPP. In general, packets 910 should be declared lost and passed to PPP in a timely enough 911 manner so as to not cause retransmissions by reliable higher layer 912 protocols due to packets that are held in queue by l2tp. 914 L2TP does not specify the particular timeout algorithms to use for 915 congestion control. Suggested algorithms for the determination of 916 adaptive timeouts to recover from dropped data or acknowledgments 917 on the tunnel are included in Appendix A of this document. 918 Additional examples for sequencing and congestion control are 919 included in Appendix E. 921 5.0 Message Format and Protocol Extensibility 923 L2TP defines a set of control messages sent in packets over the 924 tunnel between an LNS and a given LAC. The exact technique for 925 initiating a tunnel between an LNS-LAC pair is specific to the tunnel 926 media, and specific media are described in section 8.0. 928 Once media-level connectivity is reached, L2TP message formats define 929 the protocol for an LAC and LNS to manage the tunnel and its 930 associated sessions. 932 In each case where a field is optional, if the field is not present, 933 its space does not exist in the packet. Existing fields are placed 934 back-to-back to form the packet. 936 5.1 AVP 938 To maximize extensibility while still permitting interoperability, 939 a uniform method for encoding message types and bodies is used 940 throughout L2TP. This encoding will be termed an AVP (Attribute- 941 Value Pair) in the remainder of this document. Each AVP is 942 encoded as: 944 0 1 2 3 945 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 |M|H|0|0|0|0| Overall Length | Vendor ID | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Attribute | Value... | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | [until Overall Length is reached]... | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 The first six bits are a bit mask, describing the general 955 attributes of the AVP. 957 The 0 bits indicate reserved bit fields and MUST be set to 0. An 958 AVP received with a reserved bit set to 1 MUST be treated as an 959 unrecognized AVP, unless the reserved bit is defined for an 960 extension that is known to the implementation. 962 The M bit, known as the "mandatory" bit, controls the behavior 963 required of an implementation which receives an AVP which it does 964 not recognize. If M is set on an unrecognized AVP associated with 965 call (session) management, any session associated with this AVP 966 MUST be terminated. If M is set on an unrecognized AVP associated 967 with the overall tunnel, the entire tunnel (and all sessions 968 within) MUST be terminated. If M is not set, an unrecognized AVP 969 should be ignored. 971 The H bit, known as the "hidden" bit, controls the hiding of the 972 data in the value field of an AVP. This capability can be used to 973 avoid the passing of sensitive data, such as user passwords, as 974 cleartext in an AVP. Section 5.7 describes the procedure for 975 performing AVP value hiding. 977 Overall Length encodes the number of octets (including the Overall 978 Length field itself) contained in this AVP. It is 10 bits, 979 permitting a maximum of 1024 octets of data in a single AVP. 981 Vendor ID is the IANA assigned "SMI Network Management Private 982 Enterprise Codes" [12] value, encoded in network byte order. The 983 value 0, reserved in this table, corresponds to IETF adopted 984 Attribute values, defined within this document. Any vendor 985 wishing to implement L2TP extensions can use their own Vendor ID 986 along with private Attribute values, guaranteeing that they will 987 not collide with any other vendor's extensions, nor with future 988 IETF extensions. 990 Attribute is the actual attribute, a 16-bit value with a unique 991 interpretation across all AVP's defined under a given Vendor ID. 993 Value follows immediately after the Attribute field, and runs for 994 the remaining octets indicated in the Overall Length (i.e., 995 Overall Length minus six octets of header). 997 AVP's should be kept compact; the combined AVP's within a control 998 message MUST NOT ever cause a control message's total length to 999 exceed 1500 octets in length. 1001 5.2 Control Message Format 1003 Each L2TP control message begins with a 16 octet header portion 1004 followed by zero or more AVP's. This header is formatted: 1006 0 1 2 3 1007 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 |T|L|0|0|F|0|0|0|0|0|0|0|0| Ver | Length | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Tunnel ID | Call ID | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Ns | Nr | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Message Type AVP... 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 ... (8 octets) | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 The 0 bits indicate reserved bit fields and MUST be set to 0. A 1021 control message received with a reserved bit set to 1 in the 1022 header MUST be treated as an unrecognized control message, unless 1023 the bit is defined for an extension that is known to the 1024 implementation. 1026 The L and F bits must be 1, indicating that the length, Ns and Nr 1027 fields are present. 1029 The T bit MUST be 1, indicating a control message. 1031 Ver MUST be the value 2, indicating a version 1 L2TP message (the 1032 value 0 is reserved to permit detection of L2F [2] packets should 1033 they arrive intermixed). 1035 Length is the overall length of the message, including header, 1036 message type AVP, plus any additional AVP's associated with a 1037 given control message type. 1039 Tunnel ID and Call ID identify the tunnel and user session within 1040 the tunnel to which a control message applies. If a control 1041 message does not apply to a single user session within the tunnel 1042 (for instance, a Stop-Control-Connection-Notification message), 1043 Call ID MUST be set to 0. If an Assigned Tunnel ID has not yet 1044 been received from the peer, Tunnel ID MUST be set to 0. Once an 1045 Assigned Tunnel ID is received, all further packets MUST be sent 1046 with Tunnel ID set to the indicated value. Note that the Assigned 1047 Tunnel ID and Call ID MAY be selected in an unpredictable manner 1048 rather than sequentially or otherwise. Doing so will help to 1049 deter hijacking of a session by a malicious user who does not have 1050 access to packet traces between the LAC and LNS. 1052 Ns is copied from the send sequence number state variable, Ss, at 1053 the time the message is transmitted. Ss is incremented after 1054 copying if the length of the control message is non-zero. Nr is 1055 copied from the receive sequence number state variable, Sr, and 1056 indicates the sequence number, Ns, + 1 of the highest (modulo 1057 2**16) in-sequence message received. See section 4.0. 1059 5.3 Payload Message Format 1061 PPP payload packets tunneled within L2TP have a smaller 1062 encapsulation than the L2TP control message header, reducing 1063 overhead of L2TP during the life of a tunneled PPP session. The 1064 LNS is expected to be able to process user data packets of at 1065 least the default MRU for PPP, not including L2TP and media 1066 encapsulation. The smallest L2TP encapsulation is 6 octets; the 1067 largest is 14 octets (plus padding octets, if present). See 1068 section 8.1 for further MTU considerations. 1070 0 1 2 3 1071 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 |T|L|R|0|F|0|S|P|0|0|0|0|0| Ver | Length (opt) | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Tunnel ID | Call ID | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Ns (opt) | Nr (opt) | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Offset Size (opt) | Offset pad... (opt) | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 The 0 bits indicate reserved bit fields and MUST be set to 0. A 1083 packet received with a reserved bit set to 1 in the payload 1084 message header MUST be silently discarded, unless the bit is 1085 defined for an extension that is known to the implementation. 1087 The T bit MUST be 0, indicating payload. 1089 Ver MUST be 2, indicating version 1 of the L2TP protocol. 1091 If the L bit is set, the Length field is present, indicating the 1092 total length of the packet sent. 1094 The R bit, "Reset Sr", is used for congestion control and 1095 indicates that the receiver SHOULD reset its receive state 1096 variable, Sr, for this session to the value contained in the Ns 1097 field of this message header. Sr is reset to the value of Ns only 1098 if Ns is greater than (modulo 2**16) the receiver's current value 1099 of Sr. Normal receive processing of the message is performed 1100 after the value of Sr is reset. Note that if the F bit is not 1101 set, then this bit MUST be 0. See section 4.2 for a detailed 1102 discussion of the use of this bit for congestion control on the 1103 data channel. See Appendix E for examples of proper R bit usage. 1105 If the F bit is set, both the Nr and Ns fields MUST be present. 1106 Ns indicates the sequence number of the packet being sent. The Ns 1107 value of a message being transmitted is copied from the current 1108 value of the send sequence number state variable, Ss. Ss is 1109 incremented by one (modulo 2**16) after copying to the Ns field 1110 only if the payload size of the message being sent is non-zero. 1111 Nr indicates the sequence number of the next in-order message 1112 sequence number to be received (if the last in-order non-zero- 1113 length data packet had Ns set to 1, the Nr sent back would be 2). 1114 The value of Nr is copied from the current receive state variable, 1115 Sr. Together, Nr and Ns can be used to handle out-of-order 1116 packets and, together with the R bit, to provide flow control for 1117 the connection. 1119 An L2TP peer setting the F bit, and placing Nr and Ns fields in 1120 its messages, MUST have previously received or sent a Receive 1121 Window Size AVP during establishment of the session. The Nr and 1122 Ns fields are present and updated as described in section 4.0 if 1123 either side has specified an intention to do payload flow control. 1125 The Offset Size field is present if the S bit is set in the header 1126 flags. This field specifies the number of octets past the L2TP 1127 header at which the payload data is expected to start. It is 1128 recommended that data thus skipped be initialized to 0's. If 1129 Offset Size is 0, or the S bit is not set, the first octet 1130 following the last octet of L2TP header is the first octet of 1131 payload data. 1133 If the P bit is set, this packet should receive preferential 1134 treatment at the LAC in its queuing for transmission to the 1135 client. LCP echo requests used as a keepalive for the link, for 1136 instance, should generally be sent from the LNS with this bit set. 1137 Without it, a temporary interval of congestion of the transmission 1138 queues could result in the interference with keepalive messages 1139 and unnecessary loss of the link. 1141 5.4 Control Message Types 1143 Control message and AVP types defined in this specification exist 1144 under Vendor ID 0, indicating IETF defined behavior. The actual 1145 message and AVP semantics are defined in the next section. This 1146 section includes tables that summarize all currently defined 1147 message and AVP types. 1149 Each message type entry in the table below indicates: the integer 1150 value assigned to the message type; the message type abbreviation 1151 used in the AVP Summary Table of Sec. 5.5; and the full name of 1152 the message type. 1154 The integer value assigned to each message type is placed in the 1155 Value field of the Message Type AVP. This AVP MUST be the first 1156 AVP in a message. The currently defined control message types, 1157 grouped by function, are: 1159 Control Connection Management 1161 1 (SCCRQ) Start-Control-Connection-Request 1162 2 (SCCRP) Start-Control-Connection-Reply 1163 3 (SCCCN) Start-Control-Connection-Connected 1164 4 (StopCCN) Stop-Control-Connection-Notification 1165 5 (reserved) 1166 6 Hello 1168 Call Management 1170 7 (OCRQ) Outgoing-Call-Request 1171 8 (OCRP) Outgoing-Call-Reply 1172 9 (OCCN) Outgoing-Call-Connected 1173 10 (ICRQ) Incoming-Call-Request 1174 11 (ICRP) Incoming-Call-Reply 1175 12 (ICCN) Incoming-Call-Connected 1176 13 (reserved) 1177 14 (CDN) Call-Disconnect-Notify 1179 Error Reporting 1181 15 (WEN) WAN-Error-Notify 1183 PPP Session Control 1185 16 (SLI) Set-Link-Info 1187 5.5 AVP Summary 1189 The following table lists all standard L2TP attributes currently 1190 defined. The "Attr" column indicates the integer value assigned 1191 to this attribute. The "M" column indicates the setting of the 1192 "Mandatory" bit of the AVP header for each attribute. The "Len" 1193 field indicates the size of the AVP including the AVP header. A 1194 "+" in this column indicates that the length varies depending upon 1195 the length of the actual contents of the value field. 1197 The "(usage)" list for each entry indicates the message types that 1198 utilize each AVP (See command table of Sec. 5.4). An abbreviation 1199 shown in mixed or upper case letters indicates that the 1200 corresponding AVP MUST be present in this message type; All lower 1201 case indicates that the AVP may optionally appear in this message 1202 type. Some AVPs MUST be present only when a corresponding optional 1203 AVP is present, these AVPs are shown in lower case as well. 1205 A brief summary of the type and contents of the value field for 1206 each attribute is also given for each entry. Refer to the 1207 individual message type descriptions that appear in Section 6 for 1208 further details about the use of a particular AVP in a particular 1209 message type. This table is provided only as a convenient overview 1210 of AVPs, individual message AVP descriptions always enjoy priority 1211 to summary descriptions provided in this table. 1213 Attr M Len Attribute Name (usage) 1215 0 1 8 Message Type (ALL MESSAGES) 1216 16-bit integer value indicating the message type, as defined in 1217 table above. MUST be the first AVP in each message 1219 1 1 10+ Result Code (CDN, StopCCN) 1220 16-bit Integer value indicating result of corresponding request 1221 or reason for issuing a request, 16-bit integer General Error 1222 code and an optional ASCII string error message. See Result 1223 and General Error code tables below. 1225 2 1 8 Protocol Version (SCCRP, SCCRQ) 1226 8-bit L2TP Protocol and Revision numbers 1228 3 1 10 Framing Capabilities (SCCRP, SCCRQ) 1229 32-bit bitmask indicating supported framing types (e.g., 1230 synchronous and asynchronous) 1232 4 1 10 Bearer Capabilities (sccrp, sccrq) 1233 32-bit bitmask indicating supported bearer types (e.g., analog 1234 and digital) 1236 5 0 14 Tie Breaker (sccrq) 1237 8 octet value used to break control connection establishment 1238 collisions 1240 6 0 8 Firmware Revision (sccrp, sccrq) 1241 16-bit integer representing vendor's firmware revision 1243 7 1 6+ Host Name (SCCRP, SCCRQ) 1244 ASCII string name (e.g., DNS name) of issuer 1246 8 0 6+ Vendor Name (sccrp, sccrq) 1247 ASCII string describing issuing device 1249 9 1 8 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 1250 16-bit integer tunnel ID assigned by sender 1252 10 1 8 Receive Window Size (iccn, icrp, occn, ocrq, sccrp, 1253 sccrq) 1254 16-bit integer receive window size offered by sender for a 1255 given call or control session 1257 11 1 6+ Challenge (sccrp, sccrq) 1258 1 or more octet value issued by sender wishing to authenticate 1259 control session peer 1261 12 1 9+ Q.931 Cause Code (cdn) 1262 16-bit cause code, 1 octet cause message, and optional ASCII 1263 advisory message 1265 13 1 22 Challenge Response (scccn, sccrp) 1266 16 octet CHAP type response to peer's Challenge 1268 14 1 8 Assigned Call ID (CDN, ICRP, ICRQ, OCRP, OCRQ) 1269 16-bit integer ID assigned to a call by sender 1271 15 1 10 Call Serial Number (ICRQ, OCRQ) 1272 1 or more octet identifier assigned to a call 1274 16 1 10 Minimum BPS (OCRQ) 1275 32-bit integer indicating lowest acceptable line speed for call 1277 17 1 10 Maximum BPS (OCRQ) 1278 32-bit integer indicating highest acceptable line speed for 1279 call 1281 18 1 10 Bearer Type (icrq, OCRQ) 1282 Indicates bearer type (i.e., analog or digital) for call 1284 19 1 10 Framing Type (ICCN, OCCN, OCRQ) 1285 Indicates framing type (i.e., synchronous or asynchronous) for 1286 call 1288 20 1 8 Packet Processing Delay (iccn, icrp, occn, ocrq) 1289 16-bit integer estimate of processing time of full window of 1290 received packets by sender 1292 21 1 6+ Dialed Number (icrq, OCRQ) 1293 ASCII string phone number called or to be called 1295 22 1 6+ Dialing Number (icrq) 1296 ASCII string phone number of caller 1298 23 1 6+ Sub-Address (icrq, ocrq) 1299 ASCII string containing additional dialing information 1301 24 1 10 (Tx) Connect Speed (ICCN, OCCN) 1302 32-bit integer representing actual (or transmit) line speed of 1303 connection 1305 25 0 10 Physical Channel ID (icrq, ocrp) 1306 32-bit vendor specific physical device identifier used for call 1308 26 0 6+ Initial Received LCP CONFREQ (iccn) 1309 Octet string containing initial CONFREQ received from client 1311 27 0 6+ Last Sent LCP CONFREQ (iccn) 1312 Octet string containing final CONFREQ sent to client 1314 28 0 6+ Last Received LCP CONFREQ (iccn) 1315 Octet string containing final CONFREQ received from client 1317 29 0 8 Proxy Authen Type (iccn) 1318 16-bit integer code indicating client authentication type 1319 negotiated (e.g., PAP, CHAP) 1321 30 0 6+ Proxy Authen Name (iccn) 1322 ASCII string containing name returned by client in 1323 authentication response 1325 31 0 6+ Proxy Authen Challenge (iccn) 1326 Octet string Challenge presented by LAC to client 1328 32 0 8 Proxy Authen ID (iccn) 1329 16-bit integer of which low order octet is ID presented to 1330 client with Challenge. High order octet must be 0. 1332 33 1 6+ Proxy Authen Response (iccn) 1333 Octet string CHAP response or ASCII string password depending 1334 on authentication type used 1336 34 1 32 Call Errors (WEN) 1337 A reserved 16-bit word set to 0 followed by 6 32-bit integer 1338 connection error counters 1340 35 1 16 ACCM (SLI) 1341 A reserved 16-bit word set to 0 followed by 2 32-bit bitmasks 1342 containing Send and Receive ACCM values respectively 1344 36 1 6+ Random Vector (all messages) 1345 Variable length octet string containing a random sequence of 1346 values used to accomplish the optional "hiding" of other AVP 1347 values (See "H" bit description in Sec. 5.7). 1349 37 0 6+ Private Group ID (iccn) 1350 Variable length octet value used by the LAC or LNS to indicate 1351 that this call is to be associated with a particular customer 1352 group. 1354 38 0 10 Rx Connect Speed (iccn, occn) 1355 32-bit integer representing actual receive line speed of 1356 connection. Suggests possibility of asymmetric connection. 1358 39 1 6 Sequencing Required (iccn, occn) 1359 If present, indicates to the LNS that it MUST NOT dynamically 1360 disable sequencing. 1362 5.6 Result and Error Code Summary 1364 The StopCCN and CDN message types contain a Result Code AVP which 1365 indicates the result of the previously requested operation. The 1366 Result Code can indicate that additional information pertaining to an 1367 error situation can be found in the Error Code field of the Result 1368 Code AVP. The meaning of the result code is tabulated under the 1369 specific type of message containing the result. Each 16-bit Result 1370 Code is immediately followed (in the same AVP) by a 16-bit General 1371 Error code value. 1373 General error codes pertain to types of errors which are not specific 1374 to any particular L2TP request, but rather to protocol or message 1375 format errors. If an L2TP reply indicates in its Result Code that a 1376 general error occurred, the General Error value should be examined to 1377 determine what the error was. The currently defined General Error 1378 codes and their meanings are: 1380 0 - No general error 1381 1 - No control connection exists yet for this LAC-LNS pair 1382 2 - Length is wrong 1383 3 - One of the field values was out of range or reserved field was 1384 non-zero 1385 4 - Insufficient resources to handle this operation now 1386 5 - The Call ID is invalid in this context 1387 6 - A generic vendor-specific error occurred in the LAC 1388 7 - Try another. If LAC is aware of other possible LNS 1389 destinations, it should try one of them. This can be used to 1390 guide an LAC based on LNS policy, for instance, the existence 1391 of multilink PPP bundles. 1393 If the length of the Result Code AVP specifies that the Value field 1394 is more than four octets in length, the remaining octets after the 1395 General Error Code field are an arbitrary string providing further 1396 (possibly human readable) text associated with the condition. 1398 Generally, when a General Error Code of 6 is used, additional 1399 information about the error will be included in the Optional Message 1400 field that follows the Error Code field in the Result Code AVP. 1402 5.7 Hiding of AVP values 1404 The H ("Hidden") bit in the header of each AVP in a control message 1405 provides a mechanism to indicate to the receiving peer whether the 1406 contents of the AVP are hidden or present in cleartext. This feature 1407 can be used to hide sensitive control message data such as user 1408 passwords or user ID's. The H bit MUST NOT be set in the Random 1409 Vector AVP or Message Type AVP. 1411 The H bit MUST only be set if a shared secret exists between the 1412 peers on either end of the tunnel. AVPs involved in the establishment 1413 of the tunnel, or reporting errors involved in the establishment of 1414 the tunnel MUST NOT be hidden. These AVPs are the "Host Name" AVP in 1415 the SCCRQ and SCCRP message, the "Assigned Tunnel ID" in the SCCRQ, 1416 SCCRP, and StopCCN message and the "Result Code" in the StopCCN 1417 message. If the H bit is set in any AVP(s) in a given command 1418 message, a Random Vector AVP must also be present in the message and 1419 MUST precede the first AVP having an H bit of 1. 1421 The length of the AVP value to be hidden is first encoded in the form 1422 of a Hidden AVP Subformat as follows: 1424 0 1 2 3 1425 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | Length of Original Value | Original Value ... 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 ... | Padding ... 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 Length 1433 This is length of the Original Value to be obscured in octets. 1435 Original Value 1436 Value of hidden AVP that is to be obscured. 1438 Padding 1439 Random additional octets used to obscure length of the Original 1440 Value. 1442 The resulting subformat MAY be padded to a multiple of 16 octets in 1443 length. For example, if the Original Value to be obscured is a string 1444 containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 1445 octets of padding would be applied. Padding does NOT alter the value 1446 placed in the Length of the Original Value, only the length of the 1447 AVP itself. 1449 Next, An MD5 hash is performed on the concatenation of: 1451 - the 2 octet Attribute number of the AVP (in network order) 1452 - the shared authentication secret 1453 - an arbitrary length random vector 1455 The value of the random vector used in this hash is passed in the 1456 value field of a Random Vector AVP. This Random Vector AVP must be 1457 placed in the message by the sender before any hidden AVPs. The same 1458 random vector may be used for more than one hidden AVP in the same 1459 message. If a different random vector is used for the hiding of 1460 subsequent AVPs then a new Random Vector AVP must be placed in the 1461 command message before the first AVP to which it applies. 1463 The MD5 hash value is then XORed with the first 16 octet or less 1464 segment of the Hidden AVP Subformat and placed in the Value field of 1465 the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, 1466 the Subformat is transformed as if the Value field had been padded to 1467 16 octets before the XOR, but only the actual octets present in the 1468 Subformat are modified, and the length of the AVP is not altered. 1470 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1471 is calculated over a stream of octets consisting of the shared secret 1472 followed by the result of the first XOR. That hash is XORed with the 1473 second 16 octet or less segment of the Subformat and placed in the 1474 corresponding octets of the Value field of the Hidden AVP. 1476 If necessary, this operation is repeated, with the shared secret used 1477 along with each XOR result to generate the next hash to XOR the next 1478 segment of the value with. 1480 The method is taken from the book "Network Security" by Kaufman, 1481 Perlman and Speciner [4] pages 109-110. A more precise explanation 1482 of the method follows: 1484 Call the shared secret S, the Random Vector RV, and the Attribute 1485 Value AV, Break the value field into 16-octet chunks p1, p2, etc. 1486 with the last one padded at the end with random data to a 16-octet 1487 boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need 1488 intermediate values b1, b2, etc. 1490 b1 = MD5(AV + S + RA) c(1) = p1 xor b1 1491 b2 = MD5(S + c(1)) c(2) = p2 xor b2 1492 . . 1493 . . 1494 . . 1495 bi = MD5(S + c(i-1)) c(i) = pi xor bi 1497 The String will contain c(1)+c(2)+...+c(i) where + denotes 1498 concatenation. 1500 On receipt, the random vector is taken from the last Random Vector 1501 AVP encountered in the message prior to the AVP to be unhidden. The 1502 above process is then reversed to yield the original value. For more 1503 details on this hiding method, consult RFC 2058 [8]. 1505 The Random Vector AVP has the following format: 1507 Random Vector 1509 0 1 2 3 1510 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 |1|0|0|0| 6 + String length | 0 | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | 36 | Random Octet String ... 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 The Random Vector AVP may be used in any message type. The Attribute 1518 value is 36 and it is marked mandatory. It is used to enable the 1519 hiding of the values of arbitrary AVPs. It MUST precede any AVP 1520 containing an AVP with the H bit set but it MUST NOT itself have the 1521 H bit set. More than one Random Vector AVP may appear in a message, 1522 in which case the one most closely preceding an AVP with the H bit 1523 set pertains to that AVP. The Random Octet String is the random 1524 vector value to use in computing the MD5 hash to retrieve the 1525 original value of a hidden AVP. This string can be of arbitrary 1526 length, although a random vector of at least 16 octets is 1527 recommended. The only AVP that the Random Vector AVP MUST NOT precede 1528 is the Message Type AVP (which is always the first AVP in a message). 1530 6.0 Control Connection Protocol Specification 1532 Control Connection messages are used to establish and clear user 1533 sessions. The first set of Control Connection messages are used to 1534 maintain the control connection itself. The control connection is 1535 initiated by an LAC or LNS after establishing the underlying tunnel- 1536 over-media connection. 1538 6.0.1 Control Connection Collision 1540 For the case where an LAC and LNS both initiate tunnels to each 1541 other concurrently, and where the LAC and LNS both determine that 1542 a single tunnel suffices (generally because of media 1543 characteristic considerations, for instance, whether individual 1544 tunnels are needed to gain QOS guarantees for each tunnel), a "tie 1545 breaker" may be undertaken. The details of breaking a tie are 1546 documented with the tunnel establishment messages (Sec. 6.1). 1548 6.0.2 Reliable Delivery of Control Messages 1550 Since L2TP may run across media where packets may be lost, an L2TP 1551 peer sending a control message will retransmit the control message 1552 after deciding that its remote peer has not received it. The 1553 reliable transport mechanism built into L2TP is essentially a 1554 lower layer transport service; the Nr and Ns fields of the control 1555 message header belong to this transport layer. The higher layer 1556 functions of L2TP are not concerned with retransmission or 1557 ordering of control messages. 1559 Each tunnel maintains a queue of control messages to be 1560 transmitted to the peer. The message at the front of the queue is 1561 sent with a given Ns value, and is held until a control message 1562 arrives from the peer in which the Nr field indicates receipt of 1563 this message. After a fixed (recommended default is 1 second) or 1564 adaptive (see Appendix D) timeout interval expires without 1565 receiving such an acknowledgment, the control message packet is 1566 retransmitted. The retransmitted packet contains the same Ns 1567 value, but the Nr value MUST be updated with the current value of 1568 Sr to reflect any packets received in the interim. 1570 If no peer response is detected after several retransmissions (a 1571 recommended default is 5, but may be altered due to media 1572 considerations), the tunnel and all sessions within MUST be 1573 cleared. 1575 When a tunnel is being shut down for reasons other than loss of 1576 connectivity, the state and reliable delivery mechanisms MUST be 1577 maintained and operated for the full retransmission interval after 1578 the final message exchange has occurred. This permits reliable 1579 delivery of closing messages in environments where these closing 1580 messages might be dropped. 1582 A peer MUST NOT withhold acknowledgment of packets as a technique 1583 for flow controlling control messages. An L2TP implementation is 1584 expected to be able to keep up with incoming control messages, 1585 possibly responding to some with errors reflecting an inability to 1586 honor the requested action. 1588 A sliding window mechanism is used, by default, for control 1589 message transmission. The default is to permit four control 1590 messages to be outstanding on a given tunnel. If a peer specifies 1591 a Receive Window Size AVP in the Start-Control-Connection-Request 1592 and -Reply packets, up to the indicated number of control messages 1593 may be sent and held outstanding. An implementation may support a 1594 receive window of only 1, but MUST accept a window of 4 or less 1595 from its peer. Unlike payload sessions, a value of 0 for the 1596 Receive Window Size AVP is invalid for a control session. 1598 The transport layer at a receiving peer is responsible for making 1599 sure that control messages are delivered in order to the higher 1600 layer and that duplicate messages are not delivered to the higher 1601 layer. Messages arriving out of order may be queued for in-order 1602 delivery when the missing messages are received or they may be 1603 discarded, requiring a retransmission. 1605 6.0.3 Control Message Format 1607 The following Control Connection messages are all sent as packets 1608 on the established tunnel connection between a given LNS-LAC pair. 1609 All data is sent in network order (high order octets first). Any 1610 "reserved" or "empty" fields MUST be sent as 0 values to allow for 1611 protocol extensibility. 1613 Each control message has a header, specified in section 5.2, 1614 including an AVP indicating the type of control message, followed 1615 by zero or more AVP's appropriate for the given type of control 1616 message. Each control message is described first at a block 1617 level, and then with details of each AVP. 1619 6.1 Start-Control-Connection-Request (SCCRQ) 1621 The Start-Control-Connection-Request is an L2TP control message used 1622 to initialize the tunnel between an LNS and an LAC. The tunnel must 1623 be initialized through the exchange of these control messages before 1624 any other L2TP messages can be issued. The establishment of the 1625 control connection is started by the initiator of the underlying 1626 tunnel. 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | L2TP Control Message Header | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | Start-Control-Connection-Request | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Protocol Version | 1634 | Framing Capabilities | 1635 | Bearer Capabilities | 1636 | Tie Breaker | 1637 | Firmware Revision | 1638 | Host Name | 1639 | Vendor Name | 1640 | Assigned Tunnel ID | 1641 | Receive Window Size | 1642 | Challenge | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+ 1644 Start-Control-Connection-Request 1646 0 1 2 3 1647 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 |1|0|0|0|0|0| 8 | 0 | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | 0 | 1 | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 The Message Type AVP contains a Value of 1, indicating Start- 1655 Control-Connection-Request. The Flags indicate a mandatory 1656 option. Details associated with this tunneled session follow in 1657 additional AVP's within the packet. 1659 Protocol Version 1661 0 1 2 3 1662 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 |1|0|0|0|0|0| 8 | 0 | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 | 2 | 0x01 | 0x00 | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 The Protocol Version AVP within a Start-Control-Connection-Request 1670 packet indicates the L2TP protocol version available. The 1671 Attribute value is 2, indicating Protocol Version, and is marked 1672 mandatory. This AVP MUST be present. The Value field is a 16-bit 1673 hexadecimal value 0x100, indicating L2TP protocol version 1, 1674 revision 0. 1676 Framing Capabilities 1678 0 1 2 3 1679 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 |1|0|0|0|0|0| 10 | 0 | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | 3 | 0x00 | 0x00 | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | 0x00 |0|0|0|0|0|0|A|S| 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 The Framing Capabilities AVP within a Start-Control-Connection- 1689 Request indicates the type of framing that the sender of this 1690 message can provide. The Attribute value is 3, indicating Framing 1691 Capabilities, and is marked mandatory. This AVP MUST be present. 1692 The Value field is a 32-bit quantity, with two bits defined. If 1693 bit A is set, asynchronous framing is supported. If bit S is set, 1694 synchronous framing is supported. 1696 This AVP provides the peer with an indication of the types of 1697 framing that will be accepted or initiated by the sender. A peer 1698 should not initiate an incoming or outgoing call with a Framing 1699 Type AVP specifying a value not advertised in the Framing 1700 Capabilities AVP it received during control connection 1701 establishment. Attempts to do so will result in the call being 1702 rejected. 1704 Bearer Capabilities 1706 0 1 2 3 1707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 |1|0|0|0|0|0| 10 | 0 | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | 4 | 0x00 | 0x00 | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | 0x00 |0|0|0|0|0|0|A|D| 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 The Bearer Capabilities AVP within a Start-Control-Connection- 1717 Request indicates the bearer capabilities that the sender of this 1718 message can provide for outgoing calls. The Attribute value is 4, 1719 indicating Bearer Capabilities, and is marked mandatory. This AVP 1720 MUST be present if the sender can place outgoing calls when 1721 requested. The Value field is a 32-bit quantity with two bits 1722 defined. If bit A is set, analog access is supported. If bit D 1723 is set, digital access is supported. 1725 This AVP provides the peer with an indication of the bearer device 1726 types supported by the hardware interfaces of the sender for 1727 outgoing calls. An LNS should not initiate an outgoing call 1728 specifying a value in the Bearer Type AVP for a device type not 1729 advertised in the Bearer Capabilities AVP it received from the LAC 1730 during control connection establishment. Attempts to do so will 1731 result in the call being rejected. 1733 Note that an LNS that cannot act as an LAC as well will not 1734 support hardware devices for handling incoming and outgoing calls 1735 and should therefore set the A and D bits in the Value field of 1736 this AVP to 0, or should not send the AVP at all. An LNS that can 1737 also act as an LAC and place outgoing calls should set the 1738 appropriate bits in the Value field of this AVP. Presence of this 1739 message is not a guarantee that a given outgoing call will be 1740 placed by the sender if requested, just that the physical 1741 capability exists. 1743 Tie Breaker 1745 0 1 2 3 1746 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 |0|0|0|0|0|0| 14 | 0 | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | 5 | Tie Break Value... | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Value... | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | ...(64 bits) | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 The Tie Breaker AVP within a Start-Control-Connection-Request 1758 contains a 64-bit Value used to break ties in tunnel establishment 1759 between an LAC-LNS pair. The Attribute value is 5, indicating Tie 1760 Breaker, and is marked optional. This AVP itself is optional. 1761 The 8 octet Value is used as a 64-bit tie breaker value. 1763 If present, it indicates the sender wishes a single tunnel to 1764 exist between the given LAC-LNS pair, and this value will be used 1765 to choose a single tunnel where both LAC and LNS initiate a tunnel 1766 concurrently. The recipient of a Start-Control-Connection-Request 1767 must check to see if a Start-Control-Connection-Request has been 1768 sent to the peer, and if so, must compare its Tie Breaker value 1769 with the received one. The lower value "wins", and the "loser" 1770 MUST silently discard its tunnel. In the case where a tie breaker 1771 is present on both sides, and the value is equal, both sides MUST 1772 discard their tunnels. 1774 If a tie breaker is received, and the outstanding Start-Control- 1775 Connection-Request had no tie breaker value, the initiator which 1776 included the Tie Breaker AVP "wins". If neither side issues a Tie 1777 breaker, then two separate tunnels are opened. 1779 It is recommended that the Value be set to the MAC address of a 1780 LAN interface on the sender. If no MAC address is available, a 1781 64-bit random number should be used instead. 1783 Firmware Revision 1785 0 1 2 3 1786 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 |0|0|0|0|0|0| 8 | 0 | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | 6 | Firmware Revision | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 The Firmware Revision AVP within a Start-Control-Connection- 1794 Request indicates the firmware revision of the issuing device. 1795 The Attribute value is 6, indicating Firmware Revision, and is 1796 marked optional. This AVP itself is optional. The Value field is 1797 a 16-bit integer encoded in a vendor specific format. For devices 1798 which do not have a firmware revision (general purpose computers 1799 running L2TP software modules, for instance), the revision of the 1800 L2TP software module may be reported instead. 1802 Host Name 1804 0 1 2 3 1805 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 |1|0|0|0|0|0| 6 + Host name len | 0 | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | 7 | Host name... 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 The Host Name AVP within a Start-Control-Connection-Request 1813 indicates the name of the issuing LAC or LNS. The Attribute value 1814 is 7, indicating Host Name, and is marked mandatory. This AVP 1815 itself MUST be present. This name should be as broadly unique as 1816 possible; for hosts participating in DNS [4], a hostname with 1817 fully qualified domain would be appropriate. 1819 Vendor Name 1821 0 1 2 3 1822 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 3|0|0|0|0|0|0| 6+Vendor Name len| 0 | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 | 8 | Vendor name... 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 The Vendor Name AVP within a Start-Control-Connection-Request 1830 contains a vendor specific string describing the type of LAC or 1831 LNS being used. The Attribute value is 8, indicating Vendor Name, 1832 and is marked optional. This AVP itself is optional. The Value 1833 is the indicated number of octets representing the vendor string. 1835 Assigned Tunnel ID 1837 0 1 2 3 1838 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 |1|0|0|0|0|0| 8 | 0 | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | 9 | Tunnel ID | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 The Assigned Tunnel ID AVP within a Start-Control-Connection- 1846 Request specifies the Tunnel ID which the receiving peer MUST use 1847 in the Tunnel ID field of all subsequent packets. The Attribute 1848 value is 9, indicating Assigned Tunnel ID, and is marked 1849 mandatory. This AVP MUST be present. Before the Assigned Tunnel 1850 ID AVP is received, packets MUST be sent with a Tunnel ID value of 1851 0. The Value is a 16-bit non-zero Tunnel ID value. 1853 Receive Window Size 1855 0 1 2 3 1856 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 |1|0|0|0|0|0| 8 | 0 | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | 10 | Size | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 The Receive Window Size AVP within a Start-Control-Connection- 1864 Request specifies the receive window size being offered to the 1865 remote peer. The Attribute value is 10, indicating Receive Window 1866 Size, and is mandatory. This AVP itself is optional. Value is a 1867 16-bit word indicating the offered window size. If absent, the 1868 peer must assume a value of 4 for its transmit window. The remote 1869 peer may send the specified number of control messages before it 1870 must wait for an acknowledgment. 1872 Challenge 1874 0 1 2 3 1875 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 |1|0|0|0|0|0| 6 + Challenge len | 0 | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | 11 | Challenge... 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 The Challenge AVP within a Start-Control-Connection-Request 1883 indicates that the issuing peer wishes to authenticate the tunnel 1884 endpoints using a CHAP-style authentication mechanism. The 1885 Attribute value is 11, indicating Challenge, and is marked 1886 mandatory. This AVP is optional. The Value is one or more octets 1887 of challenge value. 1889 6.2 Start-Control-Connection-Reply (SCCRP) 1891 The Start-Control-Connection-Reply is an L2TP control message sent in 1892 reply to a received Start-Control-Connection-Request message. Sending 1893 this message indicates that the request was successful. 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | L2TP Control Message Header | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | Start-Control-Connection-Reply | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | Protocol Version | 1901 | Framing Capabilities | 1902 | Bearer Capabilities | 1903 | Firmware Revision | 1904 | Host Name | 1905 | Vendor Name | 1906 | Assigned Tunnel ID | 1907 | Receive Window Size | 1908 | Challenge | 1909 | Challenge Response | 1910 +-+-+-+-+-+-+-+-+-+-+-+-+ 1912 Start-Control-Connection-Reply 1914 0 1 2 3 1915 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 |1|0|0|0|0|0| 8 | 0 | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | 0 | 2 | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 The Message Type AVP contains a Value of 2, indicating Start- 1923 Control-Connection-Reply. The Flags indicate a mandatory option. 1925 Protocol Version 1927 0 1 2 3 1928 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 |1|0|0|0|0|0| 8 | 0 | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | 2 | 0x01 | 0x00 | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 The Protocol Version AVP within a Start-Control-Connection-Reply 1936 packet indicates the L2TP protocol version available. The 1937 Attribute value is 2, indicating Protocol Version, and the Value 1938 field is a 16-bit hexadecimal value 0x100, indicating L2TP 1939 protocol version 1, revision 0. This AVP MUST be present. 1941 Framing Capabilities 1943 0 1 2 3 1944 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 |1|0|0|0|0|0| 10 | 0 | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | 3 | 0x00 | 0x00 | 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 | 0x00 |0|0|0|0|0|0|A|S| 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 The Framing Capabilities AVP within a Start-Control-Connection- 1954 Reply indicates the type of framing that the sender of this 1955 message can provide. The Attribute is 3, it is a mandatory AVP, 1956 the Value field is a 32-bit quantity, with two bits defined. If 1957 bit A is set, asynchronous framing is supported. If bit S is set, 1958 synchronous framing is supported. This AVP MUST be present. 1960 More details on the use of this AVP can be found in Sec. 6.1. 1962 Bearer Capabilities 1964 0 1 2 3 1965 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 |1|0|0|0|0|0| 10 | 0 | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | 4 | 0x00 | 0x00 | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | 0x00 |0|0|0|0|0|0|A|D| 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 The Bearer Capabilities AVP within a Start-Control-Connection- 1975 Reply indicates the bearer capabilities that the sender of this 1976 message can provide for outgoing calls. The Attribute is 4, it is 1977 a mandatory AVP, the Value field is a 32-bit quantity with two 1978 bits defined. If bit A is set, analog access is supported. If 1979 bit D is set, digital access is supported. This AVP MUST be 1980 present if outgoing calls can be placed by the sender of this 1981 message. 1983 More details on the use of this AVP can be found in Sec. 6.1. 1985 Firmware Revision 1987 0 1 2 3 1988 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 |0|0|0|0|0|0| 8 | 0 | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 | 6 | Firmware Revision | 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 The Firmware Revision AVP within a Start-Control-Connection-Reply 1995 indicates the firmware revision of the issuing device. The 1996 Attribute is 6, it is not a mandatory AVP, the Value field is a 1997 16-bit integer encoded in a vendor specific format. For devices 1998 which do not have a firmware revision (general purpose computers 1999 running L2TP software modules, for instance), the revision of the 2000 L2TP software module may be reported instead. This AVP is 2001 optional. 2003 Host Name 2005 0 1 2 3 2006 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 |1|0|0|0|0|0| 6 + Host Name len | 0 | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | 7 | Host Name... 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 The Host Name AVP within a Start-Control-Connection-Reply 2014 indicates the name of the issuing LAC or LNS. See the notes in 2015 section 6.1 concerning Host Name contents. It is encoded as the 2016 Attribute 7, mandatory, with the indicated number of octets 2017 representing the host name string. This AVP MUST be present. 2019 Vendor Name 2021 0 1 2 3 2022 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 |0|0|0|0|0|0| 6+Vendor Name len | 0 | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 | 8 |Vendor Name... 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 The Vendor Name AVP within a Start-Control-Connection-Reply 2030 contains a vendor specific string describing the type of LAC or 2031 LNS being used. It is encoded as the Attribute 8, not mandatory, 2032 with the indicated number of octets representing the vendor 2033 string. This AVP is optional. 2035 Assigned Tunnel ID 2037 0 1 2 3 2038 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 |1|0|0|0|0|0| 8 | 0 | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | 9 | Tunnel ID | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply 2046 specifies the Tunnel ID which the receiving peer MUST use in all 2047 subsequent packets. It is encoded as the Attribute 9, mandatory, 2048 with a 16-bit non-zero Tunnel ID value. This AVP MUST be present. 2050 Receive Window Size 2052 0 1 2 3 2053 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 |1|0|0|0|0|0| 8 | 0 | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | 10 | size | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 The Receive Window Size AVP within a Start-Control-Connection- 2061 Reply specifies the receive window size being offered to the 2062 remote peer. The Attribute value is 10, indicating Receive Window 2063 Size, and is mandatory. This AVP itself is optional. Value is a 2064 16-bit word indicating the offered window size. If absent, the 2065 peer must assume a value of 4 for its transmit window. The remote 2066 peer may send the specified number of control messages before it 2067 must wait for an acknowledgment. 2069 Challenge 2071 0 1 2 3 2072 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 |1|0|0|0|0|0| 6 + Challenge len | 0 | 2075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 | 11 | Challenge... 2077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 The Challenge AVP within a Start-Control-Connection-Reply 2080 indicates that the peer wishes to authenticate the tunnel 2081 initiator using a CHAP-style authentication mechanism. It is 2082 encoded as the Attribute 11, mandatory, with at least one octet of 2083 challenge value embedded. If this AVP is not present, it 2084 indicates to the receiving peer that the sender does not wish to 2085 authenticate that peer. 2087 Challenge Response 2089 0 1 2 3 2090 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 |1|0|0|0|0|0| 22 | 0 | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | 13 | Response... | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | Response... (128 bits) | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 The Response AVP within a Start-Control-Connection-Reply packet 2100 provides a response to a challenge received. The Attribute value 2101 is 13, indicating Response, and the Value field is a 128-bit value 2102 reflecting the CHAP-style response to the challenge. This AVP 2103 marked mandatory, and MUST be present if a challenge was received 2104 and this Start-Control-Connection-Reply indicates success. For 2105 purposes of the ID value in the CHAP response calculation, the 2106 value 2 (corresponding to the Value field of the Start-Control- 2107 Connection-Reply AVP) MUST be used. 2109 6.3 Start-Control-Connection-Connected (SCCCN) 2111 The Start-Control-Connection-Connected message is an L2TP control 2112 message sent in reply to a received Start-Control-Connection-Reply 2113 message. This message provides closure to the tunnel establishment 2114 process, and includes a challenge response if the peer sent a 2115 challenge in the Start-Control-Connection-Reply message. 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | L2TP Control Message Header | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 | Start-Control-Connection-Connected | 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 | Challenge Response | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+ 2125 Start-Control-Connection-Connected 2127 0 1 2 3 2128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 |1|0|0|0|0|0| 8 | 0 | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | 0 | 3 | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 The Message Type AVP contains a Value of 3, indicating Start- 2136 Control-Connection-Connected. The Flags indicate a mandatory 2137 option. 2139 Challenge Response 2141 0 1 2 3 2142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 |1|0|0|0|0|0| 22 | 0 | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | 13 | Response... | 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | Response... (128 bits) | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 The Challenge Response AVP within a Start-Control-Connection- 2152 Connected packet provides a response to a challenge received. The 2153 Attribute value is 13, indicating Response, and the Value field is 2154 a 128-bit value reflecting the CHAP-style response to the 2155 challenge. This AVP is marked mandatory, and MUST be present if a 2156 challenge was received, otherwise MUST be omitted. For purposes 2157 of the ID value in the CHAP response calculation, the value 3 2158 (corresponding to the Value field of the Start-Control- 2159 Connection-Connected AVP) MUST be used. 2161 6.4 Stop-Control-Connection-Notification (StopCCN) 2163 The Stop-Control-Connection-Notification is an L2TP control message 2164 sent by one peer of an LAC-LNS control connection to inform the other 2165 peer that the control connection should be closed. In addition to 2166 closing the control connection, all active user calls are implicitly 2167 cleared. The reason for issuing this request is indicated in the 2168 Result Code AVP. 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 | L2TP Control Message Header | 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | Stop-Control-Connection-Notification| 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | Assigned Tunnel ID | 2176 | Result Code | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+ 2179 Stop-Control-Connection-Notification AVP 2181 0 1 2 3 2182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 |1|0|0|0|0|0| 8 | 0 | 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 | 0 | 4 | 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 The Message Type AVP contains a Value of 4, indicating Stop- 2190 Control-Connection-Notification. The Flags indicate a mandatory 2191 option. 2193 Assigned Tunnel ID 2195 0 1 2 3 2196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 |1|0|0|0|0|0| 8 | 0 | 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 | 9 | Tunnel ID | 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 The Attribute value is 9, indicating Assigned Tunnel ID, and is 2204 marked mandatory. This AVP MUST be present. The Value MUST be 2205 the same Assigned Tunnel ID first sent to the receiving peer. 2206 This AVP permits the peer to identify the appropriate tunnel even 2207 if Stop-Control-Connection-Notification must be sent before an 2208 Assigned Tunnel ID is received. 2210 Result Code 2212 0 1 2 3 2213 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 |1|0|0|0|0|0| 10 + Message len | 0 | 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 | 1 | Result Code | 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 | Error Code | Optional Message ... 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 The Result Code AVP within a Stop-Control-Connection-Notification 2223 packet indicates the reason for terminating the control channel. 2224 It is encoded as Attribute 1, indicating a Result Code AVP. This 2225 AVP is mandatory and MUST be present. The Result Code is a 16-bit 2226 word. The 16-bit word following the Result Code field contains 2227 the Error Code value, which for a Stop-Control-Connection- 2228 Notification is always 0. An optional message can follow the 2229 Error Code field. Its presence and length is indicated by the 2230 value of the AVP length field. Defined Result Code values are: 2232 1 - General request to clear control connection 2233 2 - General error--Error Code indicates the problem 2234 3 - Control channel already exists 2235 4 - Requester is not authorized to establish a control channel 2236 5 - The protocol version of the requester is not supported 2237 Error Code indicates highest version supported 2238 6 - Requester is being shut down 2239 7 - Finite State Machine error 2241 6.5 Hello 2243 The Hello message is an L2TP control message sent by either peer of a 2244 LAC-LNS control connection. This control message is used as a 2245 "keepalive" for the tunnel. 2247 The sending of Hello messages and the policy for sending them are 2248 left up to the implementation. A peer MUST NOT "expect" Hello 2249 messages at any time or interval. When a Hello is received, it MUST 2250 be silently discarded (after updating any effects of the indicated 2251 Nr/Ns values). 2253 Keepalives for the tunnel MAY be implemented by sending a Hello once 2254 every 60 seconds if 60 seconds have passed without receiving any 2255 message (payload or control, including zero-length messages) from the 2256 peer. 2258 Because a Hello is a control message, and control messages are 2259 reliably sent by the lower level transport, this keepalive function 2260 operates by causing the transport level to reliably deliver a 2261 message. If a media interruption has occurred, the reliable 2262 transport will be unable to deliver the Hello across, and will clean 2263 up the tunnel. 2265 Hello messages are global to the tunnel; the Call ID field of these 2266 control messages MUST be 0. 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | L2TP Control Message Header | 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 | Hello | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 Hello 2276 0 1 2 3 2277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 |1|0|0|0|0|0| 8 | 0 | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | 0 | 6 | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 The Message Type AVP contains a Value of 6, indicating Hello The 2285 Flags indicate a mandatory option. 2287 6.6 Outgoing-Call-Request (OCRQ) 2289 The Outgoing-Call-Request is an L2TP control message sent by the LNS 2290 to the LAC to indicate that an outbound call from the LNS is to be 2291 established. This request provides the LAC with information required 2292 to make the call. It also provides information to the LAC that is 2293 used to regulate the transmission of data to the LNS for this session 2294 once it is established. 2296 This message is the first in the "three-way handshake" used by L2TP 2297 for establishing outgoing calls. The first message requests the 2298 call; the second indicates that the call was successfully initiated. 2299 The third and final message indicates that the call was established. 2301 An LNS MUST have received a Bearer Capabilities AVP during tunnel 2302 establishment from an LAC in order to request an outgoing call to 2303 that LAC. 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 | L2TP Control Message Header | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | Outgoing-Call-Request | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2310 | Assigned Call ID | 2311 | Call Serial Number | 2312 | Minimum BPS | 2313 | Maximum BPS | 2314 | Bearer Type | 2315 | Framing Type | 2316 | Receive Window Size | 2317 | Packet Processing Delay | 2318 | Dialed Number | 2319 | Sub-Address | 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 Outgoing-Call-Request 2324 0 1 2 3 2325 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 |1|0|0|0|0|0| 8 | 0 | 2328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2329 | 0 | 7 | 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 The Message Type AVP contains a Value of 7, indicating Outgoing- 2333 Call-Request. The Outgoing-Call-Request encodes a request to an 2334 LAC to establish an outgoing call. The flags indicate a mandatory 2335 option. 2337 Assigned Call ID 2339 0 1 2 3 2340 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 |1|0|0|0|0|0| 8 | 0 | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | 14 | Call ID | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 The Assigned Call ID AVP encodes the ID being assigned to this 2348 call by the LNS. The Attribute value is 14, indicating Assigned 2349 Call ID, and is marked mandatory. This AVP MUST be present. The 2350 LAC places this value in the Call ID header field of all command 2351 and payload packets that it subsequently transmits over the tunnel 2352 that belong to this call. The Call ID value is an identifier 2353 assigned by the LNS to this session. It is used to multiplex and 2354 demultiplex data sent over that tunnel between the LNS and LAC. 2356 Call Serial Number 2358 0 1 2 3 2359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 |1|0|0|0|0|0| 10 | 0 | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 | 15 | CSN (H) | 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 | CSN (L) | 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 Call Serial Number AVP encodes an identifier assigned by the LNS to 2369 this call. Attribute is 15, indicating Call Serial Number, and is 2370 marked mandatory. This AVP MUST be present. The Call Serial Number 2371 is intended to be an easy reference for administrators on both ends of 2372 a tunnel to use when investigating call failure problems. Call Serial 2373 Numbers should be set to progressively increasing values, which are 2374 likely to be unique for a significant period of time across all 2375 interconnected LNS and LACs. Other identification information may 2376 also be prepended. 2378 Minimum BPS 2380 0 1 2 3 2381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 |1|0|0|0|0|0| 10 | 0 | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | 16 | BPS (H) | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 | BPS (L) | 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 Minimum BPS AVP encodes the lowest acceptable line speed for this 2391 call. Attribute is 16, Minimum BPS, and is marked mandatory. 2392 This AVP MUST be present. The BPS value indicates the speed in 2393 bits/second. 2395 Maximum BPS 2397 0 1 2 3 2398 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 |1|0|0|0|0|0| 10 | 0 | 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 | 17 | BPS (H) | 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 | BPS (L) | 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 Maximum BPS AVP encodes the highest acceptable line speed for this 2408 call. Attribute is 17, indicating Maximum BPS, and is marked 2409 mandatory. This AVP MUST be present. The BPS value indicates the 2410 speed in bits/second. 2412 Bearer Type 2414 0 1 2 3 2415 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2417 |1|0|0|0|0|0| 10 | 0 | 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 Bearer Type AVP encodes the bearer type for the requested call. 2425 The Attribute is 18, indicating Bearer Type, and is marked 2426 mandatory. This AVP MUST be present. The Value is a 32-bit 2427 quantity indicating the bearer capability required for this 2428 outgoing call. If set, bit A indicates that the call should be on 2429 an analog channel. If set, bit D indicates that the call should 2430 be on a digital channel. Both may be set, indicating that the 2431 call can be of either type. 2433 A particular bit in the Value field of this AVP MAY only be set by 2434 the LNS if it was set in the Bearer Capabilities AVP received from 2435 the LAC during control session establishment. 2437 Framing Type 2439 0 1 2 3 2440 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 |1|0|0|0|0|0| 10 | 0 | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 Framing Type AVP encodes the framing type for the requested call. 2450 Attribute is 19, indicating Framing Type, and is marked mandatory. 2451 This AVP MUST be present. The 32-bit field indicates the type of 2452 PPP framing to be used for the outgoing call. If set, Bit A 2453 indicates that asynchronous framing should be used. If set, Bit S 2454 indicates that synchronous framing should be used. Both may be 2455 set, indicating that either type of framing may be used for the 2456 call. 2458 A particular bit in the Value field of this AVP MAY only be set by 2459 the LNS if it was set in the Framing Capabilities AVP received 2460 from the LAC during control session establishment. 2462 Receive Window Size 2464 0 1 2 3 2465 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2467 |1|0|0|0|0|0| 8 | 0 | 2468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 | 10 | Size | 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 Receive Window Size AVP encodes the window size being advertised 2473 by the LNS for this call. Attribute is 10, indicating Receive 2474 Window Size, and is marked mandatory. This AVP is optional. The 2475 Size value indicates the number of received data packets the LNS 2476 will buffer for this call, which is also the maximum number of 2477 data packets the LAC should send before waiting for an 2478 acknowledgment. The absence of this AVP indicates that Sequence 2479 and Acknowledgment Numbers are not to be used in the payload 2480 session for this call. 2482 Packet Processing Delay 2484 0 1 2 3 2485 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 |1|0|0|0|0|0| 8 | 0 | 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 | 20 | Delay | 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 The Packet Processing Delay AVP encodes the delay that is expected 2493 at the LNS in processing a window full of packets sent by the LAC. 2494 Attribute is 20, indicating Packet Processing Delay, and is marked 2495 mandatory. This AVP is optional. The Delay value is specified in 2496 units of 1/10 seconds. Refer to Appendix A for a description of 2497 how this value is determined and used. 2499 Dialed Number 2501 0 1 2 3 2502 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 |1|0|0|0|0|0| 6+Phone Number len| 0 | 2505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 | 21 | Phone Number.. 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 Phone Number AVP encodes the phone number to be called. Attribute 2510 is 21, indicating Phone Number, and is marked mandatory. This AVP 2511 MUST be present. The Phone Number value is an ASCII string. 2512 Contact between the administrator of the LAC and the LNS may be 2513 necessary to coordinate the value needed in this AVP. 2515 Sub-Address 2517 0 1 2 3 2518 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 |1|0|0|0|0|0| 6+Sub-Address len | 0 | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 | 23 |Sub-Address ... 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 Sub-Address AVP encodes additional dialing information. Attribute 2526 is 23, indicating Sub-Address, and is marked mandatory. This AVP 2527 is optional. The Sub-Address value is an ASCII string. Contact 2528 between the administrator of the LAC and the LNS may be necessary 2529 to coordinate the value needed in this AVP. 2531 6.7 Outgoing-Call-Reply (OCRP) 2533 The Outgoing-Call-Reply is an L2TP control message sent by the LAC to 2534 the LNS in response to a received Outgoing-Call-Request message. The 2535 reply indicates that the LAC is able to attempt the outbound call and 2536 also returns certain parameters regarding the call attempt. 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 | L2TP Control Message Header | 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 | Outgoing-Call-Reply | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Assigned Call ID | 2544 | Physical Channel Id | 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 Outgoing-Call-Reply 2549 0 1 2 3 2550 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 |1|0|0|0|0|0| 8 | 0 | 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | 0 | 8 | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 The Message Type AVP contains a Value of 8, indicating Outgoing- 2558 Call-Reply. The Outgoing-Call-Reply message encodes the immediate 2559 result of attempting an outgoing call request. The flags indicate a 2560 mandatory option. 2562 Assigned Call ID 2564 0 1 2 3 2565 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 |1|0|0|0|0|0| 8 | 0 | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | 14 | Call ID | 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 The Assigned Call ID AVP encodes the ID being assigned to this call 2573 by the LAC. Attribute is 14, indicating Assigned Call ID, and is 2574 marked mandatory. This AVP MUST be present. Call ID value is an 2575 identifier, unique within the tunnel, assigned by the sender to this 2576 session. The remote peer MUST place this Call ID in the Call ID 2577 portion of all future packets it sends associated with this session. 2578 It is used to multiplex and demultiplex data sent over that tunnel 2579 between the LNS and LAC. 2581 Physical Channel ID 2583 0 1 2 3 2584 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 |0|0|0|0|0|0| 10 | 0 | 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 | 25 | ID (H) | 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2590 | ID (L) | 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 Physical Channel ID AVP encodes the vendor specific physical channel 2594 number used for the call. The Attribute value is 25, indicating 2595 Physical Channel ID, and is marked optional. This AVP itself is 2596 optional. ID is a 32-bit value in network byte order. The value is 2597 used for logging purposes only. 2599 6.8 Outgoing-Call-Connected (OCCN) 2601 Outgoing-Call-Connected is an L2TP control message sent by the LAC to 2602 the LNS to indicate that the result of a requested outgoing call was 2603 successful. The LAC MUST send the corresponding Outgoing-Call-Reply 2604 to the LNS before sending this message. This message provides 2605 information to the LNS about the particular parameters used for the 2606 call. It provides information to allow the LNS to regulate the 2607 transmission of data to the LAC for this session. 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | L2TP Control Message Header | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | Outgoing-Call-Connected | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 | (Tx) Connect Speed | 2615 | Framing Type | 2616 | Receive Window Size | 2617 | Packet Processing Delay | 2618 | Rx Connect Speed | 2619 | Sequencing Required | 2620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2622 Outgoing-Call-Connected 2624 0 1 2 3 2625 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 |1|0|0|0|0|0| 8 | 0 | 2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2629 | 0 | 9 | 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 The Message Type AVP contains a Value of 9, indicating Outgoing- 2633 Call-Connected. The Outgoing-Call-Connected message encodes the 2634 final result of an outgoing call request. The flags indicate a 2635 mandatory option. 2637 (Tx) Connect Speed 2639 0 1 2 3 2640 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 |1|0|0|0|0|0| 10 | 0 | 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 | 24 | BPS (H) | 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 | BPS (L) | 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2649 (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen 2650 for the connection attempt. The Attribute value is 24, indicating 2651 (Tx) Connect Speed, and is marked mandatory. This AVP MUST be 2652 present. BPS is a 32-bit value indicating the speed in bits/second. 2654 When the optional Rx Connect Speed AVP is present, the value in this 2655 AVP represents the transmit connect speed, from the perspective of 2656 the LAC (e.g. data flowing from the LAC to the client). When the 2657 optional Rx Connect Speed AVP is NOT present, the connection speed 2658 between the client and LAC is assumed to be symmetric and is 2659 represented by the single value in this AVP. 2661 Framing Type 2663 0 1 2 3 2664 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2666 |1|0|0|0|0|0| 10 | 0 | 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2670 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 Framing Type AVP encodes the framing type for the call. The 2674 Attribute value is 19, indicating Framing Type, and is marked 2675 mandatory. This AVP MUST be present. The bit field indicates the 2676 type of PPP framing used for the call. If set, bit A indicates that 2677 asynchronous framing is being used. If set, bit S indicates that 2678 synchronous framing is being used. A particular type of framing may 2679 be used only if it was specified in the Framing Type AVP of the 2680 Outgoing-Call-Request issued by the LNS. The framing type MAY be used 2681 as an indication to PPP on the LNS as to what link options to use for 2682 LCP (refer to "PPP in HDLC-like Framing" [14]). 2684 Receive Window Size 2686 0 1 2 3 2687 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2689 |1|0|0|0|0|0| 8 | 0 | 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | 10 | Size | 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 Receive Window Size AVP encodes the window size being offered by the 2695 LNS for this call. The Attribute value is 10, indicating Receive 2696 Window Size, and is marked mandatory. The Size is a 16-bit value 2697 indicating the number of received data packets the LAC will buffer 2698 for this call, which is also the maximum number of data packets the 2699 LNS should send before waiting for an acknowledgment. This AVP is 2700 present only if Sequence and Acknowledgment Numbers are to be used in 2701 the payload session for this call. 2703 Packet Processing Delay 2705 0 1 2 3 2706 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 |1|0|0|0|0|0| 8 | 0 | 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 | 20 | Delay | 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 Packet Processing Delay AVP encodes the delay the LAC expects for 2714 processing a window full of packets sent by the LNS. The Attribute 2715 value is 20, indicating Packet Processing Delay, and is marked 2716 mandatory. This AVP is optional. The Delay value is specified in 2717 units of 1/10 seconds. Refer to Appendix A to see a description of 2718 how this value is determined and used. 2720 Rx Connect Speed 2722 0 1 2 3 2723 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 |0|0|0|0|0|0| 10 | 0 | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | 38 | BPS (H) | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | BPS (L) | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 Rx Connect Speed BPS AVP encodes the receive speed of the facility 2733 chosen for the connection attempt. The Attribute value is 38, 2734 indicating Rx Connect Speed, and is marked optional. The Rx Connect 2735 Speed represents the speed of the connection from the perspective of 2736 the LAC (e.g. data flowing from the client to the LAC). Presence of 2737 this AVP implies that the connection speed may be asymmetric, with 2738 the transmit connect speed given in the (Tx) Connect Speed AVP. BPS 2739 is a 32-bit value indicating the speed in bits/second. 2741 Sequencing Required 2743 0 1 2 3 2744 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 |1|0|0|0|0|0| 6 | 0 | 2747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2748 | 39 | 2749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2751 The Sequencing Required AVP indicates to the LNS that Sequence 2752 Numbers MUST always be present, thus the ability to dynamically drop 2753 sequencing as described in section 4.2 is not an available option. 2754 The Attribute value is 38, Sequencing Required, and is marked 2755 mandatory. The presence of this AVP is optional. This AVP MUST NOT 2756 be present if the Receive Window Size AVP is not present. There is no 2757 value field. 2759 6.9 Incoming-Call-Request (ICRQ) 2761 Incoming-Call-Request is an L2TP control message sent by the LAC to 2762 the LNS to indicate that an inbound call is to be established from 2763 the LAC. This request provides the LNS with parameter information 2764 for the incoming call. 2766 This message is the first in the "three-way handshake" used by L2TP 2767 for establishing incoming calls. The LAC may defer answering the 2768 call until it has received an Incoming-Call-Reply from the LNS 2769 indicating that the call should be established. This mechanism 2770 allows the LNS to obtain sufficient information about the call before 2771 determining whether the call should be answered or not. 2772 Alternatively, the LAC may answer the call, negotiate LCP and PPP 2773 authentication, and use the information gained to choose the LNS. In 2774 this case, the call has already been answered by the time the 2775 Incoming-Call-Reply message is received; the LAC simply spoofs the 2776 "call indication/answer call" phase in this case. 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | L2TP Control Message Header | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 | Incoming-Call-Request | 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 | Assigned Call ID | 2784 | Call Serial Number | 2785 | Bearer Type | 2786 | Physical Channel ID | 2787 | Dialed Number | 2788 | Dialing Number | 2789 | Sub-Address | 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 Incoming-Call-Request 2794 0 1 2 3 2795 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2797 |1|0|0|0|0|0| 8 | 0 | 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 | 0 | 10 | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 The Message Type AVP contains a Value of 10, indicating Incoming- 2803 Call-Request. The Incoming-Call-Request message encodes an incoming 2804 call being indicated by the LAC. The flags indicate a mandatory 2805 option. 2807 Assigned Call ID 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| 8 | 0 | 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2814 | 14 | Call ID | 2815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2817 The Assigned Call ID AVP encodes the ID being assigned to this call 2818 by the LAC. The Attribute value is 14, indicating Assigned Call ID, 2819 and is marked mandatory. This AVP MUST be present. The LNS places 2820 this value in the Call ID header field of all command and payload 2821 packets that belong to this call and are subsequently transmitted 2822 over the tunnel. The Call ID value is an identifier assigned by the 2823 LAC to this session. It is used to multiplex and demultiplex data 2824 sent over that tunnel between the LNS and LAC. 2826 Call Serial Number 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 | 15 | CSN (H) | 2834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 | CSN (L) | 2836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2838 Call Serial Number AVP encodes an identifier assigned by the LAC to 2839 this call. The Attribute value is 15, Call Serial Number, and is 2840 marked mandatory. This AVP MUST be present. Please refer to section 2841 6.6 for a description of the contents of this AVP. 2843 Bearer Type 2845 0 1 2 3 2846 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2848 |1|0|0|0|0|0| 10 | 0 | 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2850 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2855 Bearer Type AVP encodes the bearer type for the incoming call. The 2856 Attribute value is 18, Bearer Type, and is marked mandatory. This 2857 AVP is optional. The Value is a 32-bit field indicating the bearer 2858 capability being used by the incoming call. If set, bit A indicates 2859 that the call is on an analog channel. If set, bit D indicates that 2860 the call is on a digital channel. It is valid to set neither the A 2861 nor D bits. Such a setting may indicate that the call was not 2862 received over a physical link (e.g if the LAC and PPP are located in 2863 the same subsystem). 2865 Physical Channel ID 2867 0 1 2 3 2868 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2870 |1|0|0|0|0|0| 10 | 0 | 2871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2872 | 25 | ID (H) | 2873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2874 | ID (L) | 2875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 Physical Channel ID AVP encodes the vendor specific physical channel 2877 number used for the call. The Attribute value is 25, Physical 2878 Channel ID, and is marked mandatory. The presence of this AVP is 2879 optional. ID is a 32-bit value in network byte order. The value is 2880 used for logging purposes only. 2882 Dialed Number 2884 0 1 2 3 2885 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 |1|0|0|0|0|0| 6+Phone Number len| 0 | 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 | 21 | Phone Number.. 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 Dialed Number AVP encodes the dialed number for the incoming call, 2893 that is, DNIS. The Attribute value is 21, Dialed Number, and is 2894 marked mandatory. The presence of this AVP is optional. The value 2895 is an ASCII string. 2897 Dialing Number 2899 0 1 2 3 2900 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 |1|0|0|0|0|0| 6+Phone Number len| 0 | 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2904 | 22 |Phone Number... 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 Dialing Number AVP encodes the originating number for the incoming 2908 call, that is, CLID. The Attribute value is 22, Dialing Number, and 2909 is marked mandatory. The presence of this AVP is optional. The 2910 value is an ASCII string. Contact between the administrator of the 2911 LAC and the LNS may be necessary to coordinate the value needed in 2912 this AVP. 2914 Sub-Address 2916 0 1 2 3 2917 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 |1|0|0|0|0|0| 6+Sub-Address len | 0 | 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 | 23 |Sub-Address ... 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2924 Sub-Address AVP encodes additional dialing information. The 2925 Attribute value is 23, Sub-Address, and is marked mandatory. The 2926 presence of this AVP is optional. The Sub-Address value is an ASCII 2927 string. Contact between the administrator of the LAC and the LNS may 2928 be necessary to coordinate the value needed in this AVP. 2930 6.10 Incoming-Call-Reply (ICRP) 2932 The Incoming-Call-Reply is an L2TP control message sent by the LNS to 2933 the LAC in response to a received Incoming-Call-Request message. The 2934 reply indicates that the request was successful. It also provides 2935 information to allow the LAC to regulate the transmission of data to 2936 the LNS for this session. 2938 This message is the second in the three-way handshake used by L2TP 2939 for establishing incoming calls. It indicates to the LAC that the 2940 call should be answered. 2942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2943 | L2TP Control Message Header | 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 | Incoming-Call-Reply | 2946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2947 | Assigned Call ID | 2948 | Receive Window Size | 2949 | Packet Processing Delay | 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2952 Incoming-Call-Reply 2954 0 1 2 3 2955 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 |1|0|0|0|0|0| 8 | 0 | 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2959 | 0 | 11 | 2960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2962 The Message Type AVP contains a Value of 11, indicating Incoming- 2963 Call-Reply. The Incoming-Call-Reply message encodes a response by 2964 the LNS to the incoming call indication given by the LAC. The flags 2965 indicate a mandatory option. 2967 Assigned Call ID 2969 0 1 2 3 2970 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2972 |1|0|0|0|0|0| 8 | 0 | 2973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 | 14 | Call ID | 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2977 The Assigned Call ID AVP encodes the ID being assigned to this call 2978 by the LNS. The Attribute value is 14, indicating Assigned Call ID, 2979 and is marked mandatory. This AVP MUST be present. The LAC places 2980 this value in the Call ID header field of all command and payload 2981 packets that it subsequently transmits over the tunnel that belong to 2982 this call. The Call ID value is an identifier assigned by the LNS to 2983 this session. It is used to multiplex and demultiplex data sent over 2984 that tunnel between the LNS and LAC. 2986 Receive Window Size 2988 0 1 2 3 2989 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2991 |1|0|0|0|0|0| 8 | 0 | 2992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2993 | 10 | Size | 2994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2996 Receive Window Size AVP encodes the receive window size being offered 2997 by the LNS for this call. The Attribute value is 10, Receive Window 2998 Size, and is marked mandatory. The Size value indicates the number 2999 of received data packets the LNS will buffer for this call, which is 3000 also the maximum number of data packets the LAC should send before 3001 waiting for an acknowledgment. This AVP is present only if Sequence 3002 and Acknowledgment Numbers are to be used in the payload session for 3003 this call. 3005 Packet Processing Delay 3007 0 1 2 3 3008 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 |1|0|0|0|0|0| 8 | 0 | 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012 | 20 | Delay | 3013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 Packet Processing Delay AVP encodes the expected delay that occurs at 3016 the LNS in processing a window full of packets sent by the LAC. The 3017 Attribute value is 20, Packet Processing Delay AVP, and is marked 3018 mandatory. The presence of this AVP is optional. The Delay value is 3019 specified in units of 1/10 seconds. Refer to Appendix A to see a 3020 description of how this value is determined and used. 3022 6.11 Incoming-Call-Connected (ICCN) 3024 The Incoming-Call-Connected message is an L2TP control message sent 3025 by the LAC to the LNS in response to a received Incoming-Call-Reply. 3026 It provides information to the LNS about particular parameters used 3027 for the call. It also provides information to allow the LNS to 3028 regulate the transmission of data to the LAC for this session. 3030 This message is the third in the three-way handshake used by L2TP for 3031 establishing incoming calls. It provides a mechanism for providing 3032 the LNS with additional information about the call that cannot, in 3033 general, be obtained at the time the Incoming-Call-Request is issued 3034 by the LAC. 3036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3037 | L2TP Control Message Header | 3038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3039 | Incoming-Call-Connected | 3040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3041 | (Tx) Connect Speed | 3042 | Framing Type | 3043 | Receive Window Size | 3044 | Packet Processing Delay | 3045 | Initial Received LCP CONFREQ | 3046 | Last Sent LCP CONFREQ | 3047 | Last Received LCP CONFREQ | 3048 | Proxy authen type | 3049 | Proxy authen name | 3050 | Proxy authen challenge | 3051 | Proxy authen ID | 3052 | Proxy authen response | 3053 | Private Group ID | 3054 | Rx Connect Speed | 3055 | Sequencing Required | 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3058 Incoming-Call-Connected 3060 0 1 2 3 3061 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3063 |1|0|0|0|0|0| 8 | 0 | 3064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 | 0 | 12 | 3066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3068 The Message Type AVP contains a Value of 12, indicating Incoming- 3069 Call-Connected. The Incoming-Call-Connected message encodes a 3070 response by the LAC to the Incoming-Call-Reply message sent by the 3071 LAC. The flags indicate a mandatory option. 3073 (Tx) Connect Speed 3075 0 1 2 3 3076 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3078 |1|0|0|0|0|0| 10 | 0 | 3079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3080 | 24 | BPS (H) | 3081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3082 | BPS (L) | 3083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3085 (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen 3086 for the connection attempt. The Attribute value is 24, indicating 3087 (Tx) Connect Speed, and is marked mandatory. This AVP MUST be 3088 present. BPS is a 32-bit value indicating the speed in bits/second. 3090 When the optional Rx Connect Speed AVP is present, the value in this 3091 AVP represents the transmit connect speed, from the perspective of 3092 the LAC (e.g. data flowing from the LAC to the client). When the 3093 optional Rx Connect Speed AVP is NOT present, the connection speed 3094 between the client and LAC is assumed to be symmetric and is 3095 represented by the single value in this AVP. 3097 Framing Type 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| 10 | 0 | 3103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 3105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3106 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3109 Framing Type AVP encodes the framing type for the call. The 3110 Attribute value is 19, Framing Type, and is marked mandatory. This 3111 AVP MUST be present. The value is a 32-bit bit field indicating the 3112 type of PPP framing used for the call. If set, bit A indicates that 3113 asynchronous framing is being used. If set, bit S indicates that 3114 synchronous framing is being used. A particular type of framing may 3115 be used only if was specified in the Value field of the Framing 3116 Capabilities AVP received from the LNS during control session 3117 establishment. The framing type MAY be used as an indication to PPP 3118 on the LNS as to what link options to use for LCP if renegotiation is 3119 necessary (refer to "PPP in HDLC-like Framing" [14]). 3121 Receive Window Size 3123 0 1 2 3 3124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3126 |1|0|0|0|0|0| 8 | 0 | 3127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3128 | 10 | Size | 3129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3131 Receive Window Size AVP encodes the window size being offered by the 3132 LAC for this call. The Attribute value is 10, Receive Window Size, 3133 and is marked mandatory. This AVP is present only if Sequence and 3134 Acknowledgment Numbers are to be used in the payload session for this 3135 call. The 16-bit Size value indicates the number of received data 3136 packets the LAC will buffer for this call, which is also the maximum 3137 number of data packets the LNS should send before waiting for an 3138 acknowledgment. 3140 Packet Processing Delay 3142 0 1 2 3 3143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3145 |1|0|0|0|0|0| 8 | 0 | 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 | 20 | Delay | 3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3150 Packet Processing Delay AVP encodes the delay the LAC expects for 3151 processing a window full of packets sent by the LNS. The Attribute 3152 value is 20, Packet Processing Delay, and is marked mandatory. The 3153 presence of this AVP is optional. The 16-bit Delay value is 3154 specified in units of 1/10 seconds. Refer to Appendix A to see a 3155 description of how this value is determined and used. 3157 Initial Received LCP CONFREQ 3159 0 1 2 3 3160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3162 |0|0|0|0|0|0| 6+LCP CONFREQ len | 0 | 3163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3164 | 26 | LCP CONFREQ... 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3167 The LAC may have answered the phone call and negotiated LCP with the 3168 dial-in client in order to establish the client's apparent identity. 3169 In this case, this option may be included to indicate the link 3170 properties the client requested in its initial LCP CONFREQ request. 3171 The Attribute value is 26, Initial Received LCP CONFREQ, and is 3172 marked optional. The presence of this AVP is optional. The Value 3173 field is a copy of the body of the initial CONFREQ received, starting 3174 at the first option within this packet's body. 3176 Last Sent LCP CONFREQ 3178 0 1 2 3 3179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3181 |0|0|0|0|0|0| 6+LCP CONFREQ len | 0 | 3182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3183 | 27 | LCP CONFREQ... 3184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3186 See Initial Received LCP CONFREQ above for rationale. The Attribute 3187 value is 27, Last Sent LCP CONFREQ, and is marked optional. The 3188 presence of this AVP is optional. The Value field is a copy of the 3189 body of the final CONFREQ sent to the client to complete LCP 3190 negotiation, starting at the first option within this packet's body. 3192 Last Received LCP CONFREQ 3194 0 1 2 3 3195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3197 |0|0|0|0|0|0| 6+LCP CONFREQ len | 0 | 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3199 | 28 | LCP CONFREQ... 3200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3202 See Initial Received LCP CONFREQ above for rationale. The Attribute 3203 value is 28, Last Received LCP CONFREQ, and is marked optional. The 3204 presence of this AVP is optional. The Value field is a copy of the 3205 body of the final CONFREQ received from the client to complete LCP 3206 negotiation, starting at the first option within this packet's body. 3208 Proxy Authen Type 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| 8 | 0 | 3214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3215 | 29 | Type | 3216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3218 The Attribute value is 29, Proxy Authen Type, and is optional. This 3219 AVP MUST be present if proxy authentication is to be utilized. If it 3220 is not present, then it is assumed that this peer cannot perform 3221 proxy authentication, perhaps requiring a restart of the 3222 authentication phase at the LNS if the client has already entered 3223 this phase with the LAC. The value Type is a 16-bit word, holding a 3224 value: 3226 1 - Textual username/password exchange 3227 2 - PPP CHAP 3228 3 - PPP PAP 3229 4 - None 3230 5 - Microsoft CHAP (MSCHAP) 3232 Associated AVP's for each type of authentication follow. 3234 Proxy Authen Name 3236 0 1 2 3 3237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3239 |0|0|0|0|0|0| 6 + Name length | 0 | 3240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3241 | 30 | Name... 3242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3244 The Attribute value is 30, Proxy Authen Name, and is marked optional. 3245 This AVP MUST be present for Proxy Authen Type values 1, 2, 3 and 5. 3247 The Name field contains the name specified in the client's 3248 authentication response. Note that the AVP H bit may be desirable 3249 for obscuring the cleartext name. 3251 Proxy Authen Challenge 3253 0 1 2 3 3254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3256 |0|0|0|0|0|0| 6 + Challenge len | 0 | 3257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3258 | 31 | Challenge... 3259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3261 The Attribute value is 31, Proxy Authen Challenge, and is marked 3262 optional. The AVP itself MUST be present for Proxy authen types 2 3263 and 5. The Challenge field contains the value presented to the 3264 client by the LAC. 3266 Proxy Authen ID 3268 0 1 2 3 3269 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3271 |0|0|0|0|0|0| 8 | 0 | 3272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3273 | 32 | ID | 3274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3276 The Attribute value is 32, Proxy Authen ID, and is marked optional. 3277 The AVP itself MUST be present for Proxy authen types 2, 3 and 5. 3278 For CHAP and MSCHAP, the ID field contains the byte ID value 3279 presented to the client by the LAC in its Challenge. For PAP, it is 3280 the Identifier value of the Authenticate-Request. The most 3281 significant 8 bits of ID MUST be 0, and are reserved. 3283 Proxy Authen Response 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 |1|0|0|0|0|0| 6 + Response len | 0 | 3289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3290 | 33 | Response... 3291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3293 The Attribute value is 33, Proxy Authen Response, and is marked 3294 mandatory. The AVP itself MUST be present for Proxy authen types 1, 3295 2, 3 and 5. The Response field contains the client's response to the 3296 challenge. For Proxy authen types 2 and 5, this field contains the 3297 response value received by the LAC. For types 1 or 3, it contains 3298 the clear text password received from the client by the LAC. In the 3299 case of cleartext passwords, use of the AVP H bit is recommended. 3301 Private Group ID 3303 0 1 2 3 3304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 |0|0|0|0|0|0| 6+Private ID len | 0 | 3307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3308 | 37 | Private Group ID ... 3309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3311 PrivateGroup ID AVP is used by the LAC to indicate that this call is 3312 to be associated with a particular customer group. The Attribute is 3313 37, Private Group ID, and is marked optional. The presence of this 3314 AVP is optional. The LNS MAY treat the PPP session as well as 3315 network traffic through this session specially in a manner determined 3316 by the peer. For example, if the LNS is individually connected to 3317 several private networks using unregistered addresses, this AVP may 3318 be included by the LAC to indicate that a given call should be 3319 associated with one of the private networks. 3321 The Private Group ID is a string corresponding to a table in the LNS 3322 that defines the particular characteristics of the selected group. A 3323 LAC MAY determine the Private Group ID from a RADIUS response 3324 containing the PrivateGroupID attribute [13]. 3326 Rx Connect Speed 3328 0 1 2 3 3329 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 |0|0|0|0|0|0| 10 | 0 | 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | 38 | BPS (H) | 3334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 | BPS (L) | 3336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3338 Rx Connect Speed BPS AVP encodes the receive speed of the facility 3339 chosen for the connection attempt. The Attribute value is 38, 3340 indicating Rx Connect Speed, and is marked optional. The Rx Connect 3341 Speed represents the speed of the connection from the perspective of 3342 the LAC (e.g. data flowing from the client to the LAC). Presence of 3343 this AVP implies that the connection speed may be asymmetric, with 3344 the transmit connect speed given in the (Tx) Connect Speed AVP. BPS 3345 is a 32-bit value indicating the speed in bits/second. 3347 Sequencing Required 3349 0 1 2 3 3350 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3352 |1|0|0|0|0|0| 6 | 0 | 3353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3354 | 39 | 3355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3357 The Sequencing Required AVP indicates to the LNS that Sequence 3358 Numbers MUST always be present, thus the ability to dynamically drop 3359 sequencing as described in section 4.2 is not an available option. 3360 The Attribute value is 38, Sequencing Required, and is marked 3361 mandatory. The presence of this AVP is optional. This AVP MUST NOT 3362 be present if the Receive Window Size AVP is not present. There is no 3363 value field. 3365 6.12 Call-Disconnect-Notify (CDN) 3367 The Call-Disconnect-Notify message is an L2TP control message sent to 3368 request disconnection of a specific call within the tunnel. Its 3369 purpose is to inform the peer of the disconnection and the reason why 3370 the disconnection occurred. The peer MUST clean up any resources, 3371 and does not send back any indication of success or failure for such 3372 cleanup. 3374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3375 | L2TP Control Message Header | 3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3377 | Call-Disconnect-Notify | 3378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3379 | Result Code | 3380 | Q.931 Cause Code | 3381 | Assigned Call ID | 3382 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3384 Call-Disconnect-Notify 3386 0 1 2 3 3387 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3389 |1|0|0|0|0|0| 8 | 0 | 3390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3391 | 0 | 14 | 3392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3394 The Message Type AVP contains a Value of 14, indicating Call- 3395 Disconnect-Notify. The Call-Disconnect-Notify message encodes a 3396 disconnect indication for a specific call within the tunnel. The 3397 flags indicate a mandatory option. 3399 Result Code 3401 0 1 2 3 3402 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3404 |1|0|0|0|0|0| 10 + Message len | 0 | 3405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3406 | 1 | Result Code | 3407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3408 | Error Code | Optional Message ... 3409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3411 The Result Code AVP within a Call-Disconnect-Notify message 3412 indicates the reason for the call disconnect. It is encoded as 3413 Attribute 1, indicating a Result Code AVP. This AVP is mandatory 3414 and MUST be present. The Result Code is a 16-bit word. The 16- 3415 bit word following the Result Code field contains the Error Code 3416 value. The Result Code value indicates whether the Error Code 3417 value is meaningful or not. If Error Code is not meaningful it 3418 MUST be set to 0. An optional error message can follow the Error 3419 Code field; its presence and length is indicated by the value of 3420 the AVP length field. Defined Result Code values are: 3422 1 - Call disconnected due to loss of carrier 3423 2 - Call disconnected for the reason indicated in Error Code. 3424 3 - Call disconnected for administrative reasons 3425 4 - Call failed due to no appropriate facilities being 3426 available (temporary condition) 3427 5 - Call failed due to no appropriate facilities being 3428 available (permanent condition) 3429 6 - Invalid destination 3430 7 - Call failed due to no carrier detected 3431 8 - Call failed due to detection of a busy signal 3432 9 - Call failed due to lack of a dial tone 3433 10 - Call was not established within time allotted by LAC 3434 11 - Call was connected but no appropriate framing was detected 3436 Q.931 Cause Code 3438 0 1 2 3 3439 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3441 |1|0|0|0|0|0| 9+Advisory Msg len| 0 | 3442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3443 | 12 | Cause Code | 3444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3445 | Cause Msg |Advisory Msg...| 3446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3448 The Q.931 Cause Code AVP is used to give additional information in 3449 case of unsolicited call disconnection. The Attribute value is 12, 3450 Cause Code, and is marked mandatory. The presence of this AVP is 3451 optional. The Cause Code AVP is used to give additional information 3452 about the reason for disconnecting. It is only relevant when the LAC 3453 is using Q.931/DSS1 for the call. Cause Code is the returned Q.931 3454 Cause code and Cause Msg is the returned Q.931 message code (e.g., 3455 DISCONNECT) associated with the Cause Code. Both values are returned 3456 in their native ITU encodings. An additional ASCII text Advisory 3457 Message may also be included (presence indicated by the AVP length) 3458 to further explain the reason for disconnecting. 3460 Assigned Call ID 3462 0 1 2 3 3463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3465 |1|0|0|0|0|0| 8 | 0 | 3466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3467 | 14 | Call ID | 3468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3470 The Assigned Call ID which was provided to the peer, included in the 3471 Call-Disconnect-Notify message. This permits a connection to be 3472 terminated even before the peer has provided its own Assigned Call ID 3473 (the Call ID field in the control message header is 0). The 3474 Attribute value is 14, Assigned Call ID, and is marked mandatory. 3475 This AVP MUST be present. 3477 6.13 WAN-Error-Notify (WEN) 3479 The WAN-Error-Notify message is an L2TP control message sent by the 3480 LAC to the LNS to indicate WAN error conditions (conditions that 3481 occur on the interface supporting PPP). The counters in this message 3482 are cumulative. This message should only be sent when an error 3483 occurs, and not more than once every 60 seconds. The counters are 3484 reset when a new call is established. 3486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3487 | L2TP Control Message Header | 3488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3489 | WAN-Error-Notify | 3490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3491 | Call Errors | 3492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3494 WAN-Error-Notify 3496 0 1 2 3 3497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3499 |1|0|0|0|0|0| 8 | 0 | 3500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3501 | 0 | 15 | 3502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3504 The Message Type AVP contains a Value of 15, indicating WAN-Error- 3505 Notify. The WAN-Error-Notify message encodes information about line 3506 and other errors detected on the LAC's physical interface to the 3507 client. This message is sent by the LAC to the LNS. The flags 3508 indicate a mandatory option. 3510 Call Errors 3512 0 1 2 3 3513 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3515 |1|0|0|0|0|0| 32 | 0 | 3516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3517 | 34 | Reserved | 3518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3519 | CRC Errors | 3520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3521 | Framing Errors | 3522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3523 | Hardware Overruns | 3524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3525 | Buffer Overruns | 3526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3527 | Time-out Errors | 3528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3529 | Alignment Errors | 3530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3532 The Call Errors AVP is used by the LAC to send error information to 3533 the LNS. The Attribute value is 34, WAN-Error-Notify, and is marked 3534 mandatory. This AVP MUST be present. The value contains the 3535 following fields: 3537 Reserved - Not used, MUST be 0 3538 CRC Errors - Number of PPP frames received with CRC errors since 3539 session was established 3540 Framing Errors - Number of improperly framed PPP packets received 3541 Hardware Overruns - Number of receive buffer over-runs since 3542 session was established 3543 Buffer Overruns - Number of buffer over-runs detected since 3544 session was established 3545 Time-out Errors - Number of time-outs since call was established 3546 Alignment Errors - Number of alignment errors since call was 3547 established 3549 6.14 Set-Link-Info (SLI) 3551 The Set-Link-Info message is an L2TP control message sent by the LNS 3552 to the LAC to set PPP-negotiated options. Because these options can 3553 change at any time during the life of the call, the LAC MUST be able 3554 to update its internal call information dynamically and update its 3555 behavior on an active PPP session. 3557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3558 | L2TP Control Message Header | 3559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3560 | Set-Link-Info | 3561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3562 | ACCM | 3563 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3565 Set-Link-Info 3567 0 1 2 3 3568 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3570 |1|0|0|0|0|0| 8 | 0 | 3571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3572 | 0 | 16 | 3573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3575 The Message Type AVP contains a Value of 16, indicating Set-Link- 3576 Info. The Set-Link-Info message encodes ACCM information sent from 3577 the LNS to the LAC after it is negotiated in LCP. The flags indicate 3578 a mandatory option. 3580 ACCM 3582 0 1 2 3 3583 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3585 |1|0|0|0|0|0| 16 | 0 | 3586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3587 | 35 | Reserved | 3588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3589 | Send ACCM | 3590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3591 | Receive ACCM | 3592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3594 The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. 3595 The Attribute value is 35, ACCM, and is marked mandatory. This 3596 attribute MUST be present. The value contains Send ACCM and Receive 3597 ACCM fields. The send ACCM value should be used by the LAC to 3598 process packets it is sends on the connection. The receive ACCM 3599 value should be used by the LAC to process incoming packets on the 3600 connection. The default values used by the LAC for both these fields 3601 are 0xFFFFFFFF. The LAC should honor these fields unless it has 3602 specific configuration information to indicate that the requested 3603 mask must be modified to permit operation. 3605 7.0 Control Connection State Machines 3607 The control messages defined in section 6 are exchanged by way of state 3608 tables defined in this section. Tables are defined for incoming call 3609 placement, outgoing call placement, as well as for initiation of the 3610 tunnel itself. The state tables do not encode timeout and 3611 retransmission behavior, as this is handled in the underlying semantics 3612 defined in 6.0.2. 3614 7.1 Control Connection Protocol Operation 3616 This section describes the operation of various L2TP control 3617 connection functions and the Control Connection messages which are 3618 used to support them. 3620 Receipt of an invalid or malformed Control Connection message should 3621 be logged appropriately, and the control connection should be closed 3622 and restarted to ensure recovery into a known state. 3624 In several cases in the following tables, a protocol message is sent, 3625 and then a "clean up" occurs. Note that regardless of the initiator 3626 of the tunnel destruction, the reliable delivery mechanism must be 3627 allowed to run (see 6.0.2) before destroying the tunnel. This 3628 permits the tunnel management messages to be reliably delivered to 3629 the peer. 3631 7.2 Control Connection States 3633 Control messages are carried over the same media as the payload 3634 messages which are carried following successful connection 3635 establishment. The L2TP control connection protocol is not 3636 distinguishable between the LNS and LAC, but is distinguishable 3637 between the originator and receiver. The originating peer is the one 3638 which first initiates establishment of the tunnel (in a tie breaker 3639 situation, this is the winner of the tie). Since either LAC or LNS 3640 can be the originator, a collision can occur. See Section 6.0.1 for 3641 a description of this and its resolution. 3643 7.2.1 Control Connection Establishment 3645 State Event Action New State 3646 ----- ----- ------ --------- 3647 idle Local Send SCCRQ wait-ctl-reply 3648 Open request 3650 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3651 acceptable 3653 idle Receive SCCRQ, Send StopCCN, idle 3654 not acceptable Clean up 3656 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3657 acceptable Send tunnel-open 3658 event to waiting 3659 sessions 3661 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3662 not acceptable Clean up 3664 wait-ctl-reply Receive SCCRQ, Clean up, idle 3665 lose tie-breaker Re-queue SCCRQ 3666 for idle state 3668 wait-ctl-conn Receive SCCCN, Send tunnel-open established 3669 acceptable event to waiting 3670 sessions 3672 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3673 not acceptable Clean up 3675 established Local Send tunnel-open established 3676 Open request event to waiting 3677 (new client) sessions 3679 established Admin Send StopCCN idle 3680 Tunnel Close Clean up 3682 wait-ctl-reply, 3683 wait-ctl-conn, 3684 established Receive StopCCN Clean up idle 3686 idle 3687 Both initiator and recipient start from this state. An initiator 3688 transmits a SCCRQ, while a recipient remains in the idle state 3689 until receiving a SCCRQ. 3691 wait-ctl-reply 3692 The originator checks to see if another connection has been 3693 requested from the same peer, and if so, handles the collision 3694 situation described in Section 6.0.1. 3696 When a SCCRP is received, it is examined for a compatible version. 3697 If the version of the reply is lower than the version sent in the 3698 request, the older (lower) version should be used provided it is 3699 supported. If the version in the reply is earlier and supported, 3700 the originator moves to the established state. If the version is 3701 earlier and not supported, a StopCCN MUST be sent to the peer and 3702 the originator cleans up and terminates the tunnel. 3704 wait-ctl-conn 3705 This is where an SCCCN is awaited; upon receipt, the challenge 3706 response is checked. The tunnel is either established, or is torn 3707 down if an authorization failure is detected. 3709 established 3710 An established connection may be terminated by either a local 3711 condition or the receipt of a Stop-Control-Connection- 3712 Notification. In the event of a local termination, the originator 3713 MUST send a Stop-Control-Connection-Notification and clean up the 3714 tunnel. 3716 If the originator receives a Stop-Control-Connection-Notification 3717 it MUST also clean up the tunnel. 3719 7.3 Timing considerations 3721 Because of the real-time nature of telephone signaling, both the LNS 3722 and LAC should be implemented with multi-threaded architectures such 3723 that messages related to multiple calls are not serialized and 3724 blocked. The call and connection state figures do not specify 3725 exceptions caused by timers. These are addressed in Section 6.0.2. 3727 7.4 Incoming calls 3729 An Incoming-Call-Request message is generated by the LAC when an 3730 associated telephone line rings. The LAC selects a Call ID and 3731 serial number and indicates the call bearer type. Modems should 3732 always indicate analog call type. ISDN calls should indicate digital 3733 when unrestricted digital service or rate adaption is used and analog 3734 if digital modems are involved. CLID, DNIS, and subaddress may be 3735 included in the message if they are available from the telephone 3736 network. 3738 Once the LAC sends the Incoming-Call-Request, it waits for a response 3739 from the LNS but it does not necessarily answer the call from the 3740 telephone network yet. The LNS may choose not to accept the call if: 3742 - No resources are available to handle more sessions 3743 - The dialed, dialing, or subaddress fields do not correspond to 3744 an authorized user 3745 - The bearer service is not authorized or supported 3747 If the LNS chooses to accept the call, it responds with an Incoming- 3748 Call-Reply which may also indicate window sizes (see Appendix B). 3749 When the LAC receives the Incoming-Call-Reply, it attempts to connect 3750 the call. A final call connected message from the LAC to the LNS 3751 indicates that the call states for both the LAC and the LNS should 3752 enter the established state. If the call terminated before the LNS 3753 could accept it, a Call-Disconnect-Notify is sent by the LAC to 3754 indicate this condition. 3756 When the dialed-in client hangs up, the call is cleared normally and 3757 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 3758 clear a call, it sends a Call-Disconnect-Notify message and cleans up 3759 its session. 3761 7.4.1 LAC Incoming Call States 3763 State Event Action New State 3764 ----- ----- ------ --------- 3765 idle Bearer Ring or Initiate local wait-tunnel 3766 Ready to indicate tunnel open 3767 incoming conn. 3769 wait-tunnel tunnel-open Send ICRQ wait-reply 3771 wait-reply Receive ICRP, Answer call, established 3772 acceptable Send ICCN 3774 wait-reply Receive ICRP, Send CDN, idle 3775 not acceptable Clean up 3777 wait-reply Receive CDN Clean up idle 3779 wait-reply Local Send CDN, idle 3780 Close request Clean up 3782 established Receive CDN Hang up bearer, idle 3783 Clean up 3785 established Local Hang up bearer, idle 3786 Close request Send CDN, 3787 Clean up 3789 established Bearer Send CDN, idle 3790 Line drop Clean up 3792 The states associated with the LAC for incoming calls are: 3794 idle 3795 The LAC detects an incoming call on one of its interfaces. 3796 Typically this means an analog line is ringing or an ISDN TE has 3797 detected an incoming Q.931 SETUP message. The LAC initiates its 3798 tunnel establishment state machine, and moves to a state waiting 3799 for confirmation of the existence of a tunnel. 3801 wait-tunnel 3802 In this state the session is waiting for either the control tunnel 3803 to be opened or for verification that the tunnel is already open. 3804 Once an indication that the tunnel has/was opened, session control 3805 messages may be exchanged. The first of these is the Incoming- 3806 Call-Request. 3808 wait-reply 3809 Incoming-Call-Reply message indicating 3810 The LAC receives either a CDN message indicating non-willingness 3811 to accept the call (general error or don't accept) and moves back 3812 into the idle state, or an Incoming-Call-Reply message indicating 3813 the call is accepted, the LAC sends an Incoming-Call-Connected 3814 message and enters the established state. 3816 established 3817 Data is exchanged over the tunnel. The call may be cleared 3818 following: 3819 An event on the connected interface. The LAC sends a Call- 3820 Disconnect-Notify message 3821 Receipt of a Call-disconnect-Notify message. The LAC cleans 3822 up, disconnecting the call. 3823 A local reason. The LAC sends a Call-Disconnect-Notify 3824 message. 3826 7.4.2 LNS Incoming Call States 3828 State Event Action New State 3829 ----- ----- ------ --------- 3830 idle Receive ICRQ, Send ICRP wait-connect 3831 acceptable 3833 idle Receive ICRQ, Send CDN, idle 3834 not acceptable Clean up 3836 wait-connect Receive ICCN Prepare for established 3837 acceptable data 3839 wait-connect Receive ICCN Send CDN, idle 3840 not acceptable Clean up 3842 wait-connect, 3843 established Receive CDN Clean up idle 3845 established Local Send CDN, idle 3846 Close request Clean up 3848 The states associated with the LNS for incoming calls are: 3850 idle 3851 An Incoming-Call-Request message is received. If the request is 3852 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 3853 and the LNS remains in the idle state. If the Incoming-Call- 3854 Request message is acceptable, an Incoming-Call-Reply is sent. 3855 The session moves to the wait-connect state. 3857 wait-connect 3858 If the session is still connected on the LAC, the LAC sends an 3859 Incoming-Call-Connected message to the LNS which then moves into 3860 established state. The LAC may send a Call-Disconnect-Notify to 3861 indicate that the incoming caller could not be connected. This 3862 could happen, for example, if a telephone user accidentally places 3863 a standard voice call to an LAC resulting in a handshake failure 3864 on the called modem. 3866 established 3867 The session is terminated either by receipt of a Call-Disconnect- 3868 Notify message from the LAC or by sending a Call-Disconnect- 3869 Notify. Clean up follows on both sides regardless of the 3870 initiator. 3872 7.5 Outgoing calls 3874 Outgoing calls are initiated by an LNS and instruct an LAC to place a 3875 call. There are three messages for outgoing calls: Outgoing-Call- 3876 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 3877 sends an Outgoing-Call-Request specifying the dialed party phone 3878 number and subaddress as well as speed and window parameters. The 3879 LAC MUST respond to the Outgoing-Call-Request message with an 3880 Outgoing-Call-Reply message once the LAC determines that the proper 3881 facilities exist to place the call and the call is administratively 3882 authorized. For example, is this LNS allowed to dial an 3883 international call? Once the outbound call is connected, the LAC 3884 sends an Outgoing-Call-Connected message to the LNS indicating the 3885 final result of the call attempt: 3887 7.5.1 LAC Outgoing Call States 3889 State Event Action New State 3890 ----- ----- ------ --------- 3891 idle Receive OCRQ, Send OCRP, wait-cs-answer 3892 acceptable Open bearer 3894 idle Receive OCRQ, Send CDN, idle 3895 not acceptable Clean up 3897 wait-cs-answer Bearer answer, Send OCCN established 3898 framing detected 3900 wait-cs-answer Bearer failure Send CDN, idle 3901 Clean up 3903 wait-cs-answer, 3904 established Receive CDN Hang up bearer, idle 3905 Clean up 3907 The states associated with the LAC for outgoing calls are: 3909 idle 3910 Received Outgoing-Call-Request. If this is received in error, 3911 respond with a Call-Disconnect-Notify. Otherwise, allocate a 3912 physical channel and send an Outgoing-Call-Reply. Place the 3913 outbound call and move to the wait-cs-answer state. 3915 wait-cs-answer 3916 If the call is not completed or a timer expires waiting for the 3917 call to complete, send a Call-Disconnect-Notify with the 3918 appropriate error condition set and go to idle state. If a 3919 circuit switched connection is established and framing is 3920 detected, send an Outgoing-Call-Connected indicating success and 3921 go to established state. 3923 established 3924 If a Call-Disconnect-Notify is received by the LAC, the telco call 3925 MUST be released via appropriate mechanisms and the session 3926 cleaned up. If the call is disconnected by the client or the 3927 called interface, a Call-Disconnect-Notify message MUST be sent to 3928 the LNS. The sender of the Call-Disconnect-Notify message returns 3929 to the idle state after sending of the message is complete. 3931 7.5.2 LNS Outgoing Call States 3933 State Event Action New State 3934 ----- ----- ------ --------- 3935 idle Local Initiate local wait-tunnel 3936 Open request tunnel-open 3938 wait-tunnel tunnel-open Send OCRQ wait-reply 3940 wait-reply Receive OCRP, none wait-connect 3941 acceptable 3943 wait-reply Receive OCRP, Send CDN idle 3944 not acceptable 3946 wait-connect Receive OCCN none established 3948 established, 3949 wait-connect Receive CDN Clean up idle 3951 wait-reply, 3952 wait-connect, 3953 established Local Send CDN idle 3954 Close request 3956 The states associated with the LNS for outgoing calls are: 3958 idle, wait-tunnel 3959 When an outgoing call is initiated, a tunnel is first created, 3960 much as the idle and wait-tunnel states for an LAC incoming call. 3961 Once a tunnel is established, an Outgoing-Call-Request message is 3962 sent to the LAC and the session moves into the wait-reply state. 3964 wait-reply 3965 If a Call-Disconnect-Notify is received, an error occurred, and 3966 the session is cleaned up and returns to idle. If an Outgoing- 3967 Call-Reply is received, the call is in progress and the session 3968 moves to the wait-connect state. 3970 wait-connect 3971 If a Call-Disconnect-Notify is received, the call failed; the 3972 session is cleaned up and returns to idle. If an Outgoing-Call- 3973 Connected is received, the call has succeeded and the session may 3974 now exchange data. 3976 established 3977 If a Call-Disconnect-Notify is received, the call has been 3978 terminated for the reason indicated in the Result and Cause Codes; 3979 the session moves back to the idle state. If the LNS chooses to 3980 terminate the session, it sends a Call-Disconnect-Notify to the 3981 LAC and then cleans up and idles its session. 3983 7.6 Tunnel Disconnection 3985 The disconnection of a tunnel consists of either peer issuing a 3986 Stop-Control-Connection-Notification. The sender of this 3987 Notification should wait a finite period of time for the 3988 acknowledgment of this message before releasing the control 3989 information associated with the tunnel. The recipient of this 3990 Notification should send an acknowledgment of the Notification and 3991 then release the associated control information. 3993 When to release a tunnel is an implementation issue and is not 3994 specified in this document. A particular implementation may use 3995 whatever policy is appropriate for determining when to release a 3996 control connection. Some implementations may leave a tunnel open for 3997 a period of time or perhaps indefinitely after the last user session 3998 for that tunnel is cleared. Others may choose to disconnect the 3999 tunnel immediately after the last user connection on the tunnel 4000 disconnects. 4002 8.0 L2TP Over Specific Media 4004 L2TP tries to be self-describing, operating at a level above the 4005 particular media over which it is carried. However, some details of 4006 its connection to media are required to permit interoperable 4007 implementations. The following sections describe details needed to 4008 permit interoperability over specific media. 4010 8.1 IP/UDP 4012 L2TP uses the well-known UDP port 1701 [3]. The entire L2TP packet, 4013 including payload and L2TP header, is sent within a UDP datagram. 4014 The initiator of an L2TP tunnel picks an available source UDP port, 4015 and sends to the desired destination at port 1701. The recipient 4016 picks a free port on its own system (which may or may not be 1701), 4017 and sends its reply to the initiator's UDP port, setting its own UDP 4018 source port set to the free port it found. 4020 It is legal for a peer's IP address and/or UDP port used for a given 4021 tunnel to change over the life of a connection; this may correspond 4022 to a peer with multiple IP interfaces responding to a network 4023 topology change. Responses should reflect the last source IP address 4024 and UDP port for that Tunnel ID. 4026 IP fragmentation may occur as the L2TP packet travels over the IP 4027 substrate. L2TP makes no special efforts to optimize this. A LAC 4028 implementation MAY cause its LCP to negotiate for a specific MRU, 4029 which could optimize for LAC environments in which the MTU's of the 4030 path over which the L2TP packets are likely to travel have a 4031 consistent value. 4033 The default for any L2TP implementation is that UDP checksums MUST be 4034 enabled for both control and payload messages. An L2TP 4035 implementation MAY provide an option to disable UDP checksums for 4036 payload packets. It is recommended that UDP checksums always be 4037 enabled on control packets. 4039 Port 1701 is used for both L2F [5] and L2TP packets. The two types 4040 of packets may be detected by their headers; L2TP has a Vers field of 4041 2, L2F has a Vers field of 1. An L2TP implementation running on a 4042 system which does not support L2F MUST silently discard all packets 4043 whose Vers field is set to 1. 4045 To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP media 4046 has the characteristics of being able to reorder or silently drop 4047 packets. The former may break non-IP protocols being carried by PPP, 4048 especially LAN-centric ones such as bridging. The latter may break 4049 protocols which assume per-packet indication of error, such as TCP 4050 header compression. The former may be handled by using L2TP payload 4051 sequence numbers if any PPP protocol is used which cannot tolerate 4052 reordering. 4054 The latter characteristic of silently dropping packets is perhaps 4055 more problematic. If RFC 1663 reliable delivery [10] is enabled, no 4056 upper PPP protocol will encounter lost packets. If L2TP sequence 4057 numbers are enabled, L2TP can detect the packet loss. In the case of 4058 an LNS, the PPP and L2TP stacks are both present within the LNS, and 4059 packet loss signaling may occur precisely as if a packet was received 4060 with a CRC error. Where the LAC and PPP stack are co-resident, this 4061 technique also applies. Where the LAC and PPP client are physically 4062 distinct, the analogous signaling MAY be accomplished by sending a 4063 packet with a CRC error to the PPP client. Note that this would 4064 greatly increase the complexity of debugging client line problems, 4065 since the client statistics can not distinguish between true media 4066 errors and LAC-initiated ones. This technique is also not possible 4067 on all hardware. 4069 If neither RFC 1663 nor sequence numbers are enabled, each lost 4070 packet results in a 1 in 2**16 chance of a TCP segment being 4071 forwarded with incorrect contents [11]. Where the combination of the 4072 packet loss rate with this statistical exposure is unacceptable, TCP 4073 header compression SHOULD NOT be used in this configuration. 4075 In general, it is wise to remember that the L2TP/UDP/IP transport is 4076 an unreliable transport. As with any PPP media which is subject to 4077 loss, care should be taken when using protocols which are 4078 particularly sensitive this. Such protocols might include stateful 4079 compression or encryption protocols. 4081 8.2 IP 4083 When operating in IP environments, L2TP MUST offer the UDP 4084 encapsulation described in 8.1 as its default configuration for IP 4085 operation. Other configurations (perhaps corresponding to a 4086 compressed header format) may be defined, and made available as a 4087 configurable option. 4089 9.0 Security Considerations 4091 L2TP encounters several security issues in its operation. The 4092 general approach of L2TP to these issues is documented here. 4094 9.1 Tunnel Endpoint Security 4096 The tunnel endpoints may authenticate each other during tunnel 4097 establishment. This authentication has the same security 4098 attributes as CHAP, and has reasonable protection against replay 4099 and snooping during the tunnel establishment process. This 4100 mechanism is not designed to provide any authentication beyond 4101 tunnel establishment; it is fairly simple for a malicious user who 4102 can snoop and inject packets to hijack a tunnel once an 4103 authenticated tunnel establishment has been completed 4104 successfully. In environments where some L2TP peers will be 4105 authenticated, but others not, a mechanism should be provided to 4106 control when tunnel endpoint authentication will be active. 4108 The LAC and LNS MUST share a single secret for authentication of 4109 both ends of the tunnel. Each side uses this same secret when 4110 acting as authenticatee as well as authenticator. Since a single 4111 secret it used, the tunnel authentication AVPs include 4112 differentiating values in the CHAP ID fields for each message 4113 digest calculation to guard against replay attacks. 4115 For L2TP tunnels over IP, IP-level packet security provides very 4116 strong protection of the tunnel. This requires no modification to 4117 the L2TP protocol, and leverages extensive IETF work in this area. 4119 For L2TP tunnels over Frame Relay or other switched networks, 4120 current practice indicates that these media are much less likely 4121 to experience attacks of in-transit data. If these attacks become 4122 prevalent, either the media or the L2TP packets would have to be 4123 encrypted or authenticated. 4125 Because the shared secret used for endpoint authentication is the 4126 same shared secret used to obscure AVP contents using the H 4127 (Hidden) bit, tunnel authentication must be used in all cases 4128 where the H bit will be used. Proxy authentication involving PAP 4129 may be usable without the H bit if PAP is only carrying one-time 4130 passwords; if clear text passwords are carried in the proxy 4131 authentication, the H bit (and, by implication, tunnel 4132 authentication) should be used. 4134 To protect against exhaustive attack during tunnel authentication, 4135 no tunnel authentication response should ever be accepted if it 4136 corresponds to a challenge more than one minute old. 4138 9.2 Client Security 4140 A more systematic method of protection in tunneled PPP 4141 environments may be achieved through client security. PPP layer 4142 encryption would provide end-to-end security for both direct 4143 dial-in clients as well as PPP clients carried within a tunnel. 4144 With this level of client security, sessions are protected against 4145 attacks against the carrying tunnel, as well as attacks on the LAC 4146 itself. Because both encryption and compression can occur at the 4147 PPP layer, the two can be coordinated, permitting compression to 4148 precede encryption. 4150 9.3 Proxy Authentication 4152 The optional proxy CHAP function of L2TP can permit an entirely 4153 transparent PPP tunnel, with a single LCP and CHAP sequence being 4154 seen by the client. For cases where the LAC and the entire path 4155 to the LNS are operated by a single entity, this function may 4156 provide acceptable security. For cases where LNS-initiated 4157 authentication is required, proxy CHAP still permits an initial 4158 access decision to be made before accepting the tunnel, permitting 4159 the LNS in most cases to reject tunnel initiations rather than 4160 accept them and later disconnect. 4162 The optional proxy PAP may result in the cleartext password 4163 traversing the tunnel. Where PAP is being used in conjunction 4164 with static passwords, this may pose a significant security issue. 4165 Where PAP is only used to transport one-time passwords, such 4166 issues may be greatly mitigated. The H bit of the carrying AVP 4167 may be used to protect against this. 4169 All implementations MUST accept proxy authentication AVP's, but 4170 are free to silently discard them and initiate an entirely new 4171 authentication with the PPP client. 4173 10.0 Acknowledgments 4175 The AVP construct comes from Glen Zorn, who thought up the framework 4176 for permitting multiple vendors to contribute to a common attribute 4177 space in a relatively orderly fashion. 4179 Dory Leifer of Ascend Communications made valuable refinements to the 4180 protocol definition of L2TP and contributed to the editing of this 4181 document. 4183 Steve Cobb and Evan Caves redesigned the state machine tables. 4185 Barney Wolff provided a great deal of design input on the endpoint 4186 authentication mechanism. 4188 11.0 Contacts 4190 Kory Hamzeh, Allan Rubens 4191 Ascend Communications 4192 1275 Harbor Bay Parkway 4193 Alameda, CA 94502 4194 kory@ascend.com 4195 acr@del.com 4196 Tim Kolar, Morgan Littlewood, Andrew J. Valencia 4197 Cisco Systems 4198 170 West Tasman Drive 4199 San Jose CA 95134-1706 4200 tkolar@cisco.com 4201 littlewo@cisco.com 4202 vandys@cisco.com 4204 W. Mark Townsley 4205 Cisco Systems 4206 7025 Kit Creek Road 4207 PO Box 14987 4208 Research Triangle Park, NC 27709 4209 townsley@cisco.com 4211 Gurdeep Singh Pall 4212 Microsoft Corporation 4213 Redmond, WA 4214 gurdeep@microsoft.com 4216 Bill Palter 4217 Network Alchemy, Inc 4218 1521.5 Pacific Ave 4219 Santa Cruz, CA 95060 4220 palter@zev.net 4222 Jeff Taarud 4223 Copper Mountain Networks, Inc. 4224 3931 Sorrento Valley Blvd. 4225 San Diego, CA 92121 4226 jtaarud@coppermountain.com 4228 William Verthein 4229 3COM Corporation 4230 william_verthein@3com.com 4232 12.0 References 4234 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 4235 07/21/1994 4237 [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet 4238 draft, April 1996 4240 [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point 4241 Tunneling Protocol", Internet draft, June 1996 4243 [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034, 4244 November 1987 4246 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, 4247 USC/Information Sciences Institute, July 1992. 4249 [6] Sally Floyd, Van Jacobson, "Random Early Detection Gateways for 4250 Congestion Avoidance", IEEE/ACM Transactions on Networking, 4251 August 1993 4253 [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, 4254 October 1996 4256 [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens, "Remote 4257 Authentication Dial In User Service (RADIUS)." RFC 2058, January 1997. 4259 [9] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, RFC 1990, 4260 "The PPP Multilink Protocol (MP)", August 1996. 4262 [10] D. Rand, "PPP Reliable Transmission", RFC 1663, July, 1994 4264 [11] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links", 4265 RFC 1144, February, 1990 4267 [12] "SMI Network Management Private Enterprise Codes", 4268 ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers 4270 [13] G. Zorn, D. Leifer, A. Rubens, J. Shriver, "RADIUS Attributes for 4271 Tunnel Protocol Support," draft-ietf-radius-tunnel-auth-04.txt, 4272 November 1997 4274 [14] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, 07/1994 4276 [15] Bradner, S, "Key words for use in RFCs to Indicate Requirement 4277 Levels", RFC 2119, March 1997. 4279 Appendix A: Acknowledgment Timeouts 4281 L2TP uses sliding windows and timeouts to provide session and control 4282 flow-control across the underlying medium (which may be an 4283 internetwork) and to perform efficient data buffering to keep the 4284 LAC-LNS data channels full without causing receive buffer overflow. 4285 L2TP requires that a timeout be used to recover from dropped data or 4286 acknowledgment packets for both control and data messages. The only 4287 real difference between the flow-control mechanism used for the two 4288 message types is that control messages are retransmitted upon 4289 expiration of the acknowledgment timeout in order to assure reliable 4290 transport while payload messages are never retransmitted. Because 4291 payload messages are not retransmitted, the action taken upon 4292 expiration of the acknowledgment timeout for each message type also 4293 differs. 4295 When the timeout for a control session expires the previously 4296 transmitted control message with Ns value equal to the highest in- 4297 sequence value of Nr received from the peer is retransmitted. The 4298 receiving peer does not advance its value for the receive sequence 4299 number state, Sr, for either a control session or payload session 4300 until it receives a message with Ns equal to its current value of Sr 4301 (except for the simple receiver described in Appendix C and payload 4302 packets with the R bit set). This rule assures that all subsequent 4303 acknowledgments for this session will contain an Nr value equal to 4304 the Ns value of the first missing message until a message with the 4305 missing Ns value is received. This rule also assures that when a 4306 payload message is lost anywhere within the current transmit window, 4307 the payload session acknowledgment timeout will expire, allowing the 4308 transmitter to adjust transmission parameters such as those suggested 4309 in this appendix. 4311 According to the above rule for updating of the receiving peer's Sr 4312 value, the loss of a transmitted payload message (due to non- 4313 retransmission of payload messages) will cause Sr to remain at the 4314 value of the first lost payload message. In order to cause the 4315 receiving peer to advance its value of Sr beyond that of a lost 4316 message's Ns value, upon expiration of a payload session 4317 acknowledgment timeout, the sending peer MUST transmit a payload 4318 message with R bit set and Ns value greater than or equal to Ns of 4319 the lost message. Refer to Section 4 for more details on the use of 4320 the R bit. 4322 The exact implementation of the acknowledgment timeout is vendor- 4323 specific. It is suggested that an adaptive timeout be implemented 4324 with backoff for congestion control. The timeout mechanism proposed 4325 here has the following properties: 4327 Independent timeouts for each session. A device (LAC or LNS) will 4328 have to maintain and calculate timeouts for every active session. 4330 An administrator-adjustable maximum timeout, MaxTimeOut, unique to 4331 each device. 4333 An adaptive timeout mechanism that compensates for changing 4334 throughput. To reduce packet processing overhead, vendors may 4335 choose not to recompute the adaptive timeout for every received 4336 acknowledgment. The result of this overhead reduction is that the 4337 timeout will not respond as quickly to rapid network changes. 4339 Timer backoff on timeout to reduce congestion. The backed-off 4340 timer value is limited by the configurable maximum timeout value. 4341 Timer backoff is done every time an acknowledgment timeout occurs. 4343 In general, this mechanism has the desirable behavior of quickly 4344 backing off upon a timeout and of slowly decreasing the timeout value 4345 as packets are delivered without timeouts. 4347 Some definitions: 4349 Packet Processing Delay, "PPD", is the amount of time required for 4350 each peer to process the maximum amount of data buffered in its 4351 offered receive packet window. The PPD is the value exchanged 4352 between the LAC and LNS when a call is established. For the LNS, 4353 this number should be small. For an LAC supporting modem 4354 connections, this number could be significant. 4356 "Sample" is the actual amount of time incurred receiving an 4357 acknowledgment for a packet. The Sample is measured, not 4358 calculated. 4360 Round-Trip Time, "RTT", is the estimated round-trip time for an 4361 Acknowledgment to be received for a given transmitted packet. 4362 When the network link is a local network, this delay will be 4363 minimal (if not zero). When the network link is the Internet, 4364 this delay could be substantial and vary widely. RTT is adaptive: 4365 it will adjust to include the PPD and whatever shifting network 4366 delays contribute to the time between a packet being transmitted 4367 and receiving its acknowledgment. 4369 Adaptive Timeout, "ATO", is the time that must elapse before an 4370 acknowledgment is considered lost. After a timeout, the sliding 4371 window is partially closed and the ATO is backed off. 4373 Packet Processing Delay (PPD) 4375 The PPD parameter is a 16-bit time value exchanged during the Call 4376 Control phase expressed in units of tenths of a second (64 means 6.4 4377 seconds). The protocol only specifies that the parameter is 4378 exchanged, it does not specify how it is calculated. The way values 4379 for ATO are calculated is implementation-dependent and need not be 4380 variable (static timeouts are allowed). If adaptive timeouts are to 4381 be used then the PPD should be exchanged in the call connect 4382 sequences. A possible way to calculate the PPD is: 4384 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 4385 + LACFudge (for an LAC) 4386 or 4387 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4388 + LNSFudge (for an LNS) 4390 Header is the total size of the L2TP and media dependent headers. 4391 MTU is the overall MTU for the link between the LAC and LNS. 4392 WindowSize represents the number of packets in the sliding window, 4393 and is implementation-dependent. The latency of the underlying 4394 connection path between the LAC and LNS could be used to pick a 4395 window size sufficient to keep the current session's pipe full. The 4396 constant 8 converts octets to bits (assuming ConnectRate is in bits 4397 per second). LACFudge and LNSFudge are not required but can be used 4398 to take overall processing overhead of the LAC or LNS into account. 4400 In the case of the computed PPD for an LNS, AvePathRate is the 4401 average bit rate of the path between the LNS and LAC. Given that 4402 this number is probably very large and WindowSize is relatively 4403 small, LNSFudge will be the dominant factor in the computation of 4404 PPD. It is recommended that the minimum value of PPD be on the order 4405 of 0.5 second. 4407 The value of PPD is used to seed the adaptive algorithm with the 4408 initial RTT[n-1] value. 4410 A.1 Calculating Adaptive Acknowledgment Timeout 4411 We still must decide how much time to allow for acknowledgments to 4412 return. If the timeout is set too high, we may wait an unnecessarily 4413 long time for dropped packets. If the timeout is too short, we may 4414 time out just before the acknowledgment arrives. The acknowledgment 4415 timeout should also be reasonable and responsive to changing network 4416 conditions. 4418 The suggested adaptive algorithm detailed below is based on the TCP 4419 1989 implementation and is explained in Richard Steven's book TCP/IP 4420 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 4421 calculation, and 'n-1' refers to values from the last calculation. 4423 DIFF[n] = SAMPLE[n] - RTT[n-1] 4424 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 4425 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 4426 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 4428 DIFF represents the error between the last estimated round-trip 4429 time and the measured time. DIFF is calculated on each iteration. 4431 DEV is the estimated mean deviation. This approximates the 4432 standard deviation. DEV is calculated on each iteration and 4433 stored for use in the next iteration. Initially, it is set to 0. 4435 RTT is the estimated round-trip time of an average packet. RTT is 4436 calculated on each iteration and stored for use in the next 4437 iteration. Initially, it is set to PPD. 4439 ATO is the adaptive timeout for the next transmitted packet. ATO 4440 is calculated on each iteration. Its value is limited, by the MIN 4441 function, to be a maximum of the configured MaxTimeOut value. 4443 Alpha is the gain for the round trip estimate error and is 4444 typically 1/8 (0.125). 4446 Beta is the gain for the deviation and is typically 1/4 (0.250). 4448 Chi is the gain for the timeout and is typically set to 4. 4450 To eliminate division operations for fractional gain elements, the 4451 entire set of equations can be scaled. With the suggested gain 4452 constants, they should be scaled by 8 to eliminate all division. To 4453 simplify calculations, all gain values are kept to powers of two so 4454 that shift operations can be used in place of multiplication or 4455 division. The above calculations are carried out each time an 4456 acknowledgment is received for a packet that was not retransmitted 4457 (no timeout occurs). 4459 A.2 Congestion Control: Adjusting for Timeout 4461 This section describes how the calculation of ATO is modified in the 4462 case where a timeout does occur. When a timeout occurs, the timeout 4463 value should be adjusted rapidly upward. Although L2TP payload 4464 packets are not retransmitted when a timeout occurs, the timeout 4465 should be adjusted up toward a maximum limit. To compensate for 4466 shifting internetwork time delays, a strategy must be employed to 4467 increase the timeout when it expires. A simple formula called Karn's 4468 Algorithm is used in TCP implementations and may be used in 4469 implementing the backoff timers for the LNS or the LAC. Notice that 4470 in addition to increasing the timeout, we also shrink the size of the 4471 window as described in the next section. 4473 Karn's timer backoff algorithm, as used in TCP, is: 4475 NewTIMEOUT = delta * TIMEOUT 4477 Adapted to our timeout calculations, for an interval in which a 4478 timeout occurs, the new timeout interval ATO is calculated as: 4480 RTT[n] = delta * RTT[n-1] 4481 DEV[n] = DEV[n-1] 4482 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 4484 In this modified calculation of ATO, only the two values that 4485 contribute to ATO and that are stored for the next iteration are 4486 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 4487 not carried forward and is not used in this scenario. A value of 2 4488 for Delta, the timeout gain factor for RTT, is suggested. 4490 Appendix B: Acknowledgment Timeout and Window Adjustment 4492 B.1 Initial Window Size 4494 Although each side has indicated the maximum size of its receive 4495 window, it is recommended that a slow start method be used to begin 4496 transmitting data. The initial maximum window size on the 4497 transmitter is set to half the maximum size the receiver requested, 4498 with a minimum size of one packet. The transmitter stops sending 4499 packets when the number of packets awaiting acknowledgment is equal 4500 to the current maximum window size. As the receiver successfully 4501 digests each window, the maximum window size on the transmitter is 4502 bumped up by one packet until the maximum specified by the receiver 4503 is reached. This method prevents a system from flooding an already 4504 congested network because no history has been established. 4506 When for any reason an LAC or LNS receives more data than it can 4507 queue for the tunnel, a packet must be discarded. In this case, it 4508 is recommended that a "random early discard" algorithm [6] be used 4509 rather than the obvious "drop last" algorithm. 4511 B.2 Closing the Window 4513 When a timeout does occur on a packet, the sender adjusts the size of 4514 the transmit window down to one half its maximum value when it 4515 failed. Fractions are rounded up, and the minimum window size is 4516 one. 4518 B.3 Opening the Window 4519 With every successful transmission of a window's worth of packets 4520 without a timeout, the maximum transmit window size is increased by 4521 one packet until it reaches the maximum window size that was sent by 4522 its peer when the call was connected. As stated earlier, no 4523 retransmission is done on a timeout. After a timeout, transmission 4524 resumes with the maximum transmit window starting at one half the 4525 size of the maximum transmit window when the timeout occurred (with a 4526 minimum window size of 1) and adjusting upward by one each time the 4527 current maximum transmit window is filled with packets that are all 4528 acknowledged without timeouts. 4530 B.4 Window Overflow 4532 When a receiver's window overflows with too many incoming packets, 4533 excess packets are thrown away. This situation should not arise if 4534 the sliding window procedures are being properly followed by the 4535 transmitter and receiver. It is assumed that, on the transmit side, 4536 packets are buffered for transmission and are no longer accepted from 4537 the packet source when the transmit buffer fills. 4539 Appendix C: Handling of out-of-order packets 4541 When the Sequence Number and Acknowledgment Number fields are present 4542 in payload packets, they are used to manage packet rate. In 4543 addition, they may be used to handle out-of-order arrival of packets. 4544 A simple L2TP receiver may choose to skip the test for the Ns value 4545 of a received message being equal to Sr, simply updating Sr if Ns is 4546 greater than the current value of Sr. For example, if packets 1, 2, 4547 3 arrived as 1, 3, 2, this simple implementation would silently 4548 discard packet 2 without informing the sender in any way that packet 4549 2 was discarded. Even though packet 2 is dropped by the receiver, the 4550 transmitter will perceive all transmitted packets as being received 4551 without loss by its peer. 4553 Such behavior does not affect the L2TP protocol itself, but 4554 significantly improved throughput in such environments may be 4555 attained by queuing and reordering packets when they arrive out of 4556 order. The number of packets to be queued is a function of memory 4557 resources on the L2TP implementation, but should never be more than 4558 1/4 of the total sequence number space (i.e., 16384 packets), to 4559 avoid the possibility of sequence number aliasing. 4561 It is suggested that receiving peer implementations implement the Sr 4562 state variable for payload sessions and that they update Sr only when 4563 receiving the next in-sequence Ns value or when receiving a message 4564 with the R bit set. Doing so allows a mechanism for reporting of lost 4565 payload messages to the transmitter, which is necessary for the 4566 transmitter to implement algorithms such as those suggested in 4567 Appendix A and B. 4569 Note that while payload messages received out-of-order may either be 4570 queued, discarded, or delivered out-of-order, queuing is preferred. 4571 PPP does not expect to receive packets out-of-order so, if queuing is 4572 not provided by a receiver, it is preferable for it to discard out- 4573 of-order packets rather than deliver them to PPP. 4575 Appendix D: Transport Layer Adaptive Timeouts and Window Adjustment 4577 Appendixes A, B, and C deal primarily with operation of the payload 4578 packet sessions of L2TP. This Appendix explains how these three 4579 algorithms pertain to the transport layer for L2TP control sessions. 4580 Appendix B, Time-out Window Management, directly applies to the 4581 Transport Layer except in the case where a window size of 1 is being 4582 used. Appendix C, does not really apply because, for the Control 4583 Session, control messages MUST always be processed by the receiver in 4584 order. Also, there are no lost control packets because they are 4585 retransmitted by the L2TP Transport Layer. Thus, the main topic of 4586 this Appendix is how to adapt the example adaptive timeout algorithm 4587 of Appendix A to the Control Session Transport Layer. 4589 There are two main differences between the Control Session and 4590 payload sessions: 1) Unlike lost payload packets, lost control 4591 messages are retransmitted and 2) There is no Packet Processing Delay 4592 value provided in the control session setup messages. The latter 4593 affects the manner in which the initial value of the RTT estimate is 4594 determined. The former really doesn't affect the algorithm at all, 4595 except that upon a timeout, retransmission of unacknowledged control 4596 messages should be attempted, up to the number that fit in the 4597 sliding window with size computed as in Appendix B. 4599 Using the symbol definitions of Appendix A, the calculation of the 4600 value for the PPD of the remote peer can be estimated as: 4602 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4603 + Fudge 4605 This is simply the number of bits in a full control session window 4606 divided by the average speed of the path between the LAC and LNS with 4607 a fudge factor added on to make it work. In cases where the average 4608 rate of the connection between LAC and LNS isn't known, it is 4609 suggested that some value be configured that is associated with each 4610 possible peer. Because Control Session windows will most likely be 4611 small and the connection speed will be quite high, fudge will be the 4612 dominant factor in this calculation. For this reason, just 4613 configuring a single fixed initial PPD estimate to be used for all 4614 possible peers will probably provide adequate results. This fudge 4615 factor should be at least 0.5 second. 4617 Appendix E: Examples of L2TP sequence numbering 4619 Although sequence numbers serve distinct purposes for control and 4620 data messages, both types of messages use identical techniques for 4621 assigning sequence numbers. This appendix shows several common 4622 scenarios, and illustrates how sequence number state progresses and 4623 is interpreted. 4625 E.1: Lock-step tunnel establishment 4626 In this example, an LAC establishes a tunnel, with the exchange 4627 involving each side alternating in sending messages. This example 4628 is contrived, in that the final acknowledgment in the example is 4629 explicitly sent within a zero-length message, although most 4630 typically the acknowledgment would have been included in the 4631 processing of the Incoming-Call-Request which had prompted the LAC 4632 to initiate the tunnel in the first place. 4634 LAC LNS 4635 -> Start-Control-Connection-Request 4636 Nr: 0, Ns: 0 4638 Start-Control-Connection-Reply <- 4639 Nr: 1, Ns: 0 4641 -> Start-Control-Connection-Connected 4642 Nr: 1, Ns: 1 4644 (delay) 4646 (zero-length) <- 4647 Nr: 2, Ns: 1 4649 E.2: Multiple packets acknowledged 4651 This example shows a flow of payload packets from the LNS to the 4652 LAC, with the LAC having no traffic of its own. The LAC is 4653 waiting 1/4 of its timeout interval, and then acknowledging all 4654 packets seen since the last interval. 4656 (previous packet flow precedes this) 4658 LAC LNS 4659 -> (zero-length) 4660 Nr: 7000, Ns: 1000 4661 (payload) <- 4662 Nr: 1000, Ns: 7000 4663 (payload) <- 4664 Nr: 1000, Ns: 7001 4665 (payload) <- 4666 Nr: 1000, Ns: 7002 4668 (LAC's timer indicates it should acknowledge pending traffic) 4670 -> (zero-length) 4671 Nr: 7003, Ns: 1000 4673 E.3: Lost packet with retransmission 4675 An existing tunnel has a new session requested by the LAC. The 4676 Incoming-Call-Reply is lost and must be retransmitted by the LNS. 4677 This example continues from the sequence state reached at the end 4678 of example E.1. Note that loss of the -Reply has two impacts: not 4679 only does it keep the upper level state machine from progressing, 4680 but it also keeps the LAC from seeing a timely lower level 4681 acknowledgment of its -Request packet. 4683 LAC LNS 4684 -> Incoming-Call-Request 4685 Nr: 1, Ns: 2 4687 (packet lost) Incoming-Call-Reply <- 4688 Nr: 3, Ns: 1 4690 (pause; LAC's timer started first, so fires first) 4692 -> Incoming-Call-Request 4693 Nr: 1, Ns: 2 4695 (LNS realizes it has already seen this packet) 4696 (LNS might use this as a cue to retransmit, as in this example) 4698 Incoming-Call-Reply <- 4699 Nr: 3, Ns: 1 4700 -> Incoming-Call-Connected 4701 Nr: 2, Ns: 3 4703 (delay) 4705 (zero-length) <- 4706 Nr: 4, Ns: 2 4708 E.4: Lost payload packet with ZLB congestion control 4710 In this example, a packet sent from Peer A to Peer B is lost. Peer 4711 B's receive window is 4, so after Peer A realizes that it has 4712 filled Peer B's window, it waits. After timing out, Peer A sends a 4713 ZLB with the R bit set to reset Peer B, telling it to give up on 4714 3001. If performing window adjustment, Peer A should now reduce 4715 its effective transmit window size until a full window is digested 4716 by Peer B. 4718 Peer A Peer B (RW=4) 4719 -> Payload Packet 4720 Nr: 7000, Ns: 3000 4722 Payload Packet <- 4723 Nr: 3001, Ns: 7000 4725 -> Payload packet (packet lost) 4726 Nr: 7001, Ns: 3001 4728 Payload Packet <- 4729 Nr: 3001, Ns: 7001 4731 -> Payload packet 4732 Nr: 7002, Ns: 3002 4733 -> Payload packet 4734 Nr: 7002, Ns: 3003 4735 -> Payload packet 4736 Nr: 7002, Ns: 3004 4738 (window full, waiting) 4740 -> Timeout, send ZLB w/R bit set 4741 Nr: 7002 Ns: 3005 4743 Payload Packet <- 4744 Nr: 3005 Ns: 7002 4746 Note that the ZLB sent with the R bit set could have been any 4747 value greater than that of the lost packet, 3001, and the current 4748 Ss value plus one. Thus, a ZLB with the R bit set to 3002, 3003 or 4749 3004 instead of 3005 would have had effectively the same result 4750 given that peer B received and queued the out of order packets. 4752 E.5: Lost payload packet with piggyback congestion control 4754 In this example, two packets sent from Peer A to Peer B are lost. 4755 Peer B's receive window is 4, so after Peer A realizes that it has 4756 filled Peer B's window, it waits. After timing out, Peer A sends a 4757 payload packet with the R bit set to reset Peer B, telling it to 4758 give up on 3001 and 3002. If performing window adjustment, Peer A 4759 should now reduce its effective transmit window size until a full 4760 window is digested by Peer B. Note that in this scenario Peer A 4761 has no way of knowing that more than one packet was lost. 4763 Peer A Peer B (RW=4) 4764 -> Payload Packet 4765 Nr: 7000, Ns: 3000 4767 Payload Packet <- 4768 Nr: 3001, Ns: 7000 4770 -> Payload packet (packet lost) 4771 Nr: 7001, Ns: 3001 4772 -> Payload packet (packet lost) 4773 Nr: 7001, Ns: 3002 4775 Payload Packet <- 4776 Nr: 3001, Ns: 7001 4778 -> Payload packet 4779 Nr: 7002, Ns: 3003 4780 -> Payload packet 4781 Nr: 7002, Ns: 3004 4783 (window full, waiting) 4785 -> Timeout, send Payload w/R bit set 4786 Nr: 7002 Ns: 3005 4787 Payload Packet <- 4788 Nr: 3006 Ns: 7002