idnits 2.17.1 draft-ietf-pppext-l2tp-06.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-26) 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 79 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 79 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 30 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 161: '... o MUST, SHALL, or MANDATORY --...' RFC 2119 keyword, line 164: '... o SHOULD or RECOMMEND -- This ...' RFC 2119 keyword, line 167: '... o MAY or OPTIONAL -- This item...' RFC 2119 keyword, line 616: '...e of 0 is thus special and MUST NOT be...' RFC 2119 keyword, line 689: '...Nr and Ns fields MUST be present in pa...' (115 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1201 has weird spacing: '... its actual...' == Line 1485 has weird spacing: '...d their tunne...' == Line 2653 has weird spacing: '...message encod...' == Line 3403 has weird spacing: '...e local wai...' == Line 3404 has weird spacing: '...ndicate tunne...' == (1 more instance...) == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'H' on line 341 -- Looks like a reference, but probably isn't: 'R' on line 343 -- Looks like a reference, but probably isn't: 'U' on line 344 -- Looks like a reference, but probably isn't: 'L' on line 342 -- Looks like a reference, but probably isn't: 'N' on line 345 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1340 (ref. '5') (Obsoleted by RFC 1700) -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-02) exists of draft-grant-tacacs-00 -- Possible downref: Normative reference to a draft: ref. '7' -- Unexpected draft version: The latest known version of draft-ietf-radius-radius is -04, but you're referring to -05. Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group Kory Hamzeh 3 INTERNET DRAFT Ascend Communications 4 Category: Internet Draft Tim Kolar 5 Title: draft-ietf-pppext-l2tp-06.txt Cisco Systems 6 Date: August 1997 Morgan Littlewood 7 Cisco Systems 8 Gurdeep Singh Pall 9 Microsoft Corporation 10 Bill Palter 11 Cisco Systems 12 Jeff Taarud 13 Copper Mountain Networks 14 W. Mark Townsley 15 IBM 16 Andrew J. Valencia 17 Cisco Systems 18 William Verthein 19 U.S. Robotics 21 Layer Two Tunneling Protocol "L2TP" 23 Status of this Memo 25 This document is an Internet-Draft. Internet-Drafts are working 26 documents of the Internet Engineering Task Force (IETF), its areas, 27 and its working groups. Note that other groups may also distribute 28 working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months. Internet-Drafts may be updated, replaced, or obsoleted by 32 other documents at any time. It is not appropriate to use Internet- 33 Drafts as reference material or to cite them other than as a 34 ``working draft'' or ``work in progress.'' 36 To learn the current status of any Internet-Draft, please check the 37 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 38 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 39 munnari.oz.au. 41 Abstract 43 Virtual dial-up allows many separate and autonomous protocol domains 44 to share common access infrastructure including modems, Access 45 Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up 46 via PPP [1]. This document describes the Layer Two Tunneling 47 Protocol (L2TP) which permits the tunneling of the link layer (i.e., 48 HDLC, async HDLC) of PPP. Using such tunnels, it is possible to 49 divorce the location of the initial dial-up server from the location 50 at which the dial-up protocol connection is terminated and access to 51 the network provided. 53 Table of Contents 55 1.0 Introduction 56 1.1 Conventions 57 1.2 Terminology 58 2.0 Problem Space Overview 59 2.1 Initial Assumptions 60 2.2 Topology 61 2.3 Providing Virtual Dial-up Services--a walk-through 62 3.0 Service Model Issues 63 3.1 Security 64 3.2 Address Allocation 65 3.3 Authentication 66 3.4 Accounting 67 4.0 Protocol Overview 68 4.1 Control Message Overview 69 4.2 Payload Packet Overview 70 5.0 Message Format and Protocol Extensibility 71 5.1 AVP 72 5.2 Control Message Format 73 5.3 Payload Message Format 74 5.4 Control Message Types 75 5.5 AVP Summary 76 5.6 Result and Error Code Summary 77 5.7 Hiding of AVP values 78 6.0 Control Connection Protocol Specification 79 6.1 Start-Control-Connection-Request 80 6.2 Start-Control-Connection-Reply 81 6.3 Start-Control-Connection-Connected 82 6.4 Stop-Control-Connection-Notification 83 6.5 (reserved) 84 6.6 Hello 85 6.7 Outgoing-Call-Request 86 6.8 Outgoing-Call-Reply 87 6.9 Outgoing-Call-Connected 88 6.10 Incoming-Call-Request 89 6.11 Incoming-Call-Reply 90 6.12 Incoming-Call-Connected 91 6.13 (reserved) 92 6.14 Call-Disconnect-Notify 93 6.15 WAN-Error-Notify 94 6.16 Set-Link-Info 95 7.0 Control Connection State Machines 96 7.1 Control Connection Protocol Operation 97 7.2 Control Connection States 98 7.2.1 Control Connection Establishment 99 7.3 Timing considerations 100 7.4 Incoming Calls 101 7.4.1 LAC Incoming Call States 102 7.4.2 LNS Incoming Call States 103 7.5 Outgoing calls 104 7.5.1 LAC Outgoing Call States 105 7.5.2 LNS Outgoing Call States 106 8.0 L2TP Over Specific Media 107 8.1 IP/UDP 108 8.2 IP 109 9.0 Security Considerations 110 9.1 Tunnel Endpoint Security 111 9.2 Client Security 112 10.0 Acknowledgments 113 11.0 Contacts 114 12.0 References 115 Appendix A: Acknowledgment Time-Outs 116 Appendix B: Acknowledgment Time-Out and Window Adjustment 117 Appendix C: Handling of out-of-order packets 118 Appendix D: Transport Layer Adaptive Time-Outs and Window Adjustment 119 Appendix E: Examples of L2TP sequence numbering 120 E.1 Lock-step tunnel establishment 121 E.2 Multiple packets acknowledged 122 E.3 Lost packet with retransmission 124 1.0 Introduction 126 The traditional dial-up network service on the Internet is for 127 registered IP addresses only. A new class of virtual dial-up 128 application which allows multiple protocols and unregistered IP 129 addresses is also desired on the Internet. Examples of this class of 130 network application are support for privately addressed IP, IPX, and 131 AppleTalk dial-up via PPP across existing Internet infrastructure. 133 The support of these multiprotocol virtual dial-up applications is of 134 significant benefit to end users, enterprises, and Internet Service 135 providers as it allows the sharing of very large investments in 136 access and core infrastructure and allows local calls to be used. It 137 also allows existing investments in non-IP protocol applications to 138 be supported in a secure manner while still leveraging the access 139 infrastructure of the Internet. 141 It is the purpose of this draft to identify the issues encountered in 142 integrating multiprotocol dial-up services into an existing Internet 143 Service Provider's Point of Presence (hereafter referred to as ISP 144 and POP, respectively), and to describe the L2TP protocol which 145 permits the leveraging of existing access protocols. 147 This protocol may also be used to solve the "multilink hunt-group 148 splitting" problem. Multilink PPP, often used to aggregate ISDN B 149 channels, requires that all channels composing a multilink bundle be 150 grouped at a single NAS. Because L2TP makes a PPP session appear at 151 a location other than the physical point at which the session was 152 physically received, it can be used to make all channels appear at a 153 single NAS, allowing multilink operation even when the physical calls 154 are spread across distinct physical NAS's. 156 1.1 Conventions 158 The following language conventions are used in the items of 159 specification in this document: 161 o MUST, SHALL, or MANDATORY -- This item is an absolute 162 requirement of the specification. 164 o SHOULD or RECOMMEND -- This item should generally be followed 165 for all but exceptional circumstances. 167 o MAY or OPTIONAL -- This item is truly optional and may be 168 followed or ignored according to the needs of the implementor. 170 1.2 Terminology 172 Analog Channel 174 A circuit-switched communication path which is intended to carry 175 3.1 Khz audio in each direction. 177 Digital Channel 179 A circuit-switched communication path which is intended to carry 180 digital information in each direction. 182 Call 184 A connection or attempted connection between two terminal 185 endpoints on a PSTN or ISDN--for example, a telephone call between 186 two modems. 188 CHAP 190 Challenge Authentication Protocol, a PPP cryptographic 191 challenge/response authentication protocol in which the cleartext 192 password is not passed in the clear over the line. 194 CLID 196 Calling Line ID, an indication to the receiver of a call as to the 197 phone number of the caller. 199 Control Messages 200 Control messages are exchanged between LAC, LNS pairs, and operate 201 in-band within the tunnel protocol. Control messages govern 202 aspects of the tunnel and sessions within the tunnel. 204 Dial User 206 An end-system or router attached to an on-demand PSTN or ISDN 207 which is either the initiator or recipient of a call. 209 DNIS 211 Dialed Number Information String, an indication to the receiver of 212 a call as to what phone number the caller used to reach it. 214 EAP 215 Extensible Authentication Protocol, a framework for a family of 216 PPP authentication protocols, including cleartext, 217 challenge/response, and arbitrary dialog sequences. 219 L2TP Access Concentrator (LAC) 221 A device attached to one or more PSTN or ISDN lines capable of PPP 222 operation and of handling the L2TP protocol. The LAC needs only 223 implement the media over which L2TP is to operate to pass traffic 224 to one or more LNS's. It may tunnel any protocol carried within 225 PPP. 227 L2TP Network Server (LNS) 229 An LNS operates on any platform capable of PPP termination. The 230 LNS handles the server side of the L2TP protocol. Since L2TP 231 relies only on the single media over which L2TP tunnels arrive, 232 the LNS may have only a single LAN or WAN interface, yet still be 233 able to terminate calls arriving at any LAC's full range of PPP 234 interfaces (async, synchronous ISDN, V.120, etc.). 236 Network Access Server (NAS) 238 A device providing temporary, on-demand network access to users. 239 This access is point-to-point using PSTN or ISDN lines. 241 PAP 243 Password Authentication Protocol, a simple PPP authentication 244 mechanism in which a cleartext username and password are 245 transmitted to prove identity. 247 Session 249 L2TP is connection-oriented. The LNS and LAC maintain state for 250 each user that is attached to an LAC. A session is created when 251 an end-to-end PPP connection is attempted between a dial user and 252 the LNS, or when a outbound call is initiated. The datagrams 253 related to a session are sent over the tunnel between the LAC and 254 LNS. 256 Quality of Service (QOS) 258 A given Quality of Service level is sometimes required for a given 259 user being tunneled between an LNS-LAC pair. For this scenario, a 260 unique L2TP tunnel is created (generally on top of a new SVC) and 261 encapsulated directly on top of the media providing the indicated 262 QOS. 264 Switched Virtual Circuit (SVC) 266 An L2TP-compatible media on top of which L2TP is directly 267 encapsulated. SVC's are dynamically created, permitting tunnel 268 media to be created dynamically in response to desired LNS-LAC 269 connectivity requirements. 271 Tunnel 273 A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP 274 datagrams between the LAC and the LNS; many sessions can be 275 multiplexed over a single tunnel. A control connection operating 276 in-band over the same tunnel controls the establishment, release, 277 and maintenance of sessions and of the tunnel itself. 279 2.0 Problem Space Overview 281 In this section we describe in high level terms the scope of the 282 problem that will be explored in more detail in later sections. 284 2.1 Initial Assumptions 286 We begin by assuming that Internet access is provided by an ISP and 287 that the ISP wishes to offer services other than traditional 288 registered IP address based services to dial-up users of the network. 290 We also assume that the user of such a service wants all of the 291 security facilities that are available to him in a dedicated dial-up 292 configuration. In particular, the end user requires: 294 + End System transparency: Neither the remote end system nor his 295 home site hosts should require any special software to use this 296 service in a secure manner. 298 + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or 299 through other dialogs, for instance, a textual exchange on V.120 300 before starting PPP. This will include TACACS+ [7] and RADIUS [8] 301 solutions as well as support for smart cards and one-time passwords. 302 The authentication should be manageable by the user independently of 303 the ISP. 305 + Addressing should be as manageable as dedicated dial-up solutions. 306 The address should be assigned by the home site and not the ISP. 308 + Authorization should be managed by the home site as it would in a 309 direct dial-up solution. 311 + Accounting should be performed both by the ISP (for billing 312 purposes) and by the user (for charge-back and auditing). 314 2.2 Topology 316 Shown below is a generic Internet with Public switched Telephone 317 Network (PSTN) access (i.e., async PPP via modems) and Integrated 318 Services Digital Network (ISDN) access (i.e., synchronous PPP 319 access). Remote users (either async or ISDN PPP) will access the 320 Home LAN as if they were dialed into the L2TP Network Server (LNS), 321 although their physical dial-up is via the ISP Network Access Server. 323 ...----[L]----+---[L]-----... 324 | 325 | 326 [H] 327 | 328 ________|________________________ 329 | | 330 ________|__ ______|________ 331 | | | | 332 | PSTN [R] [R] ISDN | 333 | Cloud | | Cloud [N]__[U] 334 | | Internet | | 335 | | [R] | 336 [N]______[R] |_____________| 337 | | | 338 | | | 339 [U] |________________________________| 341 [H] = LNS 342 [L] = Home LAN(s) 343 [R] = Router 344 [U] = Remote User 345 [N] = ISP Network Access Server 347 2.3 Providing Virtual dial-up Services--a walk-through 349 To motivate the following discussion, this section walks through an 350 example of what might happen when a Virtual dial-up client initiates 351 access. 353 The remote user initiates a PPP connection to an ISP via either the 354 PSTN or ISDN. The Network Access Server (NAS) accepts the connection 355 and the PPP link is established (L2TP also permits the NAS to check 356 with an LNS after call indication prior to accepting the call--this 357 is useful where DNIS or CLID information is available in the incoming 358 call notification). 360 The ISP may now undertake a partial authentication of the end 361 system/user. Only the username field would be interpreted to 362 determine whether the user requires a Virtual dial-up service. It is 363 expected--but not required--that usernames will be structured (e.g. 364 username@company.com). Alternatively, the ISP may maintain a 365 database mapping users to services. In the case of Virtual dial-up, 366 the mapping will name a specific endpoint, the LNS. 368 Alternatively, the ISP may have already determined the target LNS 369 from DNIS. If the LNS is willing to accept tunnel creation without 370 any authentication of the caller, the NAS may tunnel the PPP 371 connection without ever having communicated with the remote user. 373 If a virtual dial-up service is not required, standard access to the 374 Internet may be provided. 376 If no tunnel connection currently exists to the desired LNS, one is 377 initiated. L2TP is designed to be largely insulated from the details 378 of the media over which the tunnel is established; L2TP requires only 379 that the tunnel media provide packet oriented point-to-point 380 connectivity. Obvious examples of such media are UDP, Frame Relay 381 PVC's, or X.25 VC's. 383 Once the tunnel exists, an unused slot within the tunnel, a "Call 384 ID", is allocated, and a connect indication is sent to notify the LNS 385 of this new dial-up session. The LNS either accepts the connection, 386 or rejects it. Rejection may include a reason indication, which may 387 be displayed to the dial-up user, after which the call should be 388 disconnected. 390 The initial setup notification may include the authentication 391 information required to allow the LNS to authenticate the user and 392 decide to accept or decline the connection. In the case of CHAP, the 393 set-up packet includes the challenge, username and raw response. For 394 PAP or text dialog, it includes username and clear text password. 395 The LNS may choose to use this information to complete its 396 authentication, avoiding an additional cycle of authentication. 398 If the LAC negotiated PPP LCP before initiating the tunnel, the 399 initial setup notification may also include a copy of the LCP 400 CONFREQ's sent in each direction which completed LCP negotiation. 401 The LNS may use this information to initialize its own PPP state 402 (thus avoiding an additional LCP negotiation), or it may choose to 403 initiate a new LCP CONFREQ exchange. 405 If the LNS accepts the connection, it creates a "virtual interface" 406 for PPP in a manner analogous to what it would use for a direct- 407 dialed connection. With this "virtual interface" in place, link 408 layer frames may now pass over this tunnel in both directions. 409 Frames from the remote user are received at the POP, stripped of CRC, 410 link framing, and transparency bytes, encapsulated in L2TP, and 411 forwarded over the appropriate tunnel. 413 The LNS accepts these frames, strips L2TP, and processes them as 414 normal incoming frames for the appropriate interface and protocol. 415 The "virtual interface" behaves very much like a hardware interface, 416 with the exception that the hardware in this case is physically 417 located at the ISP POP. The other direction behaves analogously, 418 with the LNS encapsulating the packet in L2TP, and the NAS stripping 419 L2TP before transmitting it out the physical interface to the remote 420 user. For the remainder of this document, a NAS operating as a peer 421 to an LNS will be referred to as an L2TP Access Concentrator, or 422 "LAC". 424 At this point, the connectivity is a point-to-point PPP session whose 425 endpoints are the remote user's networking application on one end and 426 the termination of this connectivity into the LNS's PPP support on 427 the other. Because the remote user has become simply another dial-up 428 client of the LNS, client connectivity can now be managed using 429 traditional mechanisms with respect to further authorization, 430 protocol access, and packet filtering. 432 Accounting can be performed at both the LAC as well as the LNS. This 433 document illustrates some Accounting techniques which are possible 434 using L2TP, but the policies surrounding such Accounting are outside 435 the scope of this specification. 437 L2TP offers optional facilities which maximize compatibility with 438 legacy client requirements; L2TP connect notifications for PPP 439 clients can contain sufficient information for an LNS to authenticate 440 and initialize its LCP state machine. With these facilities, the 441 remote user need not be queried a second time for PPP authentication, 442 nor undergo multiple rounds of LCP negotiation and convergence. 443 These techniques are intended to optimize connection setup, and are 444 not intended to deprecate any functions required by the PPP 445 specification. 447 3.0 Service Model Issues 449 There are several significant differences between the standard 450 Internet access service and the Virtual dial-up service with respect 451 to authentication, address allocation, authorization and accounting. 452 The details of the differences between these services and the 453 problems presented by these differences are described below. The 454 mechanisms used for Virtual Dial-up service are intended to coexist 455 with more traditional mechanisms; it is intended that an ISP's POP 456 can simultaneously service ISP clients as well as Virtual dial-up 457 clients. 459 3.1 Security 461 For the Virtual dial-up service, the ISP pursues authentication only 462 to the extent required to discover the user's apparent identity (and 463 by implication, their desired LNS). This may involve no more than 464 detecting DNIS information when a call arrives, or may involve full 465 LCP negotiation and initiation of PPP authentication. As soon as the 466 apparent identity is determined, a connection to the LNS is initiated 467 with any authentication information gathered by the ISP. The LNS 468 completes the authentication by either accepting the connection, or 469 rejecting it. 471 The LNS may need to protect against attempts by third parties to 472 establish tunnels to the LNS. Tunnel establishment can include 473 authentication to protect against such attacks. 475 3.2 Address Allocation 477 For an Internet service, the user accepts that the IP address may be 478 allocated dynamically from a pool of ISP addresses. This model often 479 means that the remote user has little or no access to their home 480 network's resources, due to firewalls and other security policies 481 applied by the home network to accesses from external IP addresses. 483 For the Virtual dial-up service, the LNS can exist behind the home 484 firewall, allocating addresses which are internal (and, in fact, can 485 be RFC1918 addresses, or non-IP addresses). Because L2TP tunnels 486 exclusively at the frame layer, the actual policies of such address 487 management are irrelevant to correct Virtual dial-up service; for all 488 purposes of PPP protocol handling, the dial-in user appears to have 489 connected at the LNS. 491 3.3 Authentication 493 The authentication of the user occurs in three phases; the first at 494 the ISP, and the second and optional third at the LNS. 496 The ISP uses DNIS, CLID, or username to determine that a Virtual 497 dial-up service is required and initiates the tunnel connection to 498 the appropriate LNS. Once a tunnel is established, The ISP NAS 499 allocates a new Call ID and initiates a session by forwarding the 500 gathered authentication information. 502 The LNS undertakes the second phase by deciding whether or not to 503 accept the connection. The connection indication may include CHAP, 504 PAP, EAP, or textual authentication information. Based on this 505 information, the LNS may accept the connection, or may reject it (for 506 instance, it was a PAP request and the username/password are found to 507 be incorrect). 509 Once the connection is accepted, the LNS is free to pursue a third 510 phase of authentication at the PPP layer. These activities are 511 outside the scope of this specification, but might include an 512 additional cycle of LCP authentication, proprietary PPP extensions, 513 or textual challenges carried via a TCP/IP telnet session. 515 3.4 Accounting 517 It is a requirement that both the LAC and the LNS be capable of 518 providing accounting data and hence both may count packets, octets 519 and connection start and stop times. 521 Since Virtual dial-up is an access service, accounting of connection 522 attempts (in particular, failed connection attempts) is of 523 significant interest. The LNS can reject new connections based on 524 the authentication information gathered by the LAC, with 525 corresponding logging. For cases where the LNS accepts the 526 connection and then continues with further authentication, the LNS 527 might subsequently disconnect the client. For such scenarios, the 528 disconnection indication back to the LAC may also include a reason. 530 Because the LNS can decline a connection based on the authentication 531 information collected by the LAC, accounting can easily draw a 532 distinction between a series of failed connection attempts and a 533 series of brief successful connections. Lacking this facility, the 534 LNS must always accept connection requests, and would need to 535 exchange a number of PPP packets with the remote system. Note that 536 the LNS could use this information to decide to accept the connection 537 (which protects against most invalid connection attempts) while still 538 insisting on running its own CHAP authentication (for instance, to 539 protect against CHAP replay attacks). 541 4.0 Protocol Overview 543 There are two parallel components of L2TP operating over a given 544 tunnel: control messages between each LAC-LNS pair, and payload 545 packets between the same LAC-LNS pair. The latter are used to 546 transport L2TP encapsulated PPP packets for user sessions between the 547 pair. 549 The Nr (Next Received) and Ns (Next Sent) fields are always present 550 in control messages, and are optionally present in payload messages. 551 A single sequence number state is maintained for all control 552 messages, and a distinct state is maintained for the payload of each 553 user session within the tunnel. Each state is initialized so the 554 first packet is sent with an Ns of 0. Nr is sent reflecting one more 555 than the last in-order received packet; if sent before any packet is 556 received it would be 0, indicating that it expects the next new Ns 557 value received to be 0. 559 The sequence number state is maintained and updated as packets are 560 sent. A message (control or payload) with a zero-length body 561 indicates that the packet is only used to communicate Nr and Ns 562 fields. The Nr and Ns fields are filled in as above, but the 563 sequence number state remains the same. For non-zero-length body 564 messages, the sequence number state is incremented (modulo 2**16) 565 after it is copied to the packet's Ns field. Thus a zero-length 566 message's Ns field will reflect one more than the Ns of the last 567 non-zero-length message sent. 569 Upon receipt of a non-zero-length message, the receiving peer must 570 acknowledge the message by sending back the latest Nr value. This 571 updated Nr value can be piggybacked in any non-zero-length outgoing 572 messages that the peer may happen to send back. However, if the peer 573 does not have a non-zero-length message to transmit for a period of 574 1/4 of the timeout interval after receiving a non-zero-length message 575 then it should send a zero-length message containing the latest 576 sequence number state, as described above. 578 See Appendix E for some examples of how sequence numbers progress. 580 4.1 Control Message Overview 582 Before PPP tunneling can occur between an LAC and LNS, control 583 messages must be exchanged between them. Control messages are 584 exchanged over the same tunnel which will be used to forward 585 payload data once L2TP call control and management information 586 have been passed. The control messages are responsible for 587 establishment, management, and release of sessions carried through 588 the tunnel, as well as status on the tunnel itself. It is the 589 means by which an LNS is notified of an incoming call at an 590 associated LAC, as well as the means by which an LAC is instructed 591 to place an outgoing call. 593 A tunnel may be established by either an LAC (for incoming calls) 594 or an LNS (for outgoing calls). Following the establishment of 595 the tunnel, the LNS and LAC configure the tunnel by exchanging 596 Start-Control-Connection-Request and -Reply messages. These 597 messages are also used to exchange information about basic 598 operating capabilities of the LAC and LNS. Once the control 599 message exchange is complete, the LAC may initiate sessions by 600 indicating inbound requests, or the LNS by requesting outbound 601 calls. If both ends of the tunnel have the ability to act as an 602 LAC and LNS concurrently, then nothing prohibits establishing 603 incoming or outgoing calls from both sides of the same tunnel. 604 Control messages may indicate changes in operating characteristics 605 of an individual user session with a Set-Link-Info message. 606 Individual sessions may be released by either the LAC or LNS, also 607 through control messages. 609 Independent Call ID values are established for each end of a user 610 session. The sender of a packet associated with a particular 611 session places the Call ID established by its peer in the Call ID 612 header field of all outgoing packets. For the cases where a Call 613 ID has not yet been assigned from the peer (i.e., during call 614 establishment of a new session), the Call ID field is sent as 0, 615 and further fields within the message are used to identify the 616 session. The Call ID value of 0 is thus special and MUST NOT be 617 used as an Assigned Call ID. 619 A mechanism for detection of tunnel connectivity problems is 620 provided by the reliable transport layer of L2TP. The transport 621 layer of L2TP performs control message retransmission. If the 622 number of retransmission attempts for a given control message 623 exceeds a configured maximum value, the tunnel is reset. This 624 retransmission mechanism exists in both the LNS and LAC ends of 625 the tunnel. 627 A keepalive mechanism is employed by the L2TP higher layer in 628 order to differentiate tunnel outages from extended periods of no 629 control or data activity on a tunnel. This is accomplished by the 630 higher injecting Hello control messages into the control stream 631 after a specified period of time elapses since the last data or 632 control was received on the tunnel. As for any other control 633 message, if the transport does not receive an ACK for the Hello 634 message after the normal number of retransmissions the tunnel is 635 declared down and is reset. The transport layer reset mechanism 636 along with the injection of Hello messages ensures that a 637 connectivity failure between the LNS and the LAC will be detected 638 at both ends of a tunnel in a timely manner. 640 It is intended that control messages will also carry management 641 related information in the future, such as a message allowing the 642 LNS to request the status of a given LAC; these message types are 643 not defined in this document. 645 4.2 Payload Packet Overview 646 Once a tunnel is established and control messages have completed 647 tunnel setup, the tunnel can be used to carry user session PPP 648 packets for sessions involving a given LNS-LAC pair. The "Call 649 ID" field in the L2TP header indicates to which session a 650 particular PPP packet belongs. In this manner, PPP packets are 651 multiplexed and demultiplexed over a single tunnel between a given 652 LNS-LAC pair. The "Call ID" field value is established during the 653 exchange of call setup control messages. 655 It is legal for multiple tunnels to exist between a given LNS-LAC 656 pair. This is useful where each tunnel is used for a single user 657 session, and the tunnel media (an SVC, for instance) has specific 658 QOS attributes dedicated to a given user. L2TP provides a tunnel 659 identifier so that individual tunnels can be identified, even when 660 arriving from a single source LAC or LNS. 662 The L2TP header also contains optional acknowledgment and 663 sequencing information that can be used to perform congestion and 664 flow control over the tunnel. Control messages are used to 665 determine rate and buffering parameters that are used to regulate 666 the flow 668 of PPP packets for a particular session over the tunnel. 670 The receiving peer indicates whether flow-control is to be 671 performed for payload packets sent to it. If a peer issues a 672 Receive Window Size AVP with a non-zero value during session 673 establishment then the sending peer must abide by the indicated 674 window size value. If a receiving peer does not wish to flow 675 control the payload messages sent to it, it should not issue the 676 Receive Window Size AVP with a non-zero value. Issuing a Receive 677 Window Size AVP with a zero value has special significance. It 678 indicates that the receiver does not want to perform flow-control 679 but it does want the sending peer to provide Ns values in payload 680 packets so that it can detect (and perhaps reorder) packets 681 received out of order. 683 In the case where neither peer issues a Receive Window Size AVP 684 during session establishment, the optional Nr and Ns fields are 685 absent in all payload messages for that session. In the case 686 where either peer wishes to perform flow-control or to detect 687 out-of-order receive messages (as indicated by the sending of the 688 Receive Window Size AVP with non-zero or zero value, respectively) 689 the Nr and Ns fields MUST be present in payload messages sent by 690 both peers. Both MUST provide proper Nr and Ns values in all 691 messages transmitted. A proper Ns value starts at 0 and 692 increments by one for each transmitted payload message and a 693 proper Nr value is the current value of the receive sequence 694 number state variable. 696 If a receiving peer offers a non-zero receive window size to a 697 sending peer then the sending peer SHOULD abide by this window 698 size value. The sending peer should stop sending payload messages 699 when the window is full; i.e., x consecutive messages have been 700 sent but have not been acknowledged, where x is the value of the 701 Receive Window Size AVP. Implementors should take care to avoid 702 the situation where loss of an ACK by a sending peer with a full 703 transmit window causes a session to hang forever, due to the fact 704 there are no retransmissions of payload messages. Steps must be 705 taken to reopen the transmit window (at least to a value of 1) 706 upon expiration of an ACK wait timeout. See Appendix B for more 707 details. 709 L2TP does not specify the particular algorithms to use for 710 congestion control. Suggested algorithms for the determination of 711 adaptive time-outs to recover from dropped data or acknowledgments 712 on the tunnel are included in Appendix A of this document. 714 L2TP does not include a "Receive-Not-Ready" function. It is 715 expected that the flow-control mechanism used will provide an 716 adequate "pacing" mechanism so that the sender does not overflow 717 the receiver's allotted receive window and receive buffers. It is 718 permissible for the receiving peer to withhold Acks if it is 719 unable to accept more data for a connection. Thus, unlike for the 720 Control Message session, the sending peer MUST NOT clear a session 721 (or the whole tunnel) as a result of not receiving timely 722 acknowledgments for transmitted packets. The job of detecting a 723 non-functioning tunnel lies solely with the Control Message 724 functions of L2TP. 726 5. Message Format and Protocol Extensibility 728 L2TP defines a set of control messages sent in packets over the 729 tunnel between an LNS and a given LAC. The exact technique for 730 initiating a tunnel between an LNS-LAC pair is specific to the tunnel 731 media, and specific media are described in section 8.0. 733 Once media-level connectivity is reached, L2TP message formats define 734 the protocol for an LAC and LNS to manage the tunnel and its 735 associated sessions. 737 In each case where a field is optional, if the field is not present, 738 its space does not exist in the packet. Existing fields are placed 739 back-to-back to form the packet. 741 5.1 AVP 743 To maximize extensibility while still permitting interoperability, 744 a uniform method for encoding message types and bodies is used 745 throughout L2TP. This encoding will be termed an AVP (Attribute- 746 Value Pair) in the remainder of this document. Each AVP is 747 encoded as: 749 0 1 2 3 750 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 |M|H|0|0|0|0| Overall Length | Vendor ID | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Attribute | Value... | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | [until Overall Length is reached]... | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 The first six bits are a bit mask, describing the general 760 attributes of the AVP. The M bit, known as the "mandatory" bit, 761 controls the behavior required of an implementation which receives 762 an AVP which it does not recognize. 764 If M is set on an AVP associated call management, any session 765 associated with this AVP MUST be terminated. If the AVP is 766 associated with the overall tunnel, the entire tunnel (and all 767 sessions within) MUST be terminated. If M is not set, an 768 unrecognized AVP should be ignored. 770 The H bit, known as the "hidden" bit, controls the hiding of the 771 data in the value field of an AVP. This capability can be used to 772 avoid the passing of sensitive data, such as user passwords, as 773 cleartext in an AVP. Section 5.7 describes the procedure for 774 performing AVP value hiding. 776 Overall Length encodes the number of octets (including the Overall 777 Length field itself) contained in this AVP. It is 10 bits, 778 permitting a maximum of 1024 bytes of data in a single AVP. 780 Vendor ID is the IANA assigned "SMI Network Management Private 781 Enterprise Codes" value, encoded in network byte order. The value 782 0, reserved in this table, corresponds to IETF adopted Attribute 783 values, defined within this document. Any vendor wishing to 784 implement L2TP extensions can use their own Vendor ID along with 785 private Attribute values, guaranteeing that they will not collide 786 with any other vendor's extensions, nor with future IETF 787 extensions. 789 Attribute is the actual attribute, a 16-bit value with a unique 790 interpretation across all AVP's defined under a given Vendor ID. 792 Value follows immediately after the Attribute field, and runs for 793 the remaining octets indicated in the Overall Length (i.e., 794 Overall Length minus six octets of header). 796 AVP's should be kept compact; the combined AVP's within a control 797 message MUST NOT ever cause a control message's total length to 798 exceed 1500 bytes in length. 800 5.2 Control Message Format 802 Each L2TP control message begins with a 16 octet header portion 803 followed by zero or more AVP's. This header is formatted: 805 0 1 2 3 806 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 |T|1|0|0|1|0|0|0| | Ver | Length | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Tunnel ID | Call ID | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Ns | Nr | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Message Type AVP... | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | ... (8 bytes) | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 The T bit MUST be 1, indicating a control message. The following 820 seven bits MUST be set to 1001000, making the header more 821 compatible in encoding with the payload message (defined in the 822 next section). 824 Ver MUST be the value 2, indicating a version 1 L2TP message 825 (values 0 and 1 are reserved to permit detection of L2F [2] and 826 PPTP [3] packets if they arrive intermixed). 828 Length is the overall length of the message, including header, 829 message type AVP, plus any additional AVP's associated with a 830 given control message type. 832 Tunnel ID and Call ID identify the tunnel and user session within 833 the tunnel to which a control message applies. If a control 834 message does not apply to a single user session within the tunnel 835 (for instance, a Stop-Control-Connection-Notification message), 836 Call ID MUST be set to 0. If an Assigned Tunnel ID has not yet 837 been received from the peer, Tunnel ID MUST be set to 0. Once an 838 Assigned Tunnel ID is received, all further packets MUST be sent 839 with Tunnel ID set to the indicated value. 841 Nr and Ns reflect the currently transmitted packet and latest 842 received packet respectively. See section 4.0. 844 5.3 Payload Message Format 846 PPP payload packets tunneled within L2TP have a smaller 847 encapsulation than the L2TP control message header, reducing 848 overhead of L2TP during the life of a tunneled PPP session. The 849 LNS is expected to be able to process user data packets of 1500 850 octets, not including L2TP and media encapsulation. The smallest 851 L2TP encapsulation is 6 octets; the largest is 14 octets (plus 852 padding bytes, if present). See section 8.1 for further MTU 853 considerations. 855 0 1 2 3 856 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 |T|L|I|C|F|K|O|P|0|0|0|0|0| Ver | Length (opt) | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Tunnel ID | Call ID | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Ns (opt) | Nr (opt) | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Offset Size (opt) | Offset pad... (opt) | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 The T bit MUST be 0, indicating payload. 869 Ver MUST be 2, indicating version 1 of the L2TP protocol. 871 If the L bit is set, the Length field is present, indicating the 872 total length of the received packet. 874 The I and C bits are reserved and MUST be set to 0. These bit 875 positions represent options no longer present in L2TP. 877 If the F bit is set, both the Nr and Ns fields are present. Ns 878 indicates indicates the sequence number of the packet being sent. 879 The Ns value of a message being transmitted is copied from the 880 current value of the send sequence number state variable. The 881 send sequence number state variable is incremented by one after 882 copying to the Ns field only if the payload size of the message 883 being sent is non-zero. Nr indicates the next packet sequence 884 number to be received (if the last non-zero-length data packet had 885 Ns set to 1, the Nr sent back would be 2). Together, these fields 886 can be used to handle out-of-order packets, and to provide flow 887 control for the connection. 889 An L2TP peer setting the F bit, and placing Nr and Ns fields in 890 its messages, MUST have previously received or sent a Receive 891 Window Size AVP during establishment of the session. The Nr and 892 Ns fields are present and updated as described in section 4.0 if 893 either side has specified an intention to do payload flow control. 895 The K bit is reserved MUST be set to 0. This bit position 896 represents a function no longer present in L2TP. The bits 897 following the K bit MUST all be 0. 899 The Offset Size field is present if the O bit is set in the header 900 flags. This field specifies the number of bytes past the L2TP 901 header at which the payload data is expected to start. It is 902 recommended that data thus skipped be initialized to 0's. If 903 Offset Size is 0, or the O bit is not set, the first byte 904 following the last byte of L2TP header is the first byte of 905 payload data. 907 A packet received with a reserved bit set to 1 MUST be silently 908 discarded, unless the bit is defined for an extension that is 909 known to the implementation. 911 If the P bit is set, this packet should receive preferential 912 treatment at the LAC in its queueing for transmission to the 913 client. LCP echo requests used as a keepalive for the link, for 914 instance, should generally be sent from the LNS with this bit set. 915 Without it, a temporary interval of congestion of the transmission 916 queues could result in the interference with keepalive messages 917 and unnecessary loss of the link. 919 5.4 Control Message Types 921 Control message and AVP types defined in this specification exist 922 under Vendor ID 0, indicating IETF defined behavior. The actual 923 message and AVP semantics are defined in the next section. This 924 section includes tables that summarize all currently defined 925 message and AVP types. 927 Each message type entry in the table below indicates: the integer 928 value assigned to the message type; the message type abbreviation 929 used in the AVP Summary Table of Sec. 5.5; and the full name of 930 the message type. 932 The integer value assigned to each message type is placed in the 933 Value field of the Message Type AVP. This AVP MUST be the first 934 AVP in a message. The currently defined control message types, 935 grouped by function, are: 937 Control Connection Management 939 1 (SCCRQ) Start-Control-Connection-Request 940 2 (SCCRP) Start-Control-Connection-Reply 941 3 (SCCCN) Start-Control-Connection-Connected 942 4 (StopCCN) Stop-Control-Connection-Notification 943 5 (reserved) 944 6 Hello 946 Call Management 948 7 (OCRQ) Outgoing-Call-Request 949 8 (OCRP) Outgoing-Call-Reply 950 9 (OCCN) Outgoing-Call-Connected 951 10 (ICRQ) Incoming-Call-Request 952 11 (ICRP) Incoming-Call-Reply 953 12 (ICCN) Incoming-Call-Connected 954 13 (reserved) 955 14 (CDN) Call-Disconnect-Notify 957 Error Reporting 959 15 (WEN) WAN-Error-Notify 961 PPP Session Control 962 16 (SLI) Set-Link-Info 964 5.5 AVP Summary 966 The following table lists all standard L2TP attributes currently 967 defined. The "Attr" column indicates the integer value assigned to 968 this attribute. The "M" column indicates the setting of the 969 "Mandatory" bit of the AVP header for each attribute. The "Len" 970 field indicates the size of the AVP including the AVP header. A 971 "+" in this column indicates that the length varies depending upon 972 the length of the actual contents of the value field. 974 The "(usage)" list for each entry indicates the message types that 975 utilize each AVP (See command table of Sec. 5.4). An abbreviation 976 shown in mixed or upper case letters indicates that the 977 corresponding AVP MUST be present in this message type; All lower 978 case indicates that the AVP may optionally appear in this message 979 type. 981 A brief summary of the type and contents of the value field for 982 each attribute is also given for each entry. Refer to the 983 individual message type descriptions that appear in Section 6 for 984 further details about the use of a particular AVP in a particular 985 message type. 987 Attr M Len Attribute Name (usage) 989 0 1 8 Message Type (ALL MESSAGES) 990 16 bit integer value indicating the message type, as defined in 991 table above. MUST be the first AVP in each message 993 1 1 10+ Result Code (CDN, StopCCN) 994 16 bit Integer value indicating result of corresponding request 995 or reason for issuing a request, 16 bit integer General Error 996 code and an optional ASCII string error message. See Result 997 and General Error code tables below. 999 2 1 8 Protocol Version (SCCRP, SCCRQ) 1000 8 bit L2TP Protocol and Revision numbers 1002 3 1 10 Framing Capabilities (SCCRP, SCCRQ) 1003 32 bit bitmask indicating supported framing types (e.g., 1004 synchronous and asynchronous) 1006 4 1 10 Bearer Capabilities (SCCRP, SCCRQ) 1007 32 bit bitmask indicating supported bearer types (e.g., analog 1008 and digital) 1010 5 0 14 Tie Breaker (sccrq) 1011 8 byte value used to break control connection establishment 1012 collisions 1014 6 0 8 Firmware Revision (sccrp, sccrq) 1015 16 bit integer representing vendor's firmware revision 1017 7 0 6+ Host Name (sccrp, sccrq) 1018 ASCII string name (e.g., DNS name) of issuer 1020 8 1 6+ Vendor Name (SCCRP, SCCRQ) 1021 ASCII string describing issuing device 1023 9 1 8 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 1024 16 bit integer tunnel ID assigned by sender 1026 10 1 8 Receive Window Size (ICCN, ICRP, OCCN, OCRQ, SCCRP, 1027 SCCRQ) 1028 16 bit integer receive window size offered by sender for a 1029 given call or control session 1031 11 1 6+ Challenge (SCCRP, SCCRQ) 1032 1 or more octet value issued by sender wishing to authenticate 1033 control session peer 1035 12 0 9+ Q.931 Cause Code (cdn) 1036 16 bit cause code, 1 octet cause message, and optional ASCII 1037 advisory message 1039 13 1 22 Challenge Response (SCCCN, SCCRP) 1040 16 octet CHAP type response to peer's Challenge 1042 14 1 8 Assigned Call ID (CCRQ, CDN, ICRP, ICRQ, OCRP, OCRQ) 1043 16 bit integer ID assigned to a call by sender 1045 15 1 6+ Call Serial Number (ICRQ, OCRQ) 1046 1 or more octet identifier assigned to a call 1048 16 1 10 Minimum BPS (OCRQ) 1049 32 bit integer indicating lowest acceptable line speed for call 1051 17 1 10 Maximum BPS (OCRQ) 1052 32 bit integer indicating highest acceptable line speed for 1053 call 1055 18 1 10 Bearer Type (ICRQ, OCRQ) 1056 Indicates bearer type (i.e., analog or digital) for call 1058 19 1 10 Framing Type (ICCN, OCCN, OCRQ) 1059 Indicates framing type (i.e., synchronous or asynchronous) for 1060 call 1062 20 1 8 Packet Processing Delay (ICCN, ICRP, OCCN, OCRQ) 1063 16 bit integer estimate of processing time of full window of 1064 received packets by sender 1066 21 1 6+ Dialed Number (icrq, OCRQ) 1067 ASCII string phone number called or to be called 1069 22 1 6+ Dialing Number (icrq) 1070 ASCII string phone number of caller 1072 23 1 6+ Sub-Address (icrq, ocrq) 1073 ASCII string containing additional dialing information 1075 24 1 10 Connect Speed (ICCN, OCCN, OCRP) 1076 16 bit integer actual line speed of connection 1078 25 1 10 Physical Channel ID (ICRQ, OCRP) 1079 16 bit vendor specific physical device identifier used for call 1081 26 0 6+ Initial LCP Confreq (iccn) 1082 Octet string containing initial CONFREQ received from client 1084 27 0 6+ Last Sent LCP Confreq (iccn) 1085 Octet string containing final CONFREQ sent to client 1087 28 0 6+ Last Received LCP Confreq (iccn) 1088 Octet string containing final CONFREQ received from client 1090 29 1 8 Proxy Authen Type (ICCN) 1091 16 bit integer code indicating client authentication type 1092 negotiated (e.g., PAP, CHAP) 1094 30 0 6+ Proxy Authen Name (iccn) 1095 ASCII string containing name returned by client in 1096 authentication response 1098 31 0 6+ Proxy Authen Challenge (iccn) 1099 Octet string Challenge presented by LAC to client 1101 32 0 8 Proxy Authen ID (iccn) 1102 16 bit integer of which low order octet is ID presented to 1103 client with Challenge. High order octet must be 0. 1105 33 1 6+ Proxy Authen Response (iccn) 1106 Octet string CHAP response or ASCII string password depending 1107 on authentication type used 1109 34 1 32 Call Errors (WEN) 1110 A reserved 16 bit word set to 0 followed by 6 32 bit integer 1111 connection error counters 1113 35 1 16 ACCM (SLI) 1114 A reserved 16 bit word set to 0 followed by 2 32 bit bitmasks 1115 containing Send and Receive ACCM values respectively 1117 36 1 6+ Random Vector (all messages) 1118 Variable length octet string containing a random sequence of 1119 values used to accomplish the optional "hiding" of other AVP 1120 values (See "H" bit description in Sec. 5.7). 1122 37 1 6+ Private Group ID (iccrq, iccn, ocrq) 1123 Variable length octet value used by the LAC or LNS to indicate 1124 that this call is to be associated with a particular customer 1125 group. 1127 5.6 Result and Error Code Summary 1129 The StopCCN and CDN message types contain a Result Code AVP which 1130 indicates the result of the previously requested operation. The 1131 Result Code can indicate that additional information pertaining to an 1132 error situation can be found in the Error Code field of the Result 1133 Code AVP. The meaning of the result code is tabulated under the 1134 specific type of message containing the result. Each 16-bit Result 1135 Code is immediately followed (in the same AVP) by a 16-bit General 1136 Error code value. 1138 General error codes pertain to types of errors which are not specific 1139 to any particular L2TP request, but rather to protocol or message 1140 format errors. If an L2TP reply indicates in its Result Code that a 1141 general error occurred, the General Error value should be examined to 1142 determine what the error was. The currently defined General Error 1143 codes and their meanings are: 1145 0 - No general error 1146 1 - No control connection exists yet for this LAC-LNS pair 1147 2 - Length is wrong 1148 3 - One of the field values was out of range or reserved field was 1149 non-zero 1150 4 - Insufficient resources to handle this operation now 1151 5 - The Call ID is invalid in this context 1152 6 - A generic vendor-specific error occurred in the LAC 1153 7 - Try another. If LAC is aware of other possible LNS 1154 destinations, it should try one of them. This can be used to 1155 guide an LAC based on LNS policy, for instance, the existence 1156 of multilink PPP bundles. 1158 If the length of the Result Code AVP specifies that the Value field 1159 is more than four octets in length, the remaining bytes after the 1160 General Error Code field are an arbitrary string providing further 1161 (possibly human readable) text associated with the condition. 1163 Generally, when a General Error Code of 6 is used, additional 1164 information about the error will be included in the Optional Message 1165 field that follows the Error Code field in the Result Code AVP. 1167 5.7 Hiding of AVP values 1169 The H ("Hidden") bit in the header of each AVP in a control message 1170 provides a mechanism to indicate to the receiving peer whether the 1171 contents of the AVP are hidden or present in cleartext. This feature 1172 can be used to hide sensitive control message data such as user 1173 passwords or user ID's. The H bit MUST NOT be set in the Random 1174 Vector AVP. 1176 The H bit MUST only be set if tunnel authentication was used and, 1177 therefore, a shared secret exists between the peers on either end of 1178 the tunnel. Therefore, the H bit MUST NOT be set in AVP's contained 1179 within the Start-Control-Connection-Request, -Reply, and -Connected 1180 messages. If the H bit is set in any AVP(s) in a given command 1181 message, a Random Vector AVP must also be present in the message and 1182 MUST precede the first AVP having an H-bit of 1. 1184 The following mechanism is applied to the contents of the value field 1185 of each AVP to which hiding is to be applied. An MD5 hash is 1186 performed on the concatenation of: 1188 - the 2 octet Attribute number of the AVP 1189 - the shared authentication secret 1190 - and an arbitrary length random vector 1192 The value of the random vector used in this hash is passed in the 1193 value field of a Random Vector AVP. This Random Vector AVP must be 1194 placed in the message by the sender before any hidden AVPs. The same 1195 random vector can be used for more than one hidden AVP in the same 1196 message. If a different random vector is used for the hiding of 1197 subsequent AVPs then a new Random Vector AVP must be placed in the 1198 command message before the first AVP to which it applies. 1200 A value to be hidden MAY be padded with additional octets to obscure 1201 its actual length. The subformat of the AVP's value, the entire 1202 contents of which is XORed with the MD5 hash, is indicated below. 1204 0 1 2 3 1205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Length | Value ... 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 ... | Padding ... 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 Length 1213 This is length of the Original AVP Value to be obscured in octets. 1215 Original AVP Value 1216 Value to be obscured. 1218 Padding 1219 Random additional bytes used to obscure length of Value. 1221 The MD5 hash value is then XORed with the first 16 octet or less 1222 segment of the Subformat Value and placed in the Value field of the 1223 AVP. If the Subformat Value is less than 16 octets, the Value is 1224 transformed as if the Subformat Value field had been padded to 16 1225 octets before the XOR, but only the actual bytes present in the 1226 Subformat Value are modified, and the length of the AVP is not 1227 altered. 1229 If the subformat value is longer than 16 octets, a second one-way MD5 1230 hash is calculated over a stream of octets consisting of the shared 1231 secret followed by the result of the first XOR. That hash is XORed 1232 with the second 16 octet or less segment of the subformat value and 1233 placed in the corresponding octets of the Value field of the AVP. 1235 If necessary, this operation is repeated, with each XOR result being 1236 used along with the shared secret to generate the next hash to XOR 1237 the next segment of the value with. This technique results in the 1238 content of the AVP being obscured, although the length of the AVP is 1239 still known. 1241 On receipt, the random vector is taken from the last Random Vector 1242 AVP encountered in the message prior to the AVP to be unhidden. The 1243 above process is then reversed to yield the original value. For more 1244 details on this hiding method, consult the RADIUS [8] RFC. 1246 The Random Vector AVP has the following format: 1248 Random Vector 1250 0 1 2 3 1251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 |1|0|0|0| 6 + String length | 0 | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | 36 | Random Octet String ... 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 The Random Vector AVP may be used in any message type. The Attribute 1259 value is 36 and it is marked mandatory. It is used to enable the 1260 hiding of the values of arbitrary AVPs. It MUST precede any AVP 1261 containing an AVP with the H-bit set but it MUST NOT itself have the 1262 H-bit set. More than one Random Vector AVP may appear in a message, 1263 in which case the one most closely preceding an AVP with the H-bit 1264 set pertains to that AVP. The Random Octet String is the random 1265 vector value to use in computing the MD5 hash to retrieve the 1266 original value of a hidden AVP. This string can be of arbitrary 1267 length, although a random vector of at least 16 octets is 1268 recommended. 1270 6.0 Control Connection Protocol Specification 1272 Control Connection messages are used to establish and clear user 1273 sessions. The first set of Control Connection messages are used to 1274 maintain the control connection itself. The control connection is 1275 initiated by an LAC or LNS after establishing the underlying tunnel- 1276 over-media connection. 1278 6.0.1 Control Connection Collision 1280 For the case where an LAC and LNS both initiate tunnels to each 1281 other concurrently, and where the LAC and LNS both determine that 1282 a single tunnel suffices (generally because of media 1283 characteristic considerations, for instance, whether individual 1284 tunnels are needed to gain QOS guarantees for each tunnel), a "tie 1285 breaker" may be undertaken. The details of breaking a tie are 1286 documented with the tunnel establishment messages (Sec. 6.1). 1288 6.0.2 Reliable Delivery of Control Messages 1289 Since L2TP may run across media where packets may be lost, an L2TP 1290 peer sending a control message will retransmit the control message 1291 after deciding that its remote peer has not received it. The 1292 reliable transport mechanism built into L2TP is essentially a 1293 lower layer transport service; the Nr and Ns fields of the control 1294 message header belong to this transport layer. The higher layer 1295 functions of L2TP are not concerned with retransmission or 1296 ordering of control messages. 1298 Each tunnel maintains a queue of control messages to be 1299 transmitted to the peer. The message at the front of the queue is 1300 sent with a given Ns value, and is held until a control message 1301 arrives from the peer in which the Nr field indicates receipt of 1302 this message. After a fixed (recommended default is 1 second) or 1303 adaptive (see Appendix D) timeout interval expires without 1304 receiving such an acknowledgment, the control message packet is 1305 retransmitted. The retransmitted packet contains the same Ns 1306 value, but the Nr value MUST be updated to reflect any packets 1307 received in the interim. 1309 If no peer response is detected after several retransmissions (a 1310 recommended default is 5, but may be altered due to media 1311 considerations), the tunnel and all sessions within MUST be 1312 cleared. 1314 When a tunnel is being shut down for reasons other than loss of 1315 connectivity, the state and reliable delivery mechanisms MUST be 1316 maintained and operated for the full retransmission interval after 1317 the final message exchange has occurred. This permits reliable 1318 delivery of closing messages in environments where these closing 1319 messages might be dropped. 1321 Unlike payload traffic, a peer MUST NOT withhold acknowledgment of 1322 packets as a technique for flow controlling control messages. An 1323 L2TP implementation is expected to be able to keep up with 1324 incoming control messages, possibly responding to some with errors 1325 reflecting an inability to honor the requested action. 1327 A sliding window mechanism is used, by default, for control 1328 message transmission. The default is to permit four control 1329 messages to be outstanding on a given tunnel. If a peer specifies 1330 a Receive Window Size AVP in the Start-Control-Connection-Request 1331 and -Reply packets, up to the indicated number of control messages 1332 may be sent and held outstanding. An implementation may only 1333 support a receive window of 1, but MUST accept at least a window 1334 of 4 from its peer. Unlike payload sessions, a value of 0 for the 1335 Receive Window Size AVP is invalid for a control session. 1337 The transport layer at a receiving peer is responsible for making 1338 sure that control messages are delivered in order to the higher 1339 layer and that duplicate messages are not delivered to the higher 1340 layer. Messages arriving out of order may be queued for in-order 1341 delivery when the missing messages are received or they may be 1342 discarded, requiring a retransmission. 1344 6.0.3 Control Message Format 1346 The following Control Connection messages are all sent as packets 1347 on the established tunnel connection between a given LNS-LAC pair. 1348 All data is sent in network order (high order octets first). Any 1349 "reserved" or "empty" fields MUST be sent as 0 values to allow for 1350 protocol extensibility. 1352 Each control message has a header, specified in section 5.2, 1353 including an AVP indicating the type of control message, followed 1354 by zero or more AVP's appropriate for the given type of control 1355 message. Each control message is described first at a block 1356 level, and then with details of each AVP. 1358 6.1 Start-Control-Connection-Request (SCCRQ) 1360 The Start-Control-Connection-Request is an L2TP control message used 1361 to initialize the tunnel between an LNS and an LAC. The tunnel must 1362 be initialized through the exchange of these control messages before 1363 any other L2TP messages can be issued. The establishment of the 1364 control connection is started by the initiator of the underlying 1365 tunnel. 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | L2TP Control Message Header | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Start-Control-Connection-Request | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Protocol Version | 1373 | Framing Capabilities | 1374 | Bearer Capabilities | 1375 | Tie Breaker | 1376 | Firmware Revision | 1377 | Host Name | 1378 | Vendor Name | 1379 | Assigned Tunnel ID | 1380 | Receive Window Size | 1381 | Challenge | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+ 1384 Start-Control-Connection-Request 1386 0 1 2 3 1387 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 |1|0|0|0| 8 | 0 | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | 0 | 1 | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 The Message Type AVP contains a Value of 1, indicating Start- 1395 Control-Connection-Request. The Flags indicate a mandatory 1396 option. Details associated with this tunneled session follow in 1397 additional AVP's within the packet. 1399 Protocol Version 1401 0 1 2 3 1402 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 |1|0|0|0| 8 | 0 | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | 2 | 0x01 | 0x00 | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 The Protocol Version AVP within a Start-Control-Connection-Request 1410 packet indicates the L2TP protocol version available. The 1411 Attribute value is 2, indicating Protocol Version, and is marked 1412 mandatory. This AVP MUST be present. The Value field is a 16-bit 1413 hexadecimal value 0x100, indicating L2TP protocol version 1, 1414 revision 0. 1416 Framing Capabilities 1418 0 1 2 3 1419 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 |1|0|0|0| 10 | 0 | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | 3 | 0x00 | 0x00 | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | 0x00 |0|0|0|0|0|0|A|S| 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 The Framing Capabilities AVP within a Start-Control-Connection- 1429 Request indicates the type of framing that the sender of this 1430 message can provide. The Attribute value is 3, indicating Framing 1431 Capabilities, and is marked mandatory. This AVP MUST be present. 1432 The Value field is a 32-bit quantity, with two bits defined. If 1433 bit A is set, asynchronous framing is supported. If bit S is set, 1434 synchronous framing is supported. 1436 Bearer Capabilities 1438 0 1 2 3 1439 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 |1|0|0|0| 10 | 0 | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | 4 | 0x00 | 0x00 | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | 0x00 |0|0|0|0|0|0|A|D| 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 The Bearer Capabilities AVP within a Start-Control-Connection- 1449 Request indicates the bearer capabilities that the sender of this 1450 message can provide. The Attribute value is 4, indicating Bearer 1451 Capabilities, and is marked mandatory. This AVP MUST be present. 1452 The Value field is a 32-bit quantity with two bits defined. If 1453 bit A is set, analog access is supported. If bit D is set, 1454 digital access is supported. 1456 Tie Breaker 1458 0 1 2 3 1459 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 |0|0|0|0| 14 | 0 | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | 5 | Tie Break Value... | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Value... | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | ...(64 bits) | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 The Tie Breaker AVP within a Start-Control-Connection-Request 1471 contains a 64-bit Value used to break ties in tunnel establishment 1472 between an LAC-LNS pair. The Attribute value is 5, indicating Tie 1473 Breaker, and is marked optional. This AVP itself is optional. 1474 The 8 byte Value is used as a 64-bit tie breaker value. 1476 If present, it indicates the sender wishes a single tunnel to 1477 exist between the given LAC-LNS pair, and this value will be used 1478 to choose a single tunnel where both LAC and LNS initiate a tunnel 1479 concurrently. The recipient of a Start-Control-Connection-Request 1480 must check to see if a Start-Control-Connection-Request has been 1481 sent to the peer, and if so, must compare its Tie Breaker value 1482 with the received one. The lower value "wins", and the "loser" 1483 MUST sliently discard its tunnel. In the case where a tie breaker 1484 is present on both sides, and the value is equal, both sides MUST 1485 discard their tunnels. 1487 If a tie breaker is received, and the outstanding Start-Control- 1488 Connection-Request had no tie breaker value, the initiator which 1489 included the Tie Breaker AVP "wins". 1491 It is recommended that the Value be set to the MAC address of a 1492 LAN interface on the sender. If no MAC address is available, a 1493 64-bit random number should be used instead. 1495 Firmware Revision 1497 0 1 2 3 1498 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 |0|0|0|0| 8 | 0 | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | 6 | Firmware Revision | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 The Firmware Revision AVP within a Start-Control-Connection- 1506 Request indicates the firmware revision of the issuing device. 1508 The Attribute value is 6, indicating Firmware Revision, and is 1509 marked optional. This AVP itself is optional. The Value field is 1510 a 16-bit integer encoded in a vendor specific format. For devices 1511 which do not have a firmware revision (general purpose computers 1512 running L2TP software modules, for instance), the revision of the 1513 L2TP software module may be reported instead. 1515 Host Name 1517 0 1 2 3 1518 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 |1|0|0|0| 6 + Host name length | 0 | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | 7 | Host name... 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 The Host Name AVP within a Start-Control-Connection-Request 1526 indicates the name of the issuing LAC or LNS. The Attribute value 1527 is 7, indicating Host Name, and is marked mandatory. This AVP 1528 itself MUST be present. This name should be as broadly unique as 1529 possible; for hosts participating in DNS [4], a hostname with 1530 fully qualified domain would be appropriate. 1532 Vendor Name 1534 0 1 2 3 1535 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 |0|0|0|0|6 + vendor name length | 0 | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | 8 | Vendor name... 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 The Vendor Name AVP within a Start-Control-Connection-Request 1543 contains a vendor specific string describing the type of LAC or 1544 LNS being used. The Attribute value is 8, indicating Vendor Name, 1545 and is marked optional. This AVP itself is optional. The Value 1546 is the indicated number of bytes representing the vendor string. 1548 Assigned Tunnel ID 1550 0 1 2 3 1551 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 |1|0|0|0| 8 | 0 | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | 9 | Tunnel ID | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 The Assigned Tunnel ID AVP within a Start-Control-Connection- 1559 Request specifies the Tunnel ID which the receiving peer MUST use 1560 in the Tunnel ID field of all subsequent packets. The Attribute 1561 value is 9, indicating Assigned Tunnel ID, and is marked 1562 mandatory. This AVP MUST be present. Before the Assigned Tunnel 1563 ID AVP is received, packets MUST be sent with a Tunnel ID value of 1564 0. The Value is a 16-bit non-zero Tunnel ID value. 1566 Receive Window Size 1568 0 1 2 3 1569 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 |1|0|0|0| 8 | 0 | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 | 10 | Size | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 The Receive Window Size AVP within a Start-Control-Connection- 1577 Request specifies the receive window size being offered to the 1578 remote peer. The Attribute value is 10, indicating Receive Window 1579 Size, and is mandatory. This AVP itself is optional. Value is a 1580 16-bit word indicating the offered window size. If absent, the 1581 peer must assume a value of 4 for its transmit window. The remote 1582 peer may send the specified number of control messages before it 1583 must wait for an acknowledgment. 1585 Challenge 1587 0 1 2 3 1588 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 |1|0|0|0| 6 + Challenge length | 0 | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | 11 | Challenge... 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 The Challenge AVP within a Start-Control-Connection-Request 1596 indicates that the issuing peer wishes to authenticate the tunnel 1597 endpoints using a CHAP-style authentication mechanism. The 1598 Attribute value is 11, indicating Challenge, and is marked 1599 mandatory. This AVP is optional. The Value is one or more octets 1600 of challenge value. 1602 6.2 Start-Control-Connection-Reply (SCCRP) 1604 The Start-Control-Connection-Reply is an L2TP control message sent in 1605 reply to a received Start-Control-Connection-Request message. Sending 1606 this message indicates that the request was successful. 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | L2TP Control Message Header | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Start-Control-Connection-Reply | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Protocol Version | 1614 | Framing Capabilities | 1615 | Bearer Capabilities | 1616 | Firmware Revision | 1617 | Host Name | 1618 | Vendor Name | 1619 | Assigned Tunnel ID | 1620 | Receive Window Size | 1621 | Challenge | 1622 | Challenge Response | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+ 1625 Start-Control-Connection-Reply 1627 0 1 2 3 1628 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 |1|0|0|0| 8 | 0 | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | 0 | 2 | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 The Message Type AVP contains a Value of 2, indicating Start- 1636 Control-Connection-Reply. The Flags indicate a mandatory option. 1638 Protocol Version 1640 0 1 2 3 1641 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 |1|0|0|0| 8 | 0 | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | 2 | 0x01 | 0x00 | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 The Protocol Version AVP within a Start-Control-Connection-Reply 1649 packet indicates the L2TP protocol version available. The 1650 Attribute value is 2, indicating Protocol Version, and the Value 1651 field is a 16-bit hexadecimal value 0x100, indicating L2TP 1652 protocol version 1, revision 0. This AVP MUST be present. 1654 Framing Capabilities 1656 0 1 2 3 1657 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 |1|0|0|0| 10 | 0 | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | 3 | 0x00 | 0x00 | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | 0x00 |0|0|0|0|0|0|A|S| 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 The Framing Capabilities AVP within a Start-Control-Connection- 1667 Reply indicates the type of framing that the sender of this 1668 message can provide. The Attribute is 3, it is a mandatory AVP, 1669 the Value field is a 32-bit quantity, with two bits defined. If 1670 bit A is set, asynchronous framing is supported. If bit S is set, 1671 synchronous framing is supported. This AVP MUST be present. 1673 Bearer Capabilities 1675 0 1 2 3 1676 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 |1|0|0|0| 10 | 0 | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | 4 | 0x00 | 0x00 | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | 0x00 |0|0|0|0|0|0|A|D| 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 The Bearer Capabilities AVP within a Start-Control-Connection- 1686 Reply indicates the bearer capabilities that the sender of this 1687 message can provide. The Attribute is 4, it is a mandatory AVP, 1688 the Value field is a 32-bit quantity with two bits defined. If 1689 bit A is set, analog access is supported. If bit D is set, 1690 digital access is supported. This AVP MUST be present. 1692 Firmware Revision 1694 0 1 2 3 1695 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 |0|0|0|0| 8 | 0 | 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 | 6 | Firmware Revision | 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 The Firmware Revision AVP within a Start-Control-Connection-Reply 1703 indicates the firmware revision of the issuing device. The 1704 Attribute is 6, it is not a mandatory AVP, the Value field is a 1705 16-bit integer encoded in a vendor specific format. For devices 1706 which do not have a firmware revision (general purposes computers 1707 running L2TP software modules, for instance), the revision of the 1708 L2TP software module may be reported instead. This AVP is 1709 optional. 1711 Host Name 1713 0 1 2 3 1714 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 |1|0|0|0| 6 + Host name length | 0 | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | 7 | Host name... 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 The Host Name AVP within a Start-Control-Connection-Reply 1722 indicates the name of the issuing LAC or LNS. See the notes in 1723 section 6.1 concerning Host Name contents. It is encoded as the 1724 Attribute 7, mandatory, with the indicated number of bytes 1725 representing the host name string. This AVP MUST be present. 1727 Vendor Name 1729 0 1 2 3 1730 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 |0|0|0|0|6 + Vendor name length | 0 | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | 8 |Vendor name... 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 The Vendor Name AVP within a Start-Control-Connection-Reply 1738 contains a vendor specific string describing the type of LAC or 1739 LNS being used. It is encoded as the Attribute 8, not mandatory, 1740 with the indicated number of bytes representing the vendor string. 1741 This AVP is optional. 1743 Assigned Tunnel ID 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 |1|0|0|0| 8 | 0 | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | 9 | Tunnel ID | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply 1754 specifies the Tunnel ID which the receiving peer MUST use in all 1755 subsequent packets. It is encoded as the Attribute 9, mandatory, 1756 with a 16-bit non-zero Tunnel ID value. This AVP MUST be present. 1758 Receive Window Size 1760 0 1 2 3 1761 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 |1|0|0|0| 8 | 0 | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | 10 | size | 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 The Receive Window Size AVP within a Start-Control-Connection- 1769 Reply specifies the receive window size being offered to the 1770 remote peer. The Attribute value is 10, indicating Receive Window 1771 Size, and is mandatory. This AVP itself is optional. Value is a 1772 16-bit word indicating the offered window size. If absent, the 1773 peer must assume a value of 4 for its transmit window. The remote 1774 peer may send the specified number of control messages before it 1775 must wait for an acknowledgment. 1777 Challenge 1778 0 1 2 3 1779 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 |1|0|0|0| 6 + Challenge length | 0 | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | 11 | Challenge... 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 The Challenge AVP within a Start-Control-Connection-Reply 1787 indicates that the peer wishes to authenticate the tunnel 1788 initiator using a CHAP-style authentication mechanism. It is 1789 encoded as the Attribute 11, mandatory, with at least one byte of 1790 challenge value embedded. If this AVP is not present, it 1791 indicates to the receiving peer that the sender does not wish to 1792 authenticate that peer. 1794 Challenge Response 1796 0 1 2 3 1797 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 |1|0|0|0| 22 | 0 | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | 13 | Response... | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | Response... (128 bits) | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 The Response AVP within a Start-Control-Connection-Reply packet 1807 provides a response to a challenge received. The Attribute value 1808 is 13, indicating Response, and the Value field is a 128-bit value 1809 reflecting the CHAP-style response to the challenge. This AVP 1810 marked mandatory, and MUST be present if a challenge was received 1811 and this Start-Control-Connection-Reply indicates success. For 1812 purposes of the ID value in the CHAP response calculation, the 1813 value 2 (corresponding to the Value field of the Start-Control- 1814 Connection-Reply AVP) MUST be used. 1816 6.3 Start-Control-Connection-Connected (SCCCN) 1818 The Start-Control-Connection-Connected message is an L2TP control 1819 message sent in reply to a received Start-Control-Connection-Reply 1820 message. This message provides closure to the tunnel establishment 1821 process, and includes a challenge response if the peer sent a 1822 challenge in the Start-Control-Connection-Reply message. 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | L2TP Control Message Header | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | Start-Control-Connection-Connected | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | Challenge Response | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+ 1831 Start-Control-Connection-Connected 1833 0 1 2 3 1834 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 |1|0|0|0| 8 | 0 | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | 0 | 3 | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 The Message Type AVP contains a Value of 3, indicating Start- 1842 Control-Connection-Connected. The Flags indicate a mandatory 1843 option. 1845 Challenge Response 1847 0 1 2 3 1848 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 |1|0|0|0| 22 | 0 | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | 13 | Response... | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | Response... (128 bits) | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 The Challenge Response AVP within a Start-Control-Connection- 1858 Connected packet provides a response to a challenge received. The 1859 Attribute value is 13, indicating Response, and the Value field is 1860 a 128-bit value reflecting the CHAP-style response to the 1861 challenge. This AVP is marked mandatory, and MUST be present if a 1862 challenge was received, otherwise MUST be omitted. For purposes 1863 of the ID value in the CHAP response calculation, the value 3 1864 (corresponding to the Value field of the Start-Control- 1865 Connection-Connected AVP) MUST be used. 1867 6.4 Stop-Control-Connection-Notification (StopCCN) 1869 The Stop-Control-Connection-Notification is an L2TP control message 1870 sent by one peer of an LAC-LNS control connection to inform the other 1871 peer that the control connection should be closed. In addition to 1872 closing the control connection, all active user calls are implicitly 1873 cleared. The reason for issuing this request is indicated in the 1874 Result Code AVP. 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | L2TP Control Message Header | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | Stop-Control-Connection-Notification| 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | Assigned Tunnel ID | 1882 | Result Code | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+ 1884 Stop-Control-Connection-Notification AVP 1886 0 1 2 3 1887 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 |1|0|0|0| 8 | 0 | 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | 0 | 4 | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 The Message Type AVP contains a Value of 4, indicating Stop- 1895 Control-Connection-Notification. The Flags indicate a mandatory 1896 option. 1898 Assigned Tunnel ID 1900 0 1 2 3 1901 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 |1|0|0|0| 8 | 0 | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | 9 | Tunnel ID | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 The Attribute value is 9, indicating Assigned Tunnel ID, and is 1909 marked mandatory. This AVP MUST be present. The Value MUST be 1910 the same Assigned Tunnel ID first sent to the receiving peer. 1911 This AVP permits the peer to identify the appropriate tunnel even 1912 if Stop-Control-Connection-Notification must be sent before an 1913 Assigned Tunnel ID is received. 1915 Result Code 1917 0 1 2 3 1918 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 |1|0|0|0| 10 + Message length | 0 | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | 1 | Result Code | 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 | Error Code | Optional Message ... 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 The Result Code AVP within a Stop-Control-Connection-Notification 1928 packet indicates the reason for terminating the control channel. 1929 It is encoded as Attribute 1, indicating a Result Code AVP. This 1930 AVP is mandatory and MUST be present. The Result Code is a 16-bit 1931 word. The 16-bit word following the Result Code field contains 1932 the Error Code value, which for a Stop-Control-Connection- 1933 Notification is always 0. An optional message can follow the 1934 Error Code field. Its presence and length is indicated by the 1935 value of the AVP length field. Defined Result Code values are: 1937 1 - General request to clear control connection 1938 2 - General error--Error Code indicates the problem 1939 3 - Control channel already exists 1940 4 - Requester is not authorized to establish a control channel 1941 5 - The protocol version of the requester is not supported 1942 Error Code indicates highest version supported 1943 6 - Requester is being shut down 1944 7 - Finite State Machine error 1946 6.5 (reserved) 1948 The function previously described here has been deleted from L2TP. 1950 6.6 Hello 1952 The Hello message is an L2TP control message sent by either peer of a 1953 LAC-LNS control connection. This control message is used as a 1954 "keepalive" for the tunnel. 1956 Keepalives should be implemented by sending a Hello once every 60 1957 seconds if 60 seconds have passed without receiving any message 1958 (payload or control, including zero-length messages) from the peer. 1959 When a Hello is received, it MUST be silently discarded (after 1960 updating any effects of the indicated Nr/Ns values). 1962 Because a Hello is a control message, and control messages are 1963 reliably sent by the lower level transport, this keepalive function 1964 operates by causing the transport level to reliably deliver a 1965 message. If a media interruption has occurred, the reliable 1966 transport will be unable to deliver the Hello across, and will clean 1967 up the tunnel. 1969 Hello messages are global to the tunnel; the Call ID field of these 1970 control messages MUST be 0. 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | L2TP Control Message Header | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | Hello | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 Hello 1980 0 1 2 3 1981 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 |1|0|0|0| 8 | 0 | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | 0 | 6 | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 The Message Type AVP contains a Value of 6, indicating Hello The 1989 Flags indicate a mandatory option. 1991 6.7 Outgoing-Call-Request (OCRQ) 1992 The Outgoing-Call-Request is an L2TP control message sent by the LNS 1993 to the LAC to indicate that an outbound call from the LNS is to be 1994 established. This request provides the LAC with information required 1995 to make the call. It also provides information to the LAC that is 1996 used to regulate the transmission of data to the LNS for this session 1997 once it is established. 1999 This message is the first in the "three-way handshake" used by L2TP 2000 for establishing outgoing calls. The first message requests the 2001 call; the second indicates that the call was successfully initiated. 2002 The third and final message indicates that the call was established. 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | L2TP Control Message Header | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | Outgoing-Call-Request | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | Assigned Call ID | 2010 | Call Serial Number | 2011 | Minimum BPS | 2012 | Maximum BPS | 2013 | Bearer Type | 2014 | Framing Type | 2015 | Receive Window Size | 2016 | Packet Processing Delay | 2017 | Dialed Number | 2018 | Sub-Address | 2019 | Private Group ID | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 Outgoing-Call-Request 2024 0 1 2 3 2025 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 |1|0|0|0| 8 | 0 | 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 | 0 | 7 | 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 The Message Type AVP contains a Value of 7, indicating Outgoing- 2033 Call-Request. The Outgoing-Call-Request encodes a request to an 2034 LAC to establish an outgoing call. The flags indicate a mandatory 2035 option. 2037 Assigned Call ID 2039 0 1 2 3 2040 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 |1|0|0|0| 8 | 0 | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 | 14 | Call ID | 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 The Assigned Call ID AVP encodes the ID being assigned to this 2047 call by the LNS. The Attribute value is 14, indicating Assigned 2048 Call ID, and is marked mandatory. This AVP MUST be present. The 2049 LAC places this value in the Call ID header field of all command 2050 and payload packets that it subsequently transmits over the tunnel 2051 that belong to this call. The Call ID value is an identifier 2052 assigned by the LNS to this session. It is used to multiplex and 2053 demultiplex data sent over that tunnel between the LNS and LAC. 2055 Call Serial Number 2057 0 1 2 3 2058 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 |1|0|0|0| 6 + Number length | 0 | 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | 15 | Number... 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 Call Serial Number AVP encodes an identifier assigned by the LNS to 2066 this call. 2067 Attribute is 15, indicating Call Serial Number, and is marked mandatory. 2068 This AVP MUST be present. 2069 The Call Serial Number is intended 2070 to be an easy reference for administrators on both ends of a tunnel to use 2071 when investigating call failure problems. Call Serial Numbers should 2072 be set to progressively increasing values, which are likely to be unique for 2073 a significant period of time across all interconnected LNS and LACs. Other 2074 identification information may also be prepended. 2076 Minimum BPS 2078 0 1 2 3 2079 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 |1|0|0|0| 10 | 0 | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 | 16 | BPS (H) | 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 | BPS (L) | 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 Minimum BPS AVP encodes the lowest acceptable line speed for this 2089 call. Attribute is 16, Minimum BPS, and is marked mandatory. 2090 This AVP MUST be present. The BPS value indicates the speed in 2091 bits/second. 2093 Maximum BPS 2095 0 1 2 3 2096 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 |1|0|0|0| 10 | 0 | 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 | 17 | BPS (H) | 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | BPS (L) | 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 Maximum BPS AVP encodes the highest acceptable line speed for this 2106 call. Attribute is 17, indicating Maximum BPS, and is marked 2107 mandatory. This AVP MUST be present. The BPS value indicates the 2108 speed in bits/second. 2110 Bearer Type 2112 0 1 2 3 2113 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 |1|0|0|0| 10 | 0 | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 Bearer Type AVP encodes the bearer type for the requested call. 2123 The value bit field Attribute is 18, indicating Bearer Type, and 2124 is marked mandatory. This AVP MUST be present. The Value is a 2125 32-bit quantity indicating the bearer capability required for this 2126 outgoing call. If set, bit A indicates that the call should be on 2127 an analog channel. If set, bit D indicates that the call should 2128 be on a digital channel. Both may be set, indicating that the 2129 call can be of either type. 2131 Framing Type 2133 0 1 2 3 2134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 |1|0|0|0| 10 | 0 | 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 Framing Type AVP encodes the framing type for the requested call. 2144 Attribute is 19, indicating Framing Type, and is marked mandatory. 2145 This AVP MUST be present. The 32-bit field indicates the type of 2146 PPP framing to be used for the outgoing call. Bit A if set 2147 indicates that asynchronous framing should be used. Bit S is set 2148 indicates that synchronous framing should be used. 2150 Receive Window Size 2152 0 1 2 3 2153 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 |1|0|0|0| 8 | 0 | 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | 10 | Size | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 Receive Window Size AVP encodes the window size being advertised 2162 by the LNS for this call. Attribute is 10, indicating Receive 2163 Window Size, and is marked mandatory. This AVP is optional. The 2164 Size value indicates the number of received data packets the LNS 2165 will buffer for this call, which is also the maximum number of 2166 data packets the LAC should send before waiting for an 2167 acknowledgment. The absence of this AVP indicates that Sequence 2168 and Acknowledgment Numbers are not to be used in the payload 2169 session for this call. 2171 Packet Processing Delay 2173 0 1 2 3 2174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 |1|0|0|0| 8 | 0 | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | 20 | Delay | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 The Packet Processing Delay AVP encodes the delay LNS has for 2182 processing a window full of packets sent by the LAC. Attribute is 2183 20, indicating Packet Processing Delay, and is marked mandatory. 2184 This AVP is optional. The Delay value is specified in units of 2185 1/10 seconds. Refer to Appendix A for a description of how this 2186 value is determined and used. 2188 Dialed Number 2190 0 1 2 3 2191 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 |1|0|0|0|6 + Phone Number length| 0 | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | 21 | Phone Number.. 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 Phone Number AVP encodes the phone number to be called. Attribute 2199 is 21, indicating Phone Number, and is marked mandatory. This AVP 2200 MUST be present. The Phone Number value is an ASCII string. 2202 Sub-Address 2204 0 1 2 3 2205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 |1|0|0|0|6 + Sub-Address length | 0 | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 | 23 |Sub-Address ... 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2212 Sub-Address AVP encodes additional dialing information. Attribute 2213 is 23, indicating Sub-Address, and is marked mandatory. This AVP 2214 is optional. The Sub-Address value is an ASCII string. 2216 Private Group ID 2218 0 1 2 3 2219 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 |1|0|0|0| 6 + Private Group ID | 0 | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | 37 | Private Group ID ... 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 The Private Group ID AVP is sent by the LNS to the LAC to indicate 2227 that a particular call is to be treated specially, for example, to 2228 select a particular port group or exchange carrier. The Attribute 2229 is 37, Private Group ID, and is marked optional. The presence of 2230 this AVP is optional. The Private Group ID is a string 2231 corresponding to a table in the LAC that defines the particular 2232 characteristics of the selected group. 2234 6.8 Outgoing-Call-Reply (OCRP) 2236 The Outgoing-Call-Reply is an L2TP control message sent by the LAC to 2237 the LNS in response to a received Outgoing-Call-Request message. The 2238 reply indicates that the LAC is able to attempt the outbound call and 2239 also returns certain parameters regarding the call attempt. 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | L2TP Control Message Header | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | Outgoing-Call-Reply | 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 | Assigned Call ID | 2247 | Connect Speed | 2248 | Physical Channel Id | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 Outgoing-Call-Reply 2253 0 1 2 3 2254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 |1|0|0|0| 8 | 0 | 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | 0 | 8 | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 The Message Type AVP contains a Value of 8, indicating Outgoing- 2262 Call-Reply. The Outgoing-Call-Reply message encodes the immediate 2263 result of attempting an outgoing call request. The flags indicate a 2264 mandatory option. 2266 Assigned Call ID 2268 0 1 2 3 2269 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 |1|0|0|0| 8 | 0 | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | 14 | Call ID | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 The Assigned Call ID AVP encodes the ID being assigned to this call 2277 by the LAC. Attribute is 14, indicating Assigned Call ID, and is 2278 marked mandatory. This AVP MUST be present. Call ID value is an 2279 identifier, unique within the tunnel, assigned by the sender to this 2280 session. The remote peer MUST place this Call ID in the Call ID 2281 portion of all future packets it sends associated with this session. 2282 It is used to multiplex and demultiplex data sent over that tunnel 2283 between the LNS and LAC. 2285 Connect Speed 2287 0 1 2 3 2288 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 |1|0|0|0| 10 | 0 | 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | 24 | BPS (H) | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 | BPS (L) | 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2297 Connect Speed BPS AVP encodes the speed of the facility chosen for 2298 the connection attempt. The Attribute value is 24, indicating 2299 Connect Speed, and is marked mandatory. This AVP MUST be present. 2300 The BPS is a 32-bit value indicating the speed in bits/second. 2302 Physical Channel ID 2304 0 1 2 3 2305 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 |1|0|0|0| 10 | 0 | 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 | 25 | ID (H) | 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 | ID (L) | 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2314 Physical Channel ID AVP encodes the vendor specific physical channel 2315 number used for the call. The Attribute value is 25, indicating 2316 Physical Channel ID, and is marked optional. This AVP itself is 2317 optional. ID is a 32-bit value in network byte order. The value is 2318 used for logging purposes only. 2320 6.9 Outgoing-Call-Connected (OCCN) 2322 Outgoing-Call-Connected is an L2TP control message sent by the LAC to 2323 the LNS to indicate that the result of a requested outgoing call was 2324 successful. The LAC MUST send the corresponding Outgoing-Call-Reply 2325 to the LNS before sending this message. This message provides 2326 information to the LNS about the particular parameters used for the 2327 call. It provides information to allow the LNS to regulate the 2328 transmission of data to the LAC for this session. 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2331 | L2TP Control Message Header | 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | Outgoing-Call-Connected | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 | Connect Speed | 2336 | Framing Type | 2337 | Receive Window Size | 2338 | Packet Processing Delay | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 Outgoing-Call-Connected 2343 0 1 2 3 2344 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 |1|0|0|0| 8 | 0 | 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | 0 | 9 | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 The Message Type AVP contains a Value of 9, indicating Outgoing- 2352 Call-Connected. The Outgoing-Call-Connected message encodes the 2353 final result of an outgoing call request. The flags indicate a 2354 mandatory option. 2356 Connect Speed 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| 10 | 0 | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 | 24 | BPS (H) | 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 | BPS (L) | 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 Connect Speed BPS AVP encodes the final negotiated speed for the 2369 connection. The Attribute value is 24, indicating Connect Speed, and 2370 is marked mandatory. This AVP MUST be present. The BPS value 2371 indicates the speed in bits/second. 2373 Framing Type 2375 0 1 2 3 2376 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2378 |1|0|0|0| 10 | 0 | 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 Framing Type AVP encodes the framing type for the call. The 2386 Attribute value is 19, indicating Framing Type, and is marked 2387 mandatory. This AVP MUST be present. The value bit field indicates 2388 the type of PPP framing is used for the call. If set, bit A 2389 indicates that asynchronous framing is being used. If set, bit S 2390 indicates that synchronous framing is being used. 2392 Receive Window Size 2394 0 1 2 3 2395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 |1|0|0|0| 8 | 0 | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | 10 | Size | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 Receive Window Size AVP encodes the window size being offered by the 2403 LNS for this call. The Attribute value is 10, indicating Receive 2404 Window Size, and is marked mandatory. The Size is a 16-bit value 2405 indicating the number of received data packets the LAC will buffer 2406 for this call, which is also the maximum number of data packets the 2407 LNS should send before waiting for an acknowledgment. This AVP MUST 2408 be present if and only if Sequence and Acknowledgment Numbers are to 2409 be used in the payload session for this call. 2411 Packet Processing Delay 2413 0 1 2 3 2414 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 |1|0|0|0| 8 | 0 | 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 | 20 | Delay | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 Packet Processing Delay AVP encodes the delay the LAC expects for 2422 processing a window full of packets sent by the LNS. The Attribute 2423 value is 20, indicating Packet Processing Delay, and is marked 2424 mandatory. This AVP is optional. The Delay value is specified in 2425 units of 1/10 seconds. Refer to Appendix A to see a description of 2426 how this value is determined and used. 2428 6.10 Incoming-Call-Request (ICRQ) 2430 Incoming-Call-Request is an L2TP control message sent by the LAC to 2431 the LNS to indicate that an inbound call is to be established from 2432 the LAC. This request provides the LNS with parameter information 2433 for the incoming call. 2435 This message is the first in the "three-way handshake" used by L2TP 2436 for establishing incoming calls. The LAC may defer answering the 2437 call until it has received an Incoming-Call-Reply from the LNS 2438 indicating that the call should be established. This mechanism 2439 allows the LNS to obtain sufficient information about the call before 2440 it is answered to determine whether the call should be answered or 2441 not. Alternatively, the LAC may answer the call, negotiate LCP and 2442 PPP authentication, and use the information gained to choose the LNS. 2443 In this case, the call has already been answered by the time the 2444 Incoming-Call-Reply message is received; the LAC simply spoofs the 2445 "call indication/answer call" phase in this case. 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | L2TP Control Message Header | 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 | Incoming-Call-Request | 2451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 | Assigned Call ID | 2453 | Call Serial Number | 2454 | Bearer Type | 2455 | Physical Channel ID | 2456 | Dialed Number | 2457 | Dialing Number | 2458 | Sub-Address | 2459 | Private Group ID | 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 Incoming-Call-Request 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| 8 | 0 | 2468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 | 0 | 10 | 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 The Message Type AVP contains a Value of 10, indicating Incoming- 2473 Call-Request. The Incoming-Call-Request message encodes an incoming 2474 call being indicated by the LAC. The flags indicate a mandatory 2475 option. 2477 Assigned Call ID 2478 0 1 2 3 2479 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 |1|0|0|0| 8 | 0 | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 | 14 | Call ID | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 The Assigned Call ID AVP encodes the Call ID being assigned to call 2487 by the LAC. The Attribute value is 14, indicating Call ID, and is 2488 marked mandatory. This AVP MUST be present. The LNS places this 2489 value in the Call ID header field of all command and payload packets 2490 that it subsequently transmits over the tunnel that belong to this 2491 call. The Call ID value is an identifier assigned by the LAC to this 2492 session. It is used to multiplex and demultiplex data sent over that 2493 tunnel between the LNS and LAC. 2495 Call Serial Number 2497 0 1 2 3 2498 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2500 |1|0|0|0| 6 + Number length | 0 | 2501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2502 | 15 | Number... 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 Call Serial Number AVP encodes an identifier assigned by the LAC to 2506 this call. The Attribute value is 15, Call Serial Number, and is 2507 marked mandatory. This AVP MUST be present. Please refer to the 2508 description of this field from section 6.8. 2510 Bearer Type 2512 0 1 2 3 2513 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 |1|0|0|0| 10 | 0 | 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 Bearer Type AVP encodes the bearer type for the incoming call. The 2523 Attribute value is 18, Bearer Type, and is marked mandatory. This 2524 AVP MUST be present. The Value is a 32-bit field indicating the 2525 bearer capability being used by the incoming call. If set, bit A 2526 indicates that the call is on an analog channel. If set, bit D 2527 indicates that the call is on a digital channel. 2529 Physical Channel ID 2531 0 1 2 3 2532 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 |1|0|0|0| 10 | 0 | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 | 25 | ID (H) | 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 | ID (L) | 2539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 Physical Channel ID AVP encodes the vendor specific physical channel 2542 number used for the call. The Attribute value is 25, Physical 2543 Channel ID, and is marked mandatory. The presence of this AVP is 2544 optional. ID is a 32-bit value in network byte order. The value is 2545 used for logging purposes only. 2547 Dialed Number 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|6 + Phone Number length| 0 | 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | 21 | Phone Number.. 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 Dialed Number AVP encodes the dialed number for the incoming call, 2558 that is, DNIS. The Attribute value is 21, Dialed Number, and is 2559 marked mandatory. The presence of this AVP is optional. The value 2560 is an ASCII string. 2562 Dialing Number 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|6 + Phone Number length| 0 | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | 22 |Phone Number... 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 Dialing Number AVP encodes the originating number for the incoming 2573 call, that is, CLID. The Attribute value is 22, Dialing Number, and 2574 is marked mandatory. The presence of this AVP is optional. The 2575 value is an ASCII string. 2577 Sub-Address 2579 0 1 2 3 2580 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 |1|0|0|0|6 + Sub-Address length | 0 | 2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 | 23 |Sub-Address ... 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 Sub-Address AVP encodes additional dialing information. The 2587 Attribute value is 23, Sub-Address, and is marked mandatory. The 2588 presence of this AVP is optional. The Sub-Address value is an ASCII 2589 string. 2591 Private Group ID 2593 0 1 2 3 2594 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 |1|0|0|0| 6 + Private Group ID | 0 | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 | 37 | Private Group ID ... 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 The PrivateGroup ID AVP is used by the LAC to indicate that this call 2602 is to be associated with a particular customer group. The Attribute 2603 is 37, Private Group ID, and is marked optional. The presence of 2604 this AVP is optional. The LNS MAY treat the PPP session as well as 2605 network traffic through this session specially in a manner determined 2606 by the peer. For example, if the LNS is individually connected to 2607 several private networks using unregistered addresses, this AVP may 2608 be included by the LAC to indicate that a given call should be 2609 associated with one of the private networks. 2611 The Private Group ID is a string corresponding to a table in the LNS 2612 that defines the particular characteristics of the selected group. A 2613 LAC MAY determine the Private Group ID from a RADIUS response 2614 containing the PrivateGroupID attribute. 2616 The Private Group ID AVP MAY be included in either incoming call 2617 request or incoming call connected messages. This AVP SHOULD NOT be 2618 included in both messages. 2620 6.11 Incoming-Call-Reply (ICRP) 2622 The Incoming-Call-Reply is an L2TP control message sent by the LNS to 2623 the LAC in response to a received Incoming-Call-Request message. The 2624 reply indicates that the request was successful. It also provides 2625 information to allow the LAC to regulate the transmission of data to 2626 the LNS for this session. 2628 This message is the second in the three-way handshake used by L2TP 2629 for establishing incoming calls. It indicates to the LAC that the 2630 call should be answered. 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | L2TP Control Message Header | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | Incoming-Call-Reply | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | Assigned Call ID | 2638 | Receive Window Size | 2639 | Packet Processing Delay | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 Incoming-Call-Reply 2644 0 1 2 3 2645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 |1|0|0|0| 8 | 0 | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2649 | 0 | 11 | 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2652 The Message Type AVP contains a Value of 11, indicating Incoming- 2653 Call-Reply. The Incoming-Call-Reply message encodes a response by 2654 the LNS to the incoming call indication given by the LAC. The flags 2655 indicate a mandatory option. 2657 Assigned Call ID 2659 0 1 2 3 2660 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2662 |1|0|0|0| 8 | 0 | 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 | 14 | Call ID | 2665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 The Assigned Call ID AVP encodes the ID being assigned to call by the 2668 LNS. The Attribute value is 14, Assigned Call ID, and is marked 2669 mandatory. This AVP MUST be present. The LAC places this value in 2670 the Call ID header field of all command and payload packets that it 2671 subsequently transmits over the tunnel that belong to this call. The 2672 Call ID value is an identifier assigned by the LNS to this session. 2673 It is used to multiplex and demultiplex data sent over that tunnel 2674 between the LNS and LAC. 2676 Receive Window Size 2678 0 1 2 3 2679 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 |1|0|0|0| 8 | 0 | 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 | 10 | Size | 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 | Optional Message... | 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 Receive Window Size AVP encodes the receive window size being offered 2689 by the LNS for this call. The Attribute value is 10, Receive Window 2690 Size, and is marked mandatory. The Size value indicates the number 2691 of received data packets the LNS will buffer for this call, which is 2692 also the maximum number of data packets the LAC should send before 2693 waiting for an acknowledgment. This AVP is optional if Sequence and 2694 Acknowledgment Numbers are not to be used in the payload session for 2695 this call. 2697 Packet Processing Delay 2699 0 1 2 3 2700 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 |1|0|0|0| 8 | 0 | 2703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 | 20 | Delay | 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 Packet Processing Delay AVP encodes the delay the LNS expects for 2708 processing a window full of packets sent by the LAC. The Attribute 2709 value is 20, Packet Processing Delay AVP, and is marked mandatory. 2710 The presence of this AVP is optional. The Delay value is specified 2711 in units of 1/10 seconds. Refer to Appendix A to see a description 2712 of how this value is determined and used. 2714 6.12 Incoming-Call-Connected (ICCN) 2716 The Incoming-Call-Connected message is an L2TP control message sent 2717 by the LAC to the LNS in response to a received Incoming-Call-Reply. 2718 It provides information to the LNS about particular parameters used 2719 for the call. It also provides information to allow the LNS to 2720 regulate the transmission of data to the LAC for this session. 2722 This message is the third in the three-way handshake used by L2TP for 2723 establishing incoming calls. It provides a mechanism for providing 2724 the LNS with additional information about the call that cannot, in 2725 general, be obtained at the time the Incoming-Call-Request is issued 2726 by the LAC. 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | L2TP Control Message Header | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | Incoming-Call-Connected | 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 | Connect Speed | 2734 | Framing Type | 2735 | Receive Window Size | 2736 | Packet Processing Delay | 2737 | Initial LCP Confreq | 2738 | Last Sent LCP Confreq | 2739 | Last Received LCP Confreq | 2740 | Proxy authen type | 2741 | Proxy authen name | 2742 | Proxy authen challenge | 2743 | Proxy authen ID | 2744 | Proxy authen response | 2745 | Private Group ID | 2746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 Incoming-Call-Connected 2749 0 1 2 3 2750 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 |1|0|0|0| 8 | 0 | 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2754 | 0 | 12 | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2757 The Message Type AVP contains a Value of 12, indicating Incoming- 2758 Call-Connected. The Incoming-Call-Connected message encodes a 2759 response by the LAC to the Incoming-Call-Reply message sent by the 2760 LAC. The flags indicate a mandatory option. 2762 Connect Speed 2764 0 1 2 3 2765 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2767 |1|0|0|0| 10 | 0 | 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 | 24 | BPS (H) | 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | BPS (L) | 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 Connect Speed BPS AVP encodes the speed for the connection. The 2775 Attribute value is 24, Connect Speed, and is marked mandatory. This 2776 AVP MUST be present. The value is a 32-bit quantity indicating the 2777 speed in bits/second. 2779 Framing Type 2781 0 1 2 3 2782 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 |1|0|0|0| 10 | 0 | 2785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2788 |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| 2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 Framing Type AVP encodes the framing type for the call. The 2792 Attribute value is 19, Framing Type, and is marked mandatory. This 2793 AVP MUST be present. The value is a 32-bit bit field indicating the 2794 type of PPP framing used for the call. If set, bit A indicates that 2795 asynchronous framing is being used. If set, bit S indicates that 2796 synchronous framing is being used. 2798 Receive Window Size 2800 0 1 2 3 2801 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2803 |1|0|0|0| 8 | 0 | 2804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2805 | 10 | Size | 2806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2808 Receive Window Size AVP encodes the window size being offered by the 2809 LAC for this call. The Attribute value is 10, Receive Window Size, 2810 and is marked mandatory. This AVP is optional if Sequence and 2811 Acknowledgment Numbers are not to be used in the payload session for 2812 this call. The 16-bit Size value indicates the number of received 2813 data packets the LAC will buffer for this call, which is also the 2814 maximum number of data packets the LNS should send before waiting for 2815 an acknowledgment. 2817 Packet Processing Delay 2819 0 1 2 3 2820 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 |1|0|0|0| 8 | 0 | 2823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2824 | 20 | Delay | 2825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 Packet Processing Delay AVP encodes the delay the LAC expects for 2828 processing a window full of packets sent by the LNS. The Attribute 2829 value is 20, Packet Processing Delay, and is marked mandatory. The 2830 presence of this AVP is optional. The 16-bit Delay value is 2831 specified in units of 1/10 seconds. Refer to Appendix A to see a 2832 description of how this value is determined and used. 2834 Initial LCP Confreq 2836 0 1 2 3 2837 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2839 |0|0|0|0|6 + LCP confreq length | 0 | 2840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2841 | 26 | LCP confreq... 2842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2844 The LAC may have answered the phone call and negotiated LCP with the 2845 dial-in client in order to establish the client's apparent identity. 2846 In this case, this option may be included to indicate the link 2847 properties the client requested in its initial LCP CONFREQ request. 2848 The Attribute value is 26, Initial LCP Confreq, and is marked 2849 optional. The presence of this AVP is optional. The Value field is 2850 a copy of the body of the initial CONFREQ received, starting at the 2851 first option within this packet's body. 2853 Last Sent LCP Confreq 2854 0 1 2 3 2855 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2857 |0|0|0|0|6 + LCP confreq length | 0 | 2858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2859 | 27 | LCP confreq... 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 See Initial LCP Confreq above for rationale. The Attribute value is 2863 27, Last Sent LCP Confreq, and is marked optional. The presence of 2864 this AVP is optional. The Value field is a copy of the body of the 2865 final CONFREQ sent to the client to complete LCP negotiation, 2866 starting at the first option within this packet's body. 2868 Last Received LCP Confreq 2870 0 1 2 3 2871 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2873 |0|0|0|0|6 + LCP confreq length | 0 | 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2875 | 28 | LCP confreq... 2876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 See Initial LCP Confreq above for rationale. The Attribute value is 2879 28, Last Received LCP Confreq, and is marked optional. The presence 2880 of this AVP is optional. The Value field is a copy of the body of 2881 the final CONFREQ received from the client to complete LCP 2882 negotiation, starting at the first option within this packet's body. 2884 Proxy Authen Type 2886 0 1 2 3 2887 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 |1|0|0|0| 8 | 0 | 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | 29 | Type | 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2894 The Attribute value is 29, Proxy Authen Type, and is marked 2895 mandatory. This AVP MUST be present. The value Type is a 16-bit 2896 word, holding a value: 2898 1 - Textual username/password exchange 2899 2 - PPP CHAP 2900 3 - PPP PAP 2901 4 - None 2903 Associated AVP's for each type of authentication follow. 2905 Proxy Authen Name 2907 0 1 2 3 2908 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2910 |0|0|0|0| 6 + Name length | 0 | 2911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 | 30 | Name... 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2915 The Attribute value is 30, Proxy Authen Name, and is marked 2916 mandatory. This AVP MUST be present for Proxy Authen Type values 1, 2917 2, and 3. The Name field contains the name specified in the client's 2918 authentication response. Note that the AVP H bit may be desirable 2919 for obscuring the cleartext name. 2921 Proxy Authen Challenge 2923 0 1 2 3 2924 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2926 |0|0|0|0| 6 + Challenge length | 0 | 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2928 | 31 | Challenge... 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 The Attribute value is 31, Proxy Authen Challenge, and is marked 2932 mandatory. The AVP itself MUST be present for Proxy authen type 2. 2933 The Challenge field contains the value presented to the client by the 2934 LAC. 2936 Proxy Authen ID 2938 0 1 2 3 2939 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2941 |0|0|0|0| 8 | 0 | 2942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2943 | 32 | ID | 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 The Attribute value is 32, Proxy Authen ID, and is marked mandatory. 2947 The AVP itself MUST be present for Proxy authen types 2 and 3. For 2948 CHAP, the ID field contains the byte ID value presented to the client 2949 by the LAC in its Challenge. For PAP, it is the Identifier value of 2950 the Authenticate-Request. The most significant 8 bits of ID MUST be 2951 0, and are reserved. 2953 Proxy Authen Response 2955 0 1 2 3 2956 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2958 |1|0|0|0| 6 + Response length | 0 | 2959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 | 33 | Response... 2961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2962 The Attribute value is 33, Proxy Authen Response, and is marked 2963 mandatory. The AVP itself MUST be present for Proxy authen types 1, 2964 2, and 3. The Response field contains the client's response to the 2965 challenge. For Proxy authen type 2, this field contains the response 2966 value received by the LAC. For types 1 or 3, it contains the clear 2967 text password received from the client by the LAC. In the case of 2968 cleartext passwords, use of the AVP H bit is recommended. 2970 Private Group ID 2972 0 1 2 3 2973 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2975 |1|0|0|0| 6 + Private Group ID | 0 | 2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2977 | 37 | Private Group ID ... 2978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2980 PrivateGroup ID AVP is used by the LAC to indicate that this call is 2981 to be associated with a particular customer group. The Attribute is 2982 37, Private Group ID, and is marked optional. The presence of this 2983 AVP is optional. The LNS MAY treat the PPP session as well as 2984 network traffic through this session specially in a manner determined 2985 by the peer. For example, if the LNS is individually connected to 2986 several private networks using unregistered addresses, this AVP may 2987 be included by the LAC to indicate that a given call should be 2988 associated with one of the private networks. 2990 The Private Group ID is a string corresponding to a table in the LNS 2991 that defines the particular characteristics of the selected group. A 2992 LAC MAY determine the Private Group ID from a RADIUS response 2993 containing the PrivateGroupID attribute. 2995 The Private Group ID AVP MAY be included in either incoming call 2996 request or incoming call connected messages. This AVP SHOULD NOT be 2997 included in both messages. 2999 6.13 (reserved) 3001 The function previously described here has been deleted from L2TP. 3003 6.14 Call-Disconnect-Notify (CDN) 3005 The Call-Disconnect-Notify message is an L2TP control message sent to 3006 request disconnection of a specific call within the tunnel. Its 3007 purpose is to inform the peer of the disconnection and the reason why 3008 the disconnection occurred. The peer MUST clean up any resources, 3009 and does not send back any indication of success or failure for such 3010 cleanup. 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 | L2TP Control Message Header | 3014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 | Call-Disconnect-Notify | 3016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3017 | Result Code | 3018 | Q.931 Cause Code | 3019 | Assigned Call ID | 3020 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3022 Call-Disconnect-Notify 3024 0 1 2 3 3025 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3027 |1|0|0|0| 8 | 0 | 3028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3029 | 0 | 14 | 3030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3032 The Message Type AVP contains a Value of 14, indicating Call- 3033 Disconnect-Notify. The Call-Disconnect-Notify message encodes a 3034 disconnect indication for a specific call within the tunnel. The 3035 flags indicate a mandatory option. 3037 Result Code 3039 0 1 2 3 3040 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3042 |1|0|0|0| 10 + Message length | 0 | 3043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3044 | 1 | Result Code | 3045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3046 | Error Code | Optional Message ... 3047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3049 The Result Code AVP within a Call-Disconnect-Notify message 3050 indicates the reason for the call disconnect. It is encoded as 3051 Attribute 1, indicating a Result Code AVP. This AVP is mandatory 3052 and MUST be present. The Result Code is a 16-bit word. The 16- 3053 bit word following the Result Code field contains the Error Code 3054 value. The Result Code value indicates whether the Error Code 3055 value is meaningful or not. If Error Code is not meaningful it 3056 MUST be set to 0. An optional error message can follow the Error 3057 Code field; its presence and length is indicated by the value of 3058 the AVP length field. Defined Result Code values are: 3060 1 - Call disconnected due to loss of carrier 3061 2 - Call disconnected for the reason indicated in Error Code. 3062 3 - Call disconnected for administrative reasons 3063 4 - Call failed due to no appropriate facilities being 3064 available (temporary condition) 3065 5 - Call failed due to no appropriate facilities being 3066 available (permanent condition) 3067 6 - Invalid destination 3068 7 - Call failed due to no carrier detected 3069 8 - Call failed due to detection of a busy signal 3070 9 - Call failed due to lack of a dial tone 3071 10 - Call was not established within time allotted by LAC 3072 11 - Call was connected but no appropriate framing was detected 3074 Q.931 Cause Code 3076 0 1 2 3 3077 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3079 |0|0|0|0|9 + Advisory Msg length| 0 | 3080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3081 | 12 | Cause Code | 3082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3083 | Cause Msg |Advisory Msg...| 3084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3086 The Q.931 Cause Code AVP is used to give additional information in 3087 case of unsolicited call disconnection. The Attribute value is 3088 12, Cause Code, and is marked mandatory. The presence of this AVP 3089 is optional. The Cause Code AVP is used to give additional 3090 information about the reason for disconnecting. It is only 3091 relevant when the LAC is using Q.931/DSS1 for the call. This AVP 3092 is optional. Cause Code is the returned Q.931 Cause code and 3093 Cause Msg is the returned Q.931 message code (e.g., DISCONNECT) 3094 associated with the Cause Code. Both values are returned in their 3095 native ITU encodings. An additional Ascii text Advisory Message 3096 may also be included (presence indicated by the AVP length) to 3097 further explain the reason for disconnecting. 3099 Assigned Call ID 3101 0 1 2 3 3102 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 |1|0|0|0| 8 | 0 | 3105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3106 | 14 | Call ID | 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3109 The Assigned Call ID which was provided to the LNS from this LAC 3110 is included in the Call-Disconnect-Notify message. This permits a 3111 connection to be terminated even before the LNS has provided its 3112 own Assigned Call ID to this LAC (the Call ID field in the control 3113 message header is 0). The Attribute value is 14, Assigned Call 3114 ID, and is marked mandatory. This AVP MUST be present. 3116 6.15 WAN-Error-Notify (WEN) 3118 The WAN-Error-Notify message is an L2TP control message sent by the 3119 LAC to the LNS to indicate WAN error conditions (conditions that 3120 occur on the interface supporting PPP). The counters in this message 3121 are cumulative. This message should only be sent when an error 3122 occurs, and not more than once every 60 seconds. The counters are 3123 reset when a new call is established. 3125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3126 | L2TP Control Message Header | 3127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3128 | WAN-Error-Notify | 3129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3130 | Call Errors | 3131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3133 WAN-Error-Notify 3135 0 1 2 3 3136 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3138 |1|0|0|0| 8 | 0 | 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3140 | 0 | 15 | 3141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3143 The Message Type AVP contains a Value of 15, indicating WAN-Error- 3144 Notify. The WAN-Error-Notify message encodes information about line 3145 and other errors detected on the LAC's physical interface to the 3146 client. This message is sent by the LAC to the LNS. The flags 3147 indicate a mandatory option. 3149 Call Errors 3151 0 1 2 3 3152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3154 |1|0|0|0| 32 | 0 | 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 | 34 | Reserved | 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | CRC Errors | 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3160 | Framing Errors | 3161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3162 | Hardware Overruns | 3163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3164 | Buffer Overruns | 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 | Time-out Errors | 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 | Alignment Errors | 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3171 The Call Errors AVP is used by the LAC to send error information to 3172 the LNS. The Attribute value is 34, WAN-Error-Notify, and is marked 3173 mandatory. This AVP MUST be present. The value contains the 3174 following fields: 3176 Reserved - Not used, MUST be 0 3177 CRC Errors - Number of PPP frames received with CRC errors since 3178 session was established 3180 Framing Errors - Number of improperly framed PPP packets received 3181 Hardware Overruns - Number of receive buffer over-runs since 3182 session was established 3183 Buffer Overruns - Number of buffer over-runs detected since 3184 session was established 3185 Time-out Errors - Number of time-outs since call was established 3186 Alignment Errors - Number of alignment errors since call was 3187 established 3189 6.16 Set-Link-Info (SLI) 3191 The Set-Link-Info message is an L2TP control message sent by the LNS 3192 to the LAC to set PPP-negotiated options. Because these options can 3193 change at any time during the life of the call, the LAC MUST be able 3194 to update its internal call information dynamically and update its 3195 behavior on an active PPP session. 3197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3198 | L2TP Control Message Header | 3199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3200 | Set-Link-Info | 3201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3202 | ACCM | 3203 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3205 Set-Link-Info 3207 0 1 2 3 3208 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 |1|0|0|0| 8 | 0 | 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3212 | 0 | 16 | 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3215 The Message Type AVP contains a Value of 16, indicating Set-Link- 3216 Info. The Set-Link-Info message encodes ACCM information sent from 3217 the LNS to the LAC after it is negotiated in LCP. The flags indicate 3218 a mandatory option. 3220 ACCM 3222 0 1 2 3 3223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3225 |1|0|0|0| 32 | 0 | 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 | 35 | Reserved | 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 | Send ACCM | 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3231 | Receive ACCM | 3232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3233 The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. 3234 The Attribute value is 35, ACCM, and is marked mandatory. This 3235 attribute MUST be present. The value contains Send ACCM and Receive 3236 ACCM fields. The send ACCM value should be used by the LAC to 3237 process packets it is sends on the connection. The receive ACCM 3238 value should be used by the LAC to process incoming packets on the 3239 connection. The default values used by the LAC for both these fields 3240 are 0xFFFFFFFF. The LAC should honor these fields unless it has 3241 specific configuration information to indicate that the requested 3242 mask must be modified to permit operation. 3244 7.0 Control Connection State Machines 3246 The control messages defined in section 6 are exchanged by way of state 3247 tables defined in this section. Tables are defined for incoming call 3248 placement, outgoing call placement, as well as for initiation of the 3249 tunnel itself. The state tables do not encode timeout and 3250 retransmission behavior, as this is handled in the underlying semantics 3251 defined in 6.0.2. 3253 7.1 Control Connection Protocol Operation 3255 This section describes the operation of various L2TP control 3256 connection functions and the Control Connection messages which are 3257 used to support them. 3259 Receipt of an invalid or malformed Control Connection message should 3260 be logged appropriately, and the control connection should be closed 3261 and restarted to ensure recovery into a known state. 3263 In several cases in the following tables, a protocol message is sent, 3264 and then a "clean up" occurs. Note that regardless of the initiator 3265 of the tunnel destruction, the reliable delivery mechanism must be 3266 allowed to run (see 6.0.2) before destroying the tunnel. This 3267 permits the tunnel management messages to be reliably delivered to 3268 the peer. 3270 7.2 Control Connection States 3272 Control messages are carried over the same media as the payload 3273 messages which are carried following successful connection 3274 establishment. The L2TP control connection protocol is not 3275 distinguishable between the LNS and LAC, but is distinguishable 3276 between the originator and receiver. The originating peer is the one 3277 which first establishes the tunnel. Since either LAC or LNS can be 3278 the originator, a collision can occur. See Section 6.0.1 for a 3279 description of this and its resolution. 3281 7.2.1 Control Connection Establishment 3283 State Event Action New State 3284 ----- ----- ------ --------- 3285 idle Local Send SCCRQ wait-ctl-reply 3286 Open request 3288 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3289 acceptable 3291 idle Receive SCCRQ, Send StopCCN, idle 3292 not acceptable Clean up 3294 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3295 acceptable Send tunnel-open 3296 event to waiting 3297 sessions 3299 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3300 not acceptable Clean up 3302 wait-ctl-reply Receive SCCRQ, Clean up, idle 3303 lose tie-breaker Re-queue SCCRQ 3304 for idle state 3306 wait-ctl-conn Receive SCCCN, Send tunnel-open established 3307 acceptable event to waiting 3308 sessions 3310 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3311 not acceptable Clean up 3313 established Local Send tunnel-open established 3314 Open request event to waiting 3315 (new client) sessions 3317 established Admin Send StopCCN idle 3318 Tunnel Close Clean up 3320 wait-ctl-reply, 3321 wait-ctl-conn, 3322 established Receive StopCCN Clean up idle 3324 idle 3325 Both initiator and recipient start from this state. An initiator 3326 transmits a SCCRQ, while a recipient remains in the idle state 3327 until receiving a SCCRQ. 3329 wait-ctl-reply 3330 The originator checks to see if another connection has been 3331 requested from the same peer, and if so, handles the collision 3332 situation described in Section 6.0.1. 3334 When a SCCRP is received, it is examined for a compatible version. 3335 If the version of the reply is lower than the version sent in the 3336 request, the older (lower) version should be used provided it is 3337 supported. If the version in the reply is earlier and supported, 3338 the originator moves to the established state. If the version is 3339 earlier and not supported, a StopCCN MUST be sent to the peer and 3340 the originator cleans up and terminates the tunnel. 3342 wait-ctl-conn 3343 This is where an SCCCN is awaited; upon receipt, protocol version 3344 compatibility is checked. The tunnel is either established, or is 3345 torn down if a protocol mismatch is detected. 3347 established 3348 An established connection may be terminated by either a local 3349 condition or the receipt of a Stop-Control-Connection- 3350 Notification. In the event of a local termination, the originator 3351 MUST send a Stop-Control-Connection-Notification and clean up the 3352 tunnel. 3354 If the originator receives a Stop-Control-Connection-Notification 3355 it MUST also clean up the tunnel. 3357 7.3 Timing considerations 3359 Because of the real-time nature of telephone signaling, both the LNS 3360 and LAC should be implemented with multi-threaded architectures such 3361 that messages related to multiple calls are not serialized and 3362 blocked. The call and connection state figures do not specify 3363 exceptions caused by timers. These are addressed in Section 6.0.2. 3365 7.4 Incoming calls 3367 An Incoming-Call-Request message is generated by the LAC when an 3368 associated telephone line rings. The LAC selects a Call ID and 3369 serial number and indicates the call bearer type. Modems should 3370 always indicate analog call type. ISDN calls should indicate digital 3371 when unrestricted digital service or rate adaption is used and analog 3372 if digital modems are involved. CLID, DNIS, and subaddress may be 3373 included in the message if they are available from the telephone 3374 network. 3376 Once the LAC sends the Incoming-Call-Request, it waits for a response 3377 from the LNS but it does not necessarily answer the call from the 3378 telephone network yet. The LNS may choose not to accept the call if: 3380 - No resources are available to handle more sessions 3381 - The dialed, dialing, or subaddress fields do not correspond to 3382 an authorized user 3383 - The bearer service is not authorized or supported 3385 If the LNS chooses to accept the call, it responds with an Incoming- 3386 Call-Reply which may also indicate window sizes (see Appendix B). 3387 When the LAC receives the Incoming-Call-Reply, it attempts to connect 3388 the call. A final call connected message from the LAC to the LNS 3389 indicates that the call states for both the LAC and the LNS should 3390 enter the established state. If the call terminated before the LNS 3391 could accept it, a Call-Disconnect-Notify is sent by the LAC to 3392 indicate this condition. 3394 When the dialed-in client hangs up, the call is cleared normally and 3395 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 3396 clear a call, it sends a Call-Disconnect-Notify message and cleans up 3397 its session. 3399 7.4.1 LAC Incoming Call States 3401 State Event Action New State 3402 ----- ----- ------ --------- 3403 idle Bearer Ring or Initiate local wait-tunnel 3404 Ready to indicate tunnel open 3405 incoming conn. 3407 wait-tunnel tunnel-open Send ICRQ wait-reply 3409 wait-reply Receive ICRP, Answer call, established 3410 acceptable Send ICCN 3412 wait-reply Receive ICRP, Send CDN, idle 3413 not acceptable Clean up 3415 wait-reply Receive CDN Clean up idle 3417 wait-reply Local Send CDN, idle 3418 Close request Clean up 3420 established Receive CDN Hang up bearer, idle 3421 Clean up 3423 established Local Hang up bearer, idle 3424 Close request Send CDN, 3425 Clean up 3427 established Bearer Send CDN, idle 3428 Line drop Clean up 3430 The states associated with the LAC for incoming calls are: 3432 idle 3433 The LAC detects an incoming call on one of its interfaces. Typically 3434 this means an analog line is ringing or an ISDN TE has detected an 3435 incoming Q.931 SETUP message. The LAC initiates its tunnel 3436 establishment state machine, and moves to a state waiting for 3437 confirmation of the existence of a tunnel. 3439 wait-tunnel 3440 In this state the session is waiting for either the control tunnel to 3441 be opened or for verification that the tunnel is already open. Once 3442 an indication that the tunnel has/was opened, session control 3443 messages may be exchanged. The first of these is the Incoming-Call- 3444 Request. 3446 wait-reply 3447 The LAC receives an Incoming-Call-Reply message indicating non- 3448 willingness to accept the call (general error or don't accept) and 3449 moves back into the idle state. If the reply message indicates that 3450 the call is accepted, the LAC sends an Incoming-Call-Connected 3451 message and enters the established state. 3453 established 3454 Data is exchanged over the tunnel. The call may be cleared 3455 following: 3456 An event on the connected interface. The LAC sends a Call- 3457 Disconnect-Notify message 3458 Receipt of a Call-disconnect-Notify message. The LAC cleans up, 3459 disconnecting the call. 3460 A local reason. The LAC sends a Call-Disconnect-Notify message. 3462 7.4.2 LNS Incoming Call States 3464 State Event Action New State 3465 ----- ----- ------ --------- 3466 idle Receive ICRQ, Send ICRP wait-connect 3467 acceptable 3469 idle Receive ICRQ, Send CDN, idle 3470 not acceptable Clean up 3472 wait-connect Receive ICCN Prepare for established 3473 acceptable data 3475 wait-connect Receive ICCN Send CDN, idle 3476 not acceptable Clean up 3478 wait-connect, 3479 established Receive CDN Clean up idle 3481 established Local Send CDN, idle 3482 Close request Clean up 3484 The states associated with the LNS for incoming calls are: 3486 idle 3487 An Incoming-Call-Request message is received. If the request is 3488 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 3489 and the LNS remains in the idle state. If the Incoming-Call- 3490 Request message is acceptable, an Incoming-Call-Reply is sent. 3491 The session moves to the wait-connect state. 3493 wait-connect 3494 If the session is still connected on the LAC, the LAC sends an 3495 Incoming-Call-Connected message to the LNS which then moves into 3496 established state. The LAC may send a Call-Disconnect-Notify to 3497 indicate that the incoming caller could not be connected. This 3498 could happen, for example, if a telephone user accidentally places 3499 a standard voice call to an LAC resulting in a handshake failure 3500 on the called modem. 3502 established 3503 The session is terminated either by receipt of a Call-Disconnect- 3504 Notify message from the LAC or by sending a Call-Disconnect- 3505 Notify. Clean up follows on both sides regardless of the 3506 initiator. 3508 7.5 Outgoing calls 3510 Outgoing calls are initiated by an LNS and instruct an LAC to place a 3511 call. There are three messages for outgoing calls: Outgoing-Call- 3512 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 3513 sends an Outgoing-Call-Request specifying the dialed party phone 3514 number and subaddress as well as speed and window parameters. The 3515 LAC MUST respond to the Outgoing-Call-Request message with an 3516 Outgoing-Call-Reply message once the LAC determines that the proper 3517 facilities exist to place the call and the call is administratively 3518 authorized. For example, is this LNS allowed to dial an 3519 international call? Once the outbound call is connected the LAC 3520 sends an Outgoing-Call-Connected message to the LNS indicating the 3521 final result of the call attempt: 3523 7.5.1 LAC Outgoing Call States 3525 State Event Action New State 3526 ----- ----- ------ --------- 3527 idle Receive OCRQ, Send OCRP, wait-cs-answer 3528 acceptable Open bearer 3530 idle Receive OCRQ, Send CDN, idle 3531 not acceptable Clean up 3533 wait-cs-answer Bearer answer, Send OCCN established 3534 framing detected 3536 wait-cs-answer Bearer failure Send CDN, idle 3537 Clean up 3539 wait-cs-answer, 3540 established Receive CDN Hang up bearer, idle 3541 Clean up 3543 The states associated with the LAC for outgoing calls are: 3545 idle 3546 Received Outgoing-Call-Request. If this is received in error, 3547 respond with a Call-Disconnect-Notify. Otherwise, allocate a 3548 physical channel and send an Outgoing-Call-Reply. Place the 3549 outbound call and move to the wait-cs-answer state. 3551 wait-cs-answer 3552 If the call is not completed or a timer expires waiting for the 3553 call to complete, send a Call-Disconnect-Notify with the 3554 appropriate error condition set and go to idle state. If a 3555 circuit switched connection is established and framing is 3556 detected, send an Outgoing-Call-Connected indicating success and 3557 go to established state. 3559 established 3560 If a Call-Disconnect-Notify is received, the telco call MUST be 3561 released via appropriate mechanisms and the session cleaned up. 3562 If the call is disconnected by the client or the called interface, 3563 a Call-Disconnect-Notify message MUST be sent to the LNS. Return 3564 to idle state after sending the Call-Disconnect-Notify. 3566 7.5.2 LNS Outgoing Call States 3568 State Event Action New State 3569 ----- ----- ------ --------- 3570 idle Local Initiate local wait-tunnel 3571 Open request tunnel-open 3573 wait-tunnel tunnel-open Send OCRQ wait-reply 3575 wait-reply Receive OCRP, none wait-connect 3576 acceptable 3578 wait-reply Receive OCRP, Send CDN idle 3579 not acceptable 3581 wait-connect Receive OCCN none established 3583 established, 3584 wait-connect Receive CDN Clean up idle 3586 wait-reply, 3587 wait-connect, 3588 established Local Send CDN idle 3589 Close request 3591 The states associated with the LNS for outgoing calls are: 3593 idle, wait-tunnel 3594 When an outgoing call is initiated, a tunnel is first created, 3595 much as the idle and wait-tunnel states for an LAC incoming call. 3596 Once a tunnel is established, an Outgoing-Call-Request message is 3597 sent to the LAC and the session moves into the wait-reply state. 3599 wait-reply 3600 If a Call-Disconnect-Notify is received, an error occurred, and 3601 the session is cleaned up and returns to idle. If an Outgoing- 3602 Call-Reply is received, the call is in progress and the session 3603 moves to the wait-connect state. 3605 wait-connect 3606 If a Call-Disconnect-Notify is received, the call failed; the 3607 session is cleaned up and returns to idle. If an Outgoing-Call- 3608 Connected is received, the call has succeeded and the session may 3609 now exchange data. 3611 established 3612 If a Call-Disconnect-Notify is received, the call has been 3613 terminated for the reason indicated in the Result and Cause Codes; 3614 the session moves back to the idle state. If the LNS chooses to 3615 terminate the session, it sends a Call-Disconnect-Notify to the 3616 LAC and then cleans up and idles its session. 3618 8.0 L2TP Over Specific Media 3620 L2TP tries to be self-describing, operating at a level above the 3621 particular media over which it is carried. However, some details of 3622 its connection to media are required to permit interoperable 3623 implementations. The following sections describe details needed to 3624 permit interoperability over specific media. 3626 8.1 IP/UDP 3628 L2TP uses the well-known UDP port 1701 [3]. The entire L2TP packet, 3629 including payload and L2TP header, is sent within a UDP datagram. 3630 The initiator of an L2TP tunnel picks an available source UDP port, 3631 and sends to the desired destination at port 1701. The recipient 3632 picks a free port on its own system, and sends its reply to the 3633 initiator's UDP port, setting its own UDP source port set to the free 3634 port it found. All subsequent packets exchanged will use these UDP 3635 ports. It is legal for a peer's IP address used for a given tunnel 3636 to change over the life of a connection; this may correspond to a 3637 peer with multiple IP interfaces responding to a network topology 3638 change. Responses should reflect the last source IP address for that 3639 Tunnel ID. 3641 IP fragmentation may occur as the L2TP packet travels over the IP 3642 substrate. L2TP makes no special efforts to optimize this. A LAC 3643 implementation MAY cause its LCP to negotiate for a specific MRU, 3644 which could optimize for LAC environments in which the MTUs of the 3645 path over which the L2TP packets are likely to travel have a 3646 consistent value. 3648 The default for any L2TP implementation is that UDP checksums MUST be 3649 enabled for both control and payload messages. An L2TP 3650 implementation MAY provide an option to disable UDP checksums for 3651 payload packets. It is recommended that UDP checksums always be 3652 enabled on control packets. 3654 Port 1701 is used for both L2F [5] and L2TP packets. The two types 3655 of packets may be detected by their headers; L2TP has a Vers field of 3656 2, L2F has a 1 in this field instead. An L2TP implementation running 3657 on a system which does not support L2F MUST silently discard all 3658 packets whose Vers field is set to 1. 3660 8.2 IP 3662 When operating in IP environments, L2TP MUST offer the UDP 3663 encapsulation described in 8.1 as its default configuration for IP 3664 operation. Other configurations (perhaps corresponding to a 3665 compressed header format) may be defined, and made available as a 3666 configurable option. 3668 9.0 Security Considerations 3670 L2TP encounters several security issues in its operation. The 3671 general approach of L2TP to these issues is documented here. 3673 9.1 Tunnel Endpoint Security 3675 The tunnel endpoints may authenticate each other during tunnel 3676 establishment. This authentication has the same security 3677 attributes as CHAP, and has reasonable protection against replay 3678 and snooping. In environments where some L2TP peers will be 3679 authenticated, but others not, a mechanism should be provided to 3680 control when tunnel endpoint authentication will be active. 3682 The LAC and LNS MUST share a single secret for authentication of 3683 both ends of the tunnel. Each side uses this same secret when 3684 acting as authenticatee as well as authenticator. Since a single 3685 secret it used, the tunnel authentication AVPs include 3686 differentiating values in the CHAP ID fields for each message 3687 digest calculation to guard against replay attacks. 3689 For L2TP tunnels over IP, IP-level packet security provides very 3690 strong protection of the tunnel. This requires no modification to 3691 the L2TP protocol, and leverages extensive IETF work in this area. 3693 For L2TP tunnels over Frame Relay or other switched networks, 3694 current practice indicates that these media are much less likely 3695 to experience attacks of in-transit data. If these attacks became 3696 prevalent, either the media or the L2TP packets would have to be 3697 encrypted. 3699 Because the shared secret used for endpoint authentication is the 3700 same shared secret used to obscure AVP contents using the H 3701 (Hidden) bit, tunnel authentication must be used in all cases 3702 where the H bit will be used. Proxy authentication involving PAP 3703 may be usable without the H bit if PAP is only carrying one-time 3704 passwords; if clear text passwords are carried in the proxy 3705 authentication, the H bit (and, by implication, tunnel 3706 authentication) should be used. 3708 To protect against exhaustive attack during tunnel authentication, 3709 no tunnel authentication response should ever be accepted if it 3710 corresponds to a challenge more than one minute old. 3712 9.2 Client Security 3714 A more systematic method of protection in tunneled PPP 3715 environments may be achieved through client security. PPP layer 3716 encryption would provide end-to-end security for both direct 3717 dial-in clients as well as PPP clients carried within a tunnel. 3718 With this level of client security, sessions are protected against 3719 attacks against the carrying tunnel, as well as attacks on the LAC 3720 itself. Because both encryption and compression can occur at the 3721 PPP layer, the two can be coordinated, permitting compression to 3722 precede encryption. 3724 9.3 Proxy Authentication 3726 The optional proxy CHAP function of L2TP can permit an entirely 3727 transparent PPP tunnel, with a single LCP and CHAP sequence being 3728 seen by the client. For cases where the LAC and the entire path 3729 to the LNS are operated by a single entity, this function may 3730 provide acceptable security. For cases where LNS-initiated 3731 authentication is required, proxy CHAP still permits an initial 3732 access decision to be made before accepting the tunnel, permitting 3733 the LNS in most cases to reject tunnel initiations rather than 3734 accept them and later disconnect. 3736 The optional proxy PAP may result in the cleartext password 3737 traversing the tunnel. Where PAP is being used in conjunction 3738 with static passwords, this may pose a significant security issue. 3739 Where PAP is only used to transport one-time passwords, such 3740 issues may be greatly mitigated. The H bit of the carrying AVP 3741 may be used to protect against this. 3743 All implementations MUST accept proxy authentication AVP's, but 3744 are free to silently discard them and initiate an entirely new 3745 authentication with the PPP client. 3747 10.0 Acknowledgments 3749 The AVP construct comes from Glen Zorn, who thought up the framework 3750 for permitting multiple vendors to contribute to a common attribute 3751 space in a relatively orderly fashion. 3753 Dory Leifer and Allan Rubens of Ascend Communications made valuable 3754 refinements to the protocol definition of L2TP and contributed to the 3755 editing of this document. 3757 Steve Cobb and Evan Caves redesigned the state machine tables. 3759 Barney Wolff provided a great deal of design input on the endpoint 3760 authentication mechanism. 3762 11.0 Contacts 3764 Kory Hamzeh 3765 Ascend Communications 3766 1275 Harbor Bay Parkway 3767 Alameda, CA 94502 3768 kory@ascend.com 3770 Tim Kolar, Morgan Littlewood, Bill Palter, Andrew J. Valencia 3771 Cisco Systems 3772 170 West Tasman Drive 3773 San Jose CA 95134-1706 3774 tkolar@cisco.com 3775 littlewo@cisco.com 3776 palter@cisco.com 3777 vandys@cisco.com 3779 Gurdeep Singh Pall 3780 Microsoft Corporation 3781 Redmond, WA 3782 gurdeep@microsoft.com 3784 Jeff Taarud 3785 Copper Mountain Networks 3786 jtaarud@coppermountain.com 3788 W. Mark Townsley 3789 IBM Corporation 3790 700 Park Office Dr. 3791 Raleigh, NC 27709 3792 wmt@raleigh.ibm.com 3794 William Verthein 3795 U.S. Robotics 3797 12.0 References 3799 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 3800 07/21/1994 3802 [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet 3803 draft, April 1996 3805 [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point 3806 Tunneling Protocol", Internet draft, June 1996 3808 [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC1034, 3809 November 1987 3811 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, 3812 USC/Information Sciences Institute, July 1992. 3814 [6] Sally Floyd, Van Jacobson, "Random Early Detection Gateways for 3815 Congestion Avoidance", IEEE/ACM Transactions on Networking, 3816 August 1993 3818 [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, 3819 October 1996 3821 [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authentication 3822 Dial In User Service (RADIUS)." draft-ietf-radius-radius-05.txt, 3823 Livingston, Merit, Daydreamer, July 1996. 3825 Appendix A: Acknowledgment Time-Outs 3827 L2TP uses sliding windows and time-outs to provide both user session 3828 flow-control across the underlying medium (which may be an 3829 internetwork) and to perform efficient data buffering to keep the 3830 LAC-LNS data channels full without causing receive buffer overflow. 3831 L2TP requires that a time-out be used to recover from dropped data or 3832 acknowledgment packets. The exact implementation of the time-out is 3833 vendor-specific. It is suggested that an adaptive time-out be 3834 implemented with backoff for congestion control. The time-out 3835 mechanism proposed here has the following properties: 3837 Independent time-outs for each session. A device (LAC or LNS) 3838 will have to maintain and calculate time-outs for every active 3839 session. 3841 An administrator-adjustable maximum time-out, MaxTimeOut, unique 3842 to each device. 3844 An adaptive time-out mechanism that compensates for changing 3845 throughput. To reduce packet processing overhead, vendors may 3846 choose not to recompute the adaptive time-out for every received 3847 acknowledgment. The result of this overhead reduction is that the 3848 time-out will not respond as quickly to rapid network changes. 3850 Timer backoff on time-out to reduce congestion. The backed-off 3851 timer value is limited by the configurable maximum time-out value. 3852 Timer backoff is done every time an acknowledgment time-out 3853 occurs. 3855 In general, this mechanism has the desirable behavior of quickly 3856 backing off upon a time-out and of slowly decreasing the time-out 3857 value as packets are delivered without time-outs. 3859 Some definitions: 3861 Packet Processing Delay, "PPD", is the amount of time required for 3862 each peer to process the maximum amount of data buffered in its 3863 offered receive packet window. The PPD is the value exchanged 3864 between the LAC and LNS when a call is established. For the LNS, 3865 this number should be small. For an LAC supporting modem 3866 connections, this number could be significant. 3868 "Sample" is the actual amount of time incurred receiving an 3869 acknowledgment for a packet. The Sample is measured, not 3870 calculated. 3872 Round-Trip Time, "RTT", is the estimated round-trip time for an 3873 Acknowledgment to be received for a given transmitted packet. 3874 When the network link is a local network, this delay will be 3875 minimal (if not zero). When the network link is the Internet, 3876 this delay could be substantial and vary widely. RTT is adaptive: 3877 it will adjust to include the PPD and whatever shifting network 3878 delays contribute to the time between a packet being transmitted 3879 and receiving its acknowledgment. 3881 Adaptive Time-Out, "ATO", is the time that must elapse before an 3882 acknowledgment is considered lost. After a time-out, the sliding 3883 window is partially closed and the ATO is backed off. 3885 Packet Processing Delay (PPD) 3887 The PPD parameter is a 16-bit time value exchanged during the Call 3888 Control phase expressed in units of tenths of a second (64 means 6.4 3889 seconds). The protocol only specifies that the parameter is 3890 exchanged, it does not specify how it is calculated. The way values 3891 for ATO are calculated is implementation-dependent and need not be 3892 variable (static time-outs are allowed). IF adaptive time-outs are 3893 to be used then the PPD should be exchanged in the call connect 3894 sequences. A possible way to calculate the PPD is: 3896 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 3897 + LACFudge (for an LAC) 3898 or 3899 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 3900 + LNSFudge (for an LNS) 3902 Header is the total size of the L2TP and media dependent headers. 3903 MTU is the overall MTU for the link between the LAC and LNS. 3904 WindowSize represents the number of packets in the sliding window, 3905 and is implementation-dependent. The latency of the underlying 3906 connection path between the LAC and LNS could be used to pick a 3907 window size sufficient to keep the current session's pipe full. The 3908 constant 8 converts octets to bits (assuming ConnectRate is in bits 3909 per second). If ConnectRate is in bytes per second, omit the 8. 3910 LACFudge and LNSFudge are not required but can be used to take 3911 overall processing overhead of the LAC or LNS into account. 3913 In the case of the computed PPD for an LNS, AvePathRate is the 3914 average bit rate of the path between the LNS and LAC. Given that 3915 this number is probably very large and WindowSize is relatively 3916 small, LNSFudge will be the dominant factor in the computation of 3917 PPD. It is recommended that the minimum value of PPD be on the order 3918 of 0.5 second. 3920 The value of PPD is used to seed the adaptive algorithm with the 3921 initial RTT[n-1] value. 3923 A.1 Calculating Adaptive Acknowledgment Time-Out 3925 We still must decide how much time to allow for acknowledgments to 3926 return. If the time-out is set too high, we may wait an 3927 unnecessarily long time for dropped packets. If the time-out is too 3928 short, we may time out just before the acknowledgment arrives. The 3929 acknowledgment time-out should also be reasonable and responsive to 3930 changing network conditions. 3932 The suggested adaptive algorithm detailed below is based on the TCP 3933 1989 implementation and is explained in Richard Steven's book TCP/IP 3934 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 3935 calculation, and 'n-1' refers to values from the last calculation. 3937 DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta * 3938 (|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 3939 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 3941 DIFF represents the error between the last estimated round-trip 3942 time and the measured time. DIFF is calculated on each iteration. 3944 DEV is the estimated mean deviation. This approximates the 3945 standard deviation. DEV is calculated on each iteration and 3946 stored for use in the next iteration. Initially, it is set to 0. 3948 RTT is the estimated round-trip time of an average packet. RTT is 3949 calculated on each iteration and stored for use in the next 3950 iteration. Initially, it is set to PPD. 3952 ATO is the adaptive time-out for the next transmitted packet. ATO 3953 is calculated on each iteration. Its value is limited, by the MIN 3954 function, to be a maximum of the configured MaxTimeOut value. 3956 Alpha is the gain for the average and is typically 1/8 (0.125). 3958 Beta is the gain for the deviation and is typically 1/4 (0.250). 3960 Chi is the gain for the time-out and is typically set to 4. 3962 To eliminate division operations for fractional gain elements, the 3963 entire set of equations can be scaled. With the suggested gain 3964 constants, they should be scaled by 8 to eliminate all division. To 3965 simplify calculations, all gain values are kept to powers of two so 3966 that shift operations can be used in place of multiplication or 3967 division. The above calculations are carried out each time an 3968 acknowledgment is received for a packet that was not retransmitted 3969 (no time-out occurs). 3971 A.2 Congestion Control: Adjusting for Time-Out 3973 This section describes how the calculation of ATO is modified in the 3974 case where a time-out does occur. When a time-out occurs, the time- 3975 out value should be adjusted rapidly upward. Although L2TP payload 3976 packets are not retransmitted when a time-out occurs, the time-out 3977 should be adjusted up toward a maximum limit. To compensate for 3978 shifting internetwork time delays, a strategy must be employed to 3979 increase the time-out when it expires. A simple formula called 3980 Karn's Algorithm is used in TCP implementations and may be used in 3981 implementing the backoff timers for the LNS or the LAC. Notice that 3982 in addition to increasing the time-out, we also shrink the size of 3983 the window as described in the next section. 3985 Karn's timer backoff algorithm, as used in TCP, is: 3987 NewTIMEOUT = delta * TIMEOUT 3989 Adapted to our time-out calculations, for an interval in which a 3990 time-out occurs, the new time-out interval ATO is calculated as: 3992 RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MIN (RTT[n] + 3993 (chi * DEV[n]), MaxTimeOut) 3995 In this modified calculation of ATO, only the two values that 3996 contribute to ATO and that are stored for the next iteration are 3997 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 3998 not carried forward and is not used in this scenario. A value of 2 3999 for Delta, the time-out gain factor for RTT, is suggested. 4001 Appendix B: Acknowledgment Time-Out and Window Adjustment 4003 B.1 Initial Window Size 4005 Although each side has indicated the maximum size of its receive 4006 window, it is recommended that a slow start method be used to begin 4007 transmitting data. The initial maximum window size on the 4008 transmitter is set to half the maximum size the receiver requested, 4009 with a minimum size of one packet. The transmitter stops sending 4010 packets when the number of packets awaiting acknowledgment is equal 4011 to the current maximum window size. As the receiver successfully 4012 digests each window, the maximum window size on the transmitter is 4013 bumped up by one packet until the maximum specified by the receiver 4014 is reached. This method prevents a system from flooding an already 4015 congested network because no history has been established. 4017 When for any reason an LAC or LNS receives more data than it can 4018 queue for the tunnel, a packet must be discarded. In this case, it 4019 is recommended that a "random early discard" algorithm [6] be used 4020 rather than the obvious "drop last" algorithm. 4022 B.2 Closing the Window 4024 When a time-out does occur on a packet, the sender adjusts the size 4025 of the transmit window down to one half its maximum value when it 4026 failed. Fractions are rounded up, and the minimum window size is 4027 one. 4029 B.3 Opening the Window 4031 With every successful transmission of a window's worth of packets 4032 without a time-out, the maximum transmit window size is increased by 4033 one packet until it reaches the maximum window size that was sent by 4034 its peer when the call was connected. As stated earlier, no 4035 retransmission is done on a time-out. After a time-out, transmission 4036 resumes with the maximum transmit window starting at one half the 4037 size of the maximum transmit window when the time-out occurred (with 4038 a minimum window size of 1) and adjusting upward by one each time the 4039 current maximum transmit window is filled with packets that are all 4040 acknowledged without time-outs. 4042 B.4 Window Overflow 4044 When a receiver's window overflows with too many incoming packets, 4045 excess packets are thrown away. This situation should not arise if 4046 the sliding window procedures are being properly followed by the 4047 transmitter and receiver. It is assumed that, on the transmit side, 4048 packets are buffered for transmission and are no longer accepted from 4049 the packet source when the transmit buffer fills. 4051 Appendix C: Handling of out-of-order packets 4053 When the Sequence Number and Acknowledgment Number fields are present 4054 in payload packets, they are used to manage packet rate. In 4055 addition, they may be used to handle out-of-order arrival of packets. 4056 A simple L2TP client would simply discard any packet other than a 4057 packet with a sequence greater than that last received; if packets 1, 4058 2, 3 arrived as 1, 3, 2, this would result in packet 2 being 4059 discarded. 4061 Such behavior does not affect the L2TP protocol itself, but 4062 significantly improved throughput in such environments may be 4063 attained by queueing and reordering packets when they arrive out of 4064 order. The number of packets to be queued is a function of memory 4065 resources on the L2TP implementation, but should never be more than 4066 1/4 of the total sequence number space (i.e., 16384 packets), to 4067 avoid aliasing. 4069 An implementation which queues packets in this way must also employ 4070 an algorithm for deciding that a given sequence number corresponds to 4071 a packet which is lost, rather than one which is out of order but 4072 still in transit. Such a decision would likely be based upon timing, 4073 buffering conditions, and packet arrival characteristics. The 4074 details of such a tradeoff are outside the scope of this 4075 specification, but it is recommended a packet should be afforded an 4076 interval at least twice the estimated RTT from the L2TP peer. 4078 Appendix D: Transport Layer Adaptive Time-outs and Window Adjustment 4080 Appendixes A, B, and C dealt with operation of the payload packet 4081 sessions of L2TP. This Appendix explains how these three algorithms 4082 pertain to the transport layer for L2TP control sessions. Appendix B, 4083 Time-out Window Management, directly applies to the Transport Layer 4084 except in the case where a window size of 1 is being used. Appendix 4085 C, does not really apply because, for the Control Session, control 4086 messages MUST always be processed by the receiver in order. Also, 4087 there are no lost control packets because they are retransmitted by 4088 the L2TP Transport Layer. Thus, the main topic of this Appendix is 4089 how to adapt the example adaptive time-out algorithm of Appendix A to 4090 the Control Session Transport Layer. 4092 There are two main differences between the Control Session and 4093 payload sessions: 1) Unlike lost payload packets, lost control 4094 messages are retransmitted and 2) There is no Packet Processing Delay 4095 value provided in the control session setup messages. The latter 4096 affects the manner in which the initial value of the RTT estimate is 4097 determined. The former really doesn't affect the algorithm at all, 4098 except that upon a time-out, retransmission of unacknowledged control 4099 messages should be attempted, up to the number that fit in the 4100 sliding window with size computed as in Appendix B. 4102 Using the symbol definitions of Appendix A, the calculation of the 4103 value for the PPD of the remote peer can be estimated as: 4105 PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate 4106 + Fudge 4108 This is simply the number of bits in a full control session window 4109 divided by the average speed of the path between the LAC and LNS with 4110 a fudge factor added on to make it work. In cases where the average 4111 rate of the connection between LAC and LNS isn't known, it is 4112 suggested that some value be configured that is associated with each 4113 possible peer. Because Control Session windows will most likely be 4114 small and the connection speed will be quite high, fudge will be the 4115 dominant factor in this calculation. For this reason, just 4116 configuring a single fixed initial PPD estimate to be used for all 4117 possible peers will probably provide adequate results. This fudge 4118 factor should probably be at least 0.5 second. 4120 Appendix E: Examples of L2TP sequence numbering 4122 Although sequence numbers serve distinct purposes for control and 4123 data messages, both types of messages use identical techniques for 4124 assigning sequence numbers. This appendix shows several common 4125 scenarios, and illustrates how sequence number state progresses and 4126 is interpreted. 4128 E.1: Lock-step tunnel establishment 4130 In this example, an LAC establishes a tunnel, with the exchange 4131 involving each side alternating in sending messages. This example 4132 is contrived, in that the final acknowledgment in the example is 4133 explicitly sent within a zero-length message, although most 4134 typically the acknowledgment would have been included in the 4135 processing of the Incoming-Call-Request which had prompted the LAC 4136 to initiate the tunnel in the first place. 4138 LAC LNS 4139 -> Start-Control-Connection-Request 4140 Nr: 0, Ns: 0 4142 Start-Control-Connection-Reply <- 4143 Nr: 1, Ns: 0 4145 -> Start-Control-Connection-Connected 4146 Nr: 1, Ns: 1 4148 (delay) 4150 (zero-length) <- 4151 Nr: 2, Ns: 1 4153 E.2: Multiple packets acknowledged 4155 This example shows a flow of payload packets from the LNS to the 4156 LAC, with the LAC having no traffic of its own. The LAC is 4157 waiting 1/4 of its timeout interval, and then acknowledging all 4158 packets seen since the last interval. 4160 (previous packet flow precedes this) 4162 LAC LNS 4163 -> (zero-length) 4164 Nr: 7000, Ns: 1000 4165 (payload) <- 4166 Nr: 1000, Ns: 7000 4167 (payload) <- 4168 Nr: 1000, Ns: 7001 4169 (payload) <- 4170 Nr: 1000, Ns: 7002 4172 (LAC's timer indicates it should acknowledge pending traffic) 4174 -> (zero-length) 4175 Nr: 7003, Ns: 1000 4177 E.3: Lost packet with retransmission 4179 As a final example, an existing tunnel has a new session requested 4180 by the LAC. The Incoming-Call-Reply is lost and must be 4181 retransmitted by the LNS. This example continues from the 4182 sequence state reached at the end of example E.1. Note that loss 4183 of the -Reply has two impacts: not only does it keep the upper 4184 level state machine from progressive, but it also keeps the LAC 4185 from seeing a timely lower level acknowledgment of its -Request 4186 packet. 4188 LAC LNS 4189 -> Incoming-Call-Request 4190 Nr: 1, Ns: 2 4191 Incoming-Call-Reply <- 4192 Nr: 3, Ns: 1 4194 (pause; LAC's timer started first, so fires first) 4196 -> Incoming-Call-Request 4197 Nr: 1, Ns: 2 4199 (LNS realizes it has already seen this packet) 4200 (LNS might use this as a cue to retransmit, as in this example) 4202 Incoming-Call-Reply <- 4203 Nr: 3, Ns: 1 4204 -> Incoming-Call-Connected 4205 Nr: 2, Ns: 3 4207 (delay) 4209 (zero-length) <- 4210 Nr: 4, Ns: 2