idnits 2.17.1 draft-ietf-pppext-l2tp-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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. == Mismatching filename: the document gives the document name as 'draft-ietf-pppext-l2tp-13', but the file name used is 'draft-ietf-pppext-l2tp-14' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC1661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2617 has weird spacing: '...e local wai...' == Line 2618 has weird spacing: '...ndicate tunne...' == Line 2827 has weird spacing: '...e local wai...' -- 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.) -- The document date (February 1999) is 9201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Home LAN' is mentioned on line 331, but not defined == Missing Reference: 'System' is mentioned on line 331, but not defined == Missing Reference: 'KPS' is mentioned on line 669, but not defined == Missing Reference: 'DSS1' is mentioned on line 1165, but not defined == Missing Reference: 'Remote' is mentioned on line 1819, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 3103, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'PPTP' is mentioned on line 3189, but not defined == Unused Reference: 'RFC791' is defined on line 3119, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 3153, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 3173, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2138 (Obsoleted by RFC 2865) ** Downref: Normative reference to an Historic RFC: RFC 2341 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. 'STEVENS' Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W. M. Townsley 2 Internet-Draft A. Valencia 3 Category: Standards Track cisco Systems 4 A. Rubens 5 Ascend Communications 6 G. S. Pall 7 G. Zorn 8 Microsoft Corporation 9 B. Palter 10 Redback Networks 11 February 1999 13 Layer Two Tunneling Protocol "L2TP" 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress''. 30 To learn the current status of any Internet-Draft, please check the 31 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 32 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 33 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 35 The distribution of this memo is unlimited. It is filed as and expires August 8, 1999. Please send 37 comments to the L2TP mailing list (l2tp@ipsec.org). 39 Abstract 41 This document describes the Layer Two Tunneling Protocol (L2TP). RFC 42 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP 43 facilitates the tunneling of PPP packets across an intervening 44 network in a way that is as transparent as possible to both end-users 45 and applications. 47 Table of Contents 49 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.0 Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 3.0 Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 54 3.1 L2TP Header Format . . . . . . . . . . . . . . . . . . . . 9 55 3.2 Control Message Types . . . . . . . . . . . . . . . . . . 11 56 4.0 Control Message Attribute Value Pairs . . . . . . . . . . 12 57 4.1 AVP Format . . . . . . . . . . . . . . . . . . . . . . . . 12 58 4.2 Hiding of AVP Values . . . . . . . . . . . . . . . . . . . 13 59 4.3 AVP Summary . . . . . . . . . . . . . . . . . . . . . . . 15 60 4.3.1 AVPs Applicable To All Control Messages . . . . . . . . . 16 61 4.3.2 Result and Error Codes . . . . . . . . . . . . . . . . . . 17 62 4.3.3 Control Connection Management AVPs . . . . . . . . . . . . 19 63 4.3.4 Call Management AVPs . . . . . . . . . . . . . . . . . . . 25 64 4.3.5 Proxy LCP and Authentication AVPs . . . . . . . . . . . . 31 65 4.3.6 Call Status AVPs . . . . . . . . . . . . . . . . . . . . . 36 66 5.0 Protocol Operation . . . . . . . . . . . . . . . . . . . . 39 67 5.1 Control Connection Establishment . . . . . . . . . . . . . 39 68 5.1.1 Tunnel Authentication . . . . . . . . . . . . . . . . . . 40 69 5.2 Session Establishment . . . . . . . . . . . . . . . . . . 40 70 5.2.1 Incoming Call Establishment . . . . . . . . . . . . . . . 40 71 5.2.2 Outgoing Call Establishment . . . . . . . . . . . . . . . 41 72 5.3 Forwarding PPP Frames . . . . . . . . . . . . . . . . . . 41 73 5.4 Using Sequence Numbers on the Data Channel . . . . . . . . 42 74 5.5 Keepalive (Hello) . . . . . . . . . . . . . . . . . . . . 42 75 5.6 Session Teardown . . . . . . . . . . . . . . . . . . . . . 43 76 5.7 Control Connection Teardown . . . . . . . . . . . . . . . 43 77 5.8 Reliable Delivery of Control Messages . . . . . . . . . . 43 78 6.0 Control Connection Protocol Specification . . . . . . . . 45 79 6.1 Start-Control-Connection-Request (SCCRQ) . . . . . . . . . 46 80 6.2 Start-Control-Connection-Reply (SCCRP) . . . . . . . . . . 46 81 6.3 Start-Control-Connection-Connected (SCCCN) . . . . . . . . 47 82 6.4 Stop-Control-Connection-Notification (StopCCN) . . . . . . 47 83 6.5 Hello (HELLO) . . . . . . . . . . . . . . . . . . . . . . 47 84 6.6 Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . . 48 85 6.7 Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . . 49 86 6.8 Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . . 49 87 6.9 Outgoing-Call-Request (ICRQ) . . . . . . . . . . . . . . . 50 88 6.10 Outgoing-Call-Reply (ICRP) . . . . . . . . . . . . . . . . 50 89 6.11 Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . . 51 90 6.12 Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . . 51 91 6.13 WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . . 51 92 6.14 Set-Link-Info (SLI) . . . . . . . . . . . . . . . . . . . 52 93 7.0 Control Connection State Machines . . . . . . . . . . . . 52 94 7.1 Control Connection Protocol Operation . . . . . . . . . . 52 95 7.2 Control Connection States . . . . . . . . . . . . . . . . 53 96 7.2.1 Control Connection Establishment . . . . . . . . . . . . . 53 97 7.3 Timing considerations . . . . . . . . . . . . . . . . . . 55 98 7.4 Incoming Calls . . . . . . . . . . . . . . . . . . . . . . 55 99 7.4.1 LAC Incoming Call States . . . . . . . . . . . . . . . . . 56 100 7.4.2 LNS Incoming Call States . . . . . . . . . . . . . . . . . 57 101 7.5 Outgoing calls . . . . . . . . . . . . . . . . . . . . . . 59 102 7.5.1 LAC Outgoing Call States . . . . . . . . . . . . . . . . . 59 103 7.5.2 LNS Outgoing Call States . . . . . . . . . . . . . . . . . 60 104 7.6 Tunnel Disconnection . . . . . . . . . . . . . . . . . . . 62 105 8.0 L2TP Over Specific Media . . . . . . . . . . . . . . . . . 62 106 8.1 L2TP over UDP/IP . . . . . . . . . . . . . . . . . . . . . 62 107 8.2 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 108 9.0 Security Considerations . . . . . . . . . . . . . . . . . 64 109 9.1 Tunnel Endpoint Security . . . . . . . . . . . . . . . . . 64 110 9.2 Proxy PPP Authentication . . . . . . . . . . . . . . . . . 64 111 10.0 IANA Considerations . . . . . . . . . . . . . . . . . . . 65 112 10.1 AVP Attribute Type Values . . . . . . . . . . . . . . . . 65 113 10.2 Message AVP Values . . . . . . . . . . . . . . . . . . . . 65 114 10.3 Result Code AVP Values . . . . . . . . . . . . . . . . . . 65 115 10.4 Framing Capabilities & Bearer Capabilities . . . . . . . . 66 116 10.5 Proxy Authen Type AVP Values . . . . . . . . . . . . . . . 66 117 10.6 AVP Header Bits . . . . . . . . . . . . . . . . . . . . . 66 118 11.0 References . . . . . . . . . . . . . . . . . . . . . . . . 66 119 12.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 68 120 13.0 Author's Addresses . . . . . . . . . . . . . . . . . . . . 68 121 Appendix A: Control Channel Slow Start and Congestion 122 Avoidance . . . . . . . . . . . . . . . . . . . . . 69 123 Appendix B: Control Message Examples . . . . . . . . . . . . . . 70 125 1.0 Introduction 127 PPP [RFC1661] defines an encapsulation mechanism for transporting 128 multiprotocol packets across layer 2 (L2) point-to-point links. 129 Typically, a user obtains a L2 connection to a Network Access Server 130 (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN, 131 ADSL, etc.) and then runs PPP over that connection. In such a 132 configuration, the L2 termination point and PPP session endpoint 133 reside on the same physical device (i.e., the NAS). 135 L2TP extends the PPP model by allowing the L2 and PPP endpoints to 136 reside on different devices interconnected by a packet-switched 137 network. With L2TP, a user has an L2 connection to an access 138 concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the 139 concentrator then tunnels individual PPP frames to the NAS. This 140 allows the actual processing of PPP packets to be divorced from the 141 termination of the L2 circuit. 143 One obvious benefit of such a separation is that instead of requiring 144 the L2 connection terminate at the NAS (which may require a long- 145 distance toll charge), the connection may terminate at a (local) 146 circuit concentrator, which then extends the logical PPP session over 147 a shared infrastructure such as frame relay circuit or the Internet. 148 From the user's perspective, there is no functional difference 149 between having the L2 circuit terminate in a NAS directly or using 150 L2TP. 152 L2TP may also solve the multilink hunt-group splitting problem. 153 Multilink PPP [RFC1990] requires that all channels composing a 154 multilink bundle be grouped at a single Network Access Server (NAS). 155 Due to its ability to project a PPP session to a location other than 156 the point at which it was physically received, L2TP can be used to 157 make all channels terminate at a single NAS. This allows multilink 158 operation even when the calls are spread across distinct physical 159 NASs. 161 This document defines the necessary control protocol for on-demand 162 creation of tunnels between two nodes and the accompanying 163 encapsulation for multiplexing multiple, tunneled PPP sessions. 165 1.1 Specification of Requirements 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 1.2 Terminology 173 Analog Channel 175 A circuit-switched communication path which is intended to carry 176 3.1 kHz audio in each direction. 178 Attribute Value Pair (AVP) 180 The variable length concatenation of a unique Attribute 181 (represented by an integer) and a Value containing the actual 182 value identified by the attribute. Multiple AVPs make up Control 183 Messages which are used in the establishment, maintenance, and 184 teardown of tunnels. 186 Call 188 A connection (or attempted connection) between a Remote System and 189 LAC. For example, a telephone call through the PSTN. A Call 190 (Incoming or Outgoing) which is successfully established between a 191 Remote System and LAC results in a corresponding L2TP Session 192 within a previously established Tunnel between the LAC and LNS. 193 (See also: Session, Incoming Call, Outgoing Call). 195 Called Number 197 An indication to the receiver of a call as to what telephone 198 number the caller used to reach it. 200 Calling Number 202 An indication to the receiver of a call as to the telephone number 203 of the caller. 205 CHAP 207 Challenge Handshake Authentication Protocol [RFC1994], a PPP 208 cryptographic challenge/response authentication protocol in which 209 the cleartext password is not passed over the line. 211 Control Connection 213 A control connection operates in-band over a tunnel to control the 214 establishment, release, and maintenance of sessions and of the 215 tunnel itself. 217 Control Messages 219 Control messages are exchanged between LAC and LNS pairs, 220 operating in-band within the tunnel protocol. Control messages 221 govern aspects of the tunnel and sessions within the tunnel. 223 Digital Channel 225 A circuit-switched communication path which is intended to carry 226 digital information in each direction. 228 DSLAM 230 Digital Subscriber Line (DSL) Access Module. A network device used 231 in the deployment of DSL service. This is typically a concentrator 232 of individual DSL lines located in a central office (CO) or local 233 exchange. 235 Incoming Call 237 A Call received at an LAC to be tunneled to an LNS (see Call, 238 Outgoing Call). 240 L2TP Access Concentrator (LAC) 242 A node that acts as one side of an L2TP tunnel endpoint and is a 243 peer to the L2TP Network Server (LNS). The LAC sits between an 244 LNS and a remote system and forwards packets to and from each. 245 Packets sent from the LAC to the LNS requires tunneling with the 246 L2TP protocol as defined in this document. The connection from 247 the LAC to the remote system is either local (see: Client LAC) or 248 a PPP link. 250 L2TP Network Server (LNS) 252 A node that acts as one side of an L2TP tunnel endpoint and is a 253 peer to the L2TP Access Concentrator (LAC). The LNS is the 254 logical termination point of a PPP session that is being tunneled 255 from the remote system by the LAC. 257 Management Domain (MD) 259 A network or networks under the control of a single 260 administration, policy or system. For example, an LNS's Management 261 Domain might be the corporate network it serves. An LAC's 262 Management Domain might be the Internet Service Provider that owns 263 and manages it. 265 Network Access Server (NAS) 267 A device providing local network access to users across a remote 268 access network such as the PSTN. An NAS may also serve as an LAC, 269 LNS or both. 271 Outgoing Call 273 A Call placed by an LAC on behalf of an LNS (see Call, Incoming 274 Call). 276 Peer 278 When used in context with L2TP, peer refers to either the LAC or 279 LNS. An LAC's Peer is an LNS and vice versa. When used in context 280 with PPP, a peer is either side of the PPP connection. 282 POTS 284 Plain Old Telephone Service. 286 Remote System 287 An end-system or router attached to a remote access network (i.e. 288 a PSTN), which is either the initiator or recipient of a call. 289 Also referred to as a dial-up or virtual dial-up client. 291 Session 293 L2TP is connection-oriented. The LNS and LAC maintain state for 294 each Call that is initiated or answered by an LAC. An L2TP Session 295 is created between the LAC and LNS when an end-to-end PPP 296 connection is established between a Remote System and the LNS. 297 Datagrams related to the PPP connection are sent over the Tunnel 298 between the LAC and LNS. There is a one to one relationship 299 between established L2TP Sessions and their associated Calls. (See 300 also: Call). 302 Tunnel 304 A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a 305 Control Connection and zero or more L2TP Sessions. The Tunnel 306 carries encapsulated PPP datagrams and Control Messages between 307 the LAC and the LNS. 309 Zero-Length Body (ZLB) Message 311 A control packet with only an L2TP header. ZLB messages are used 312 for explicitly acknowledging packets on the reliable control 313 channel. 315 2.0 Topology 317 The following diagram depicts a typical L2TP scenario. The goal is to 318 tunnel PPP frames between the Remote System or LAC Client and an LNS 319 located at a Home LAN. 321 [Home LAN] 322 [LAC Client]----------+ | 323 ____|_____ +--[Host] 324 | | | 325 [LAC]---------| Internet |-----[LNS]-----+ 326 | |__________| | 327 _____|_____ : 328 | | 329 | PSTN | 330 [Remote]--| Cloud | 331 [System] | | [Home LAN] 332 |___________| | 333 | ______________ +---[Host] 334 | | | | 335 [LAC]-------| Frame Relay |---[LNS]-----+ 336 | or ATM Cloud | | 337 |______________| : 339 The Remote System initiates a PPP connection across the PSTN Cloud to 340 an LAC. The LAC then tunnels the PPP connection across the Internet, 341 Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is 342 obtained. The Remote System is provided addresses from the HOME LAN 343 via PPP NCP negotiation. Authentication, Authorization and Accounting 344 may be provided by the Home LAN's Management Domain as if the user 345 were connected to a Network Access Server directly. 347 A LAC Client (a Host which runs L2TP natively) may also participate 348 in tunneling to the Home LAN without use of a separate LAC. In this 349 case, the Host containing the LAC Client software already has a 350 connection to the public Internet. A "virtual" PPP connection is then 351 created and the local L2TP LAC Client software creates a tunnel to 352 the LNS. As in the above case, Addressing, Authentication, 353 Authorization and Accounting will be provided by the Home LAN's 354 Management Domain. 356 3.0 Protocol Overview 358 L2TP utilizes two types of messages, control messages and data 359 messages. Control messages are used in the establishment, maintenance 360 and clearing of tunnels and calls. Data messages are used to 361 encapsulate PPP frames being carried over the tunnel. Control 362 messages utilize a reliable Control Channel within L2TP to guarantee 363 delivery (see section 5.1 for details). Data messages are not 364 retransmitted when packet loss occurs. 366 +-------------------+ 367 | PPP Frames | 368 +-------------------+ +-----------------------+ 369 | L2TP Data Messages| | L2TP Control Messages | 370 +-------------------+ +-----------------------+ 371 | L2TP Data Channel | | L2TP Control Channel | 372 | (unreliable) | | (reliable) | 373 +------------------------------------------------+ 374 | Packet Transport (UDP, FR, ATM, etc.) | 375 +------------------------------------------------+ 377 Figure 3.0 L2TP Protocol Structure 379 Figure 3.0 depicts the relationship of PPP frames and Control 380 Messages over the L2TP Control and Data Channels. PPP Frames are 381 passed over an unreliable Data Channel encapsulated first by an L2TP 382 header and then a Packet Transport such as UDP, Frame Relay, ATM, 383 etc. Control messages are sent over a reliable L2TP Control Channel 384 which transmits packets in-band over the same Packet Transport. 386 Sequence numbers are required to be present in all control messages 387 and are used to provide reliable delivery on the Control Channel. 388 Data Messages may use sequence numbers to reorder packets and detect 389 lost packets. 391 All values are placed into their respective fields and sent in 392 network order (high order octets first). 394 3.1 L2TP Header Format 396 L2TP packets for the control channel and data channel share a common 397 header format. In each case where a field is optional, its space does 398 not exist in the message if the field is marked not present. This 399 header is formatted: 401 0 1 2 3 402 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Tunnel ID | Session ID | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Ns (opt) | Nr (opt) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Offset Size (opt) | Offset pad... (opt) 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 3.1 L2TP Message Header 414 The Type (T) bit indicates the type of message. It is set to 0 for a 415 data message and 1 for a control message. 417 If the Length (L) bit is 1, the Length field is present. This bit 418 MUST be set to 1 for control messages. 420 The x bits are reserved for future extensions. All reserved bits MUST 421 be set to 0 on outgoing messages and ignored on incoming messages. 423 If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. 424 The S bit MUST be set to 1 for control messages. 426 If the Offset (O) bit is 1, the Offset Size field is present. The O 427 bit MUST be set to 0 (zero) for control messages. 429 If the Priority (P) bit is 1, this data message should receive 430 preferential treatment in its local queuing and transmission. LCP 431 echo requests used as a keepalive for the link, for instance, should 432 generally be sent with this bit set to 1. Without it, a temporary 433 interval of local congestion could result in interference with 434 keepalive messages and unnecessary loss of the link. This feature is 435 only for use with data messages. The P bit MUST be set to 0 for all 436 control messages. 438 Ver MUST be 2, indicating the version of the L2TP data message header 439 described in this document. The value 1 is reserved to permit 440 detection of L2F [RFC2341] packets should they arrive intermixed with 441 L2TP packets. Packets received with an unknown Ver field MUST be 442 discarded. 444 The Length field indicates the total length of the message in octets. 446 Tunnel ID indicates the identifier for the control connection. L2TP 447 tunnels are named by identifiers that have local significance only. 448 That is, the same tunnel will be given different Tunnel IDs by each 449 end of the tunnel. Tunnel ID in each message is that of the intended 450 recipient, not the sender. Tunnel IDs are selected and exchanged as 451 Assigned Tunnel ID AVPs during the creation of a tunnel. 453 Session ID indicates the identifier for a session within a tunnel. 454 L2TP sessions are named by identifiers that have local significance 455 only. That is, the same session will be given different Session IDs 456 by each end of the session. Session ID in each message is that of the 457 intended recipient, not the sender. Session IDs are selected and 458 exchanged as Assigned Session ID AVPs during the creation of a 459 session. 461 Ns indicates the sequence number for this data or control message, 462 beginning at zero and incrementing by one (modulo 2**16) for each 463 message sent. See Section 5.8 and 5.4 for more information on using 464 this field. 466 Nr indicates the sequence number expected in the next control message 467 to be received. Thus, Nr is set to the Ns of the last in-order 468 message received plus one (modulo 2**16). In data messages, Nr is 469 reserved and, if present (as indicated by the S-bit), MUST be ignored 470 upon receipt. See section 5.8 for more information on using this 471 field in control messages. 473 The Offset Size field, if present, specifies the number of octets 474 past the L2TP header at which the payload data is expected to start. 475 Actual data within the offset padding is undefined. If the offset 476 field is present, the L2TP header ends after the last octet of the 477 offset padding. 479 3.2 Control Message Types 481 The Message Type AVP (see section 4.3.1) defines the specific type of 482 control message being sent. Recall from section 3.1 that this is only 483 for control messages, that is, messages with the T-bit set to 1. 485 This document defines the following control message types (see 486 Section 6.1 through 6.14 for details on the construction and use of 487 each message): 489 Control Connection Management 491 0 (reserved) 493 1 (SCCRQ) Start-Control-Connection-Request 494 2 (SCCRP) Start-Control-Connection-Reply 495 3 (SCCCN) Start-Control-Connection-Connected 496 4 (StopCCN) Stop-Control-Connection-Notification 497 5 (reserved) 498 6 (HELLO) Hello 500 Call Management 502 7 (OCRQ) Outgoing-Call-Request 503 8 (OCRP) Outgoing-Call-Reply 504 9 (OCCN) Outgoing-Call-Connected 505 10 (ICRQ) Incoming-Call-Request 506 11 (ICRP) Incoming-Call-Reply 507 12 (ICCN) Incoming-Call-Connected 508 13 (reserved) 509 14 (CDN) Call-Disconnect-Notify 511 Error Reporting 513 15 (WEN) WAN-Error-Notify 515 PPP Session Control 517 16 (SLI) Set-Link-Info 519 4.0 Control Message Attribute Value Pairs 521 To maximize extensibility while still permitting interoperability, a 522 uniform method for encoding message types and bodies is used 523 throughout L2TP. This encoding will be termed AVP (Attribute-Value 524 Pair) in the remainder of this document. 526 4.1 AVP Format 528 Each AVP is encoded as: 530 0 1 2 3 531 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 |M|H| rsvd | Length | Vendor ID | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Attribute Type | Attribute Value... 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 [until Length is reached]... | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 The first six bits are a bit mask, describing the general attributes 541 of the AVP. 543 Two bits are defined in this document, the remaining are reserved for 544 future extensions. Reserved bits MUST be set to 0. An AVP received 545 with a reserved bit set to 1 MUST be treated as an unrecognized AVP. 547 Mandatory (M) bit: Controls the behavior required of an 548 implementation which receives an AVP which it does not recognize. If 549 the M bit is set on an unrecognized AVP within a message associated 550 with a particular session, the session associated with this message 551 MUST be terminated. If the M bit is set on an unrecognized AVP within 552 a message associated with the overall tunnel, the entire tunnel (and 553 all sessions within) MUST be terminated. If the M bit is not set, an 554 unrecognized AVP MUST be ignored. The control message must then 555 continue to be processed as if the AVP had not been present. 557 Hidden (H) bit: Identifies the hiding of data in the Attribute Value 558 field of an AVP. This capability can be used to avoid the passing of 559 sensitive data, such as user passwords, as cleartext in an AVP. 560 Section 4.2 describes the procedure for performing AVP hiding. 562 Length: Encodes the number of octets (including the Overall Length 563 and bitmask fields) contained in this AVP. The Length may be 564 calculated as 6 + the length of the Attribute Value field in octets. 565 The field itself is 10 bits, permitting a maximum of 1023 octets of 566 data in a single AVP. The minimum Length of an AVP is 6. If the 567 length is 6, then the Attribute Value field is absent. 569 Vendor ID: The IANA assigned "SMI Network Management Private 570 Enterprise Codes" [RFC1700] value. The value 0, corresponding to 571 IETF adopted attribute values, is used for all AVPs defined within 572 this document. Any vendor wishing to implement their own L2TP 573 extensions can use their own Vendor ID along with private Attribute 574 values, guaranteeing that they will not collide with any other 575 vendor's extensions, nor with future IETF extensions. Note that there 576 are 16 bits allocated for the Vendor ID, thus limiting this feature 577 to the first 65,535 enterprises. 579 Attribute Type: A 2 octet value with a unique interpretation across 580 all AVPs defined under a given Vendor ID. 582 Attribute Value: This is the actual value as indicated by the Vendor 583 ID and Attribute Type. It follows immediately after the Attribute 584 Type field, and runs for the remaining octets indicated in the Length 585 (i.e., Length minus 6 octets of header). This field is absent if the 586 Length is 6. 588 4.2 Hiding of AVP Attribute Values 590 The H bit in the header of each AVP provides a mechanism to indicate 591 to the receiving peer whether the contents of the AVP are hidden or 592 present in cleartext. This feature can be used to hide sensitive 593 control message data such as user passwords or user IDs. 595 The H bit MUST only be set if a shared secret exists between the LAC 596 and LNS. The shared secret is the same secret that is used for tunnel 597 authentication (see Section 5.1.1). If the H bit is set in any 598 AVP(s) in a given control message, a Random Vector AVP must also be 599 present in the message and MUST precede the first AVP having an H bit 600 of 1. 602 Hiding an AVP value is done in several steps. The first step is to 603 take the length and value fields of the original (cleartext) AVP and 604 encode them into a Hidden AVP Subformat as follows: 606 0 1 2 3 607 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Length of Original Value | Original Attribute Value ... 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 ... | Padding ... 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Length of Original Attribute Value: This is length of the Original 615 Attribute Value to be obscured in octets. This is necessary to 616 determine the original length of the Attribute Value which is lost 617 when the additional Padding is added. 619 Original Attribute Value: Attribute Value that is to be obscured. 621 Padding: Random additional octets used to obscure length of the 622 Attribute Value that is being hidden. 624 To mask the size of the data being hidden, the resulting subformat 625 MAY be padded as shown above. Padding does NOT alter the value placed 626 in the Length of Original Attribute Value field, but does alter the 627 length of the resultant AVP that is being created. For example, If an 628 Attribute Value to be hidden is 4 octets in length, the unhidden AVP 629 length would be 10 octets (6 + Attribute Value length). After hiding, 630 the length of the AVP will become 6 + Attribute Value length + size 631 of the Length of Original Attribute Value field + Padding. Thus, if 632 Padding is 12 octects, the AVP length will be 6 + 4 + 2 + 12 = 24 633 octets. 635 Next, An MD5 hash is performed on the concatenation of: 637 + the 2 octet Attribute number of the AVP 638 + the shared secret 639 + an arbitrary length random vector 641 The value of the random vector used in this hash is passed in the 642 value field of a Random Vector AVP. This Random Vector AVP must be 643 placed in the message by the sender before any hidden AVPs. The same 644 random vector may be used for more than one hidden AVP in the same 645 message. If a different random vector is used for the hiding of 646 subsequent AVPs then a new Random Vector AVP must be placed in the 647 command message before the first AVP to which it applies. 649 The MD5 hash value is then XORed with the first 16 octet (or less) 650 segment of the Hidden AVP Subformat and placed in the Attribute Value 651 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 652 octets, the Subformat is transformed as if the Attribute Value field 653 had been padded to 16 octets before the XOR, but only the actual 654 octets present in the Subformat are modified, and the length of the 655 AVP is not altered. 657 If the Subformat is longer than 16 octets, a second one-way MD5 hash 658 is calculated over a stream of octets consisting of the shared secret 659 followed by the result of the first XOR. That hash is XORed with the 660 second 16 octet (or less) segment of the Subformat and placed in the 661 corresponding octets of the Value field of the Hidden AVP. 663 If necessary, this operation is repeated, with the shared secret used 664 along with each XOR result to generate the next hash to XOR the next 665 segment of the value with. 667 The hiding method was adapted from RFC 2138 [RFC2138] which was taken 668 from from the "Mixing in the Plaintext" section in the book "Network 669 Security" by Kaufman, Perlman and Speciner [KPS]. A detailed 670 explanation of the method follows: 672 Call the shared secret S, the Random Vector RV, and the Attribute 673 Value AV. Break the value field into 16-octet chunks p1, p2, etc. 674 with the last one padded at the end with random data to a 16-octet 675 boundary. Call the ciphertext blocks c(1), c(2), etc. We will also 676 define intermediate values b1, b2, etc. 678 b1 = MD5(AV + S + RV) c(1) = p1 xor b1 679 b2 = MD5(S + c(1)) c(2) = p2 xor b2 680 . . 681 . . 682 . . 683 bi = MD5(S + c(i-1)) c(i) = pi xor bi 685 The String will contain c(1)+c(2)+...+c(i) where + denotes 686 concatenation. 688 On receipt, the random vector is taken from the last Random Vector 689 AVP encountered in the message prior to the AVP to be unhidden. The 690 above process is then reversed to yield the original value. 692 4.3 AVP Summary 694 The following sections contain a list of all L2TP AVPs defined in 695 this document. 697 Following the name of the AVP is a list indicating the message types 698 that utilize each AVP. After each AVP title follows a short 699 description of the purpose of the AVP, a detail (including a graphic) 700 of the format for the Attribute Value, and any additional information 701 needed for proper use of the avp. 703 4.3.1 AVPs Applicable To All Control Messages 705 Message Type (All Messages) 707 The Message Type AVP, Attribute Type 0, identifies the control 708 message herein and defines the context in which the exact meaning 709 of the following AVPs will be determined. 711 The Attribute Value field for this AVP has the following format: 713 0 1 714 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Message Type | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 The Message Type is a 2 octet unsigned integer. 721 The Message Type AVP MUST be the first AVP in a message, 722 immediately following the control message header (defined in 723 section 3.1). See Section 3.2 for the list of defined control 724 message types and their identifiers. 726 The Mandatory (M) bit within the Message Type AVP has special 727 meaning. Rather than an indication as to whether the AVP itself 728 should be ignored if not recognized, it is an indication as to 729 whether the control message itself should be ignored. Thus, if the 730 M-bit is set within the Message Type AVP and the Message Type is 731 unknown to the implementation, the tunnel MUST be cleared. If the 732 M-bit is not set, then the implementation may ignore an unknown 733 message type. The M-bit MUST be set to 1 for all message types 734 defined in this document. This AVP may not be hidden (the H-bit 735 MUST be 0). The Length of this AVP is 8. 737 Random Vector (All Messages) 739 The Random Vector AVP, Attribute Type 36, is used to enable the 740 hiding of the Attribute Value of arbitrary AVPs. 742 The Attribute Value field for this AVP has the following format: 744 0 1 2 3 745 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Random Octet String ... 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 The Random Octet String may be of arbitrary length, although a 751 random vector of at least 16 octets is recommended. The string 752 contains the random vector for use in computing the MD5 hash to 753 retrieve or hide the Attribute Value of a hidden AVP (see Section 754 4.2). 756 More than one Random Vector AVP may appear in a message, in which 757 case a hidden AVP uses the Random Vector AVP most closely 758 preceeding it. This AVP MUST precede the first AVP with the H bit 759 set. 761 The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be 762 hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the 763 length of the Random Octet String. 765 4.3.2 Result and Error Codes 767 Result Code (CDN, StopCCN) 769 The Result Code AVP, Attribute Type 1, indicates the reason for 770 terminating the control channel or session. 772 The Attribute Value field for this AVP has the following format: 774 0 1 2 3 775 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Result Code | Error Code (opt) | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Error Message (opt) ... 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 The Result Code is a 2 octet unsigned integer. The optional Error 783 Code is a 2 octet unsigned integer. An optional Error Message can 784 follow the Error Code field. Presence of the Error Code and 785 Message are indicated by the AVP Length field. The Error Message 786 contains an arbitrary string providing further (human readable) 787 text associated with the condition. Human readable text in all 788 error messages MUST be provided in the UTF-8 charset using the 789 Default Language [RFC2277]. 791 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 792 this AVP MUST be set to 1. The Length is 8 if there is no Error 793 Code or Message, 10 if there is an Error Code and no Error Message 794 or 10 + the length of the Error Message if there is an Error Code 795 and Message. 797 Defined Result Code values for the StopCCN message are: 799 0 - Reserved 800 1 - General request to clear control connection 801 2 - General error--Error Code indicates the problem 802 3 - Control channel already exists 803 4 - Requester is not authorized to establish a control channel 804 5 - The protocol version of the requester is not supported 805 Error Code indicates highest version supported 806 6 - Requester is being shut down 807 7 - Finite State Machine error 809 Defined Result Code values for the CDN message are: 811 0 - Reserved 812 1 - Call disconnected due to loss of carrier 813 2 - Call disconnected for the reason indicated 814 in error code 815 3 - Call disconnected for administrative reasons 816 4 - Call failed due to lack of appropriate facilities being 817 available (temporary condition) 818 5 - Call failed due to lack of appropriate facilities being 819 available (permanent condition) 820 6 - Invalid destination 821 7 - Call failed due to no carrier detected 822 8 - Call failed due to detection of a busy signal 823 9 - Call failed due to lack of a dial tone 824 10 - Call was not established within time allotted by LAC 825 11 - Call was connected but no appropriate framing was detected 827 The Error Codes defined below pertain to types of errors that are 828 not specific to any particular L2TP request, but rather to 829 protocol or message format errors. If an L2TP reply indicates in 830 its Result Code that a general error occurred, the General Error 831 value should be examined to determine what the error was. The 832 currently defined General Error codes and their meanings are: 834 0 - No general error 835 1 - No control connection exists yet for this LAC-LNS pair 836 2 - Length is wrong 837 3 - One of the field values was out of range or 838 reserved field was non-zero 839 4 - Insufficient resources to handle this operation now 840 5 - The Session ID is invalid in this context 841 6 - A generic vendor-specific error occurred in the LAC 842 7 - Try another. If LAC is aware of other possible LNS 843 destinations, it should try one of them. This can be 844 used to guide an LAC based on LNS policy, for instance, 845 the existence of multilink PPP bundles. 847 When a General Error Code of 6 is used, additional information 848 about the error SHOULD be included in the Error Message field. 850 4.3.3 Control Connection Management AVPs 852 Protocol Version (SCCRP, SCCRQ) 854 The Protocol Version AVP, Attribute Type 2, indicates the L2TP 855 protocol version of the sender. 857 The Attribute Value field for this AVP has the following format: 859 0 1 860 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Ver | Rev | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 The Ver field is a 1 octet unsigned integer containing the value 866 1. Rev field is a 1 octet unsigned integer containing 0. This 867 pertains to L2TP protocol version 1, revision 0. Note this is not 868 the same version number that is included in the header of each 869 message. 871 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 872 this AVP MUST be set to 1. The Length of this AVP is 8. 874 Framing Capabilities (SCCRP, SCCRQ) 876 The Framing Capabilities AVP, Attribute Type 3, provides the peer 877 with an indication of the types of framing that will be accepted 878 or requested by the sender. 880 The Attribute Value field for this AVP has the following format: 882 0 1 2 3 883 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Reserved for future framing type definitions |A|S| 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 The Attribute Value field is a 32-bit mask, with two bits defined. 889 If bit A is set, asynchronous framing is supported. If bit S is 890 set, synchronous framing is supported. 892 A peer MUST NOT request an incoming or outgoing call with a 893 Framing Type AVP specifying a value not advertised in the Framing 894 Capabilities AVP it received during control connection 895 establishment. Attempts to do so will result in the call being 896 rejected. 898 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 899 this AVP MUST be set to 1. The Length (before hiding) is 10. 901 Bearer Capabilities (SCCRP, SCCRQ) 903 The Bearer Capabilities AVP, Attribute Type 4, provides the peer 904 with an indication of the bearer device types supported by the 905 hardware interfaces of the sender for outgoing calls. 907 The Attribute Value field for this AVP has the following format: 909 0 1 2 3 910 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Reserved for future bearer type definitions |A|D| 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 This is a 32-bit mask, with two bits defined. If bit A is set, 916 analog access is supported. If bit D is set, digital access is 917 supported. 919 An LNS should not request an outgoing call specifying a value in 920 the Bearer Type AVP for a device type not advertised in the Bearer 921 Capabilities AVP it received from the LAC during control 922 connection establishment. Attempts to do so will result in the 923 call being rejected. 925 This AVP MUST be present if the sender can place outgoing calls 926 when requested. 928 Note that an LNS that cannot act as an LAC as well will not 929 support hardware devices for handling incoming and outgoing calls 930 and should therefore set the A and D bits of this AVP to 0, or 931 should not send the AVP at all. An LNS that can also act as an LAC 932 and place outgoing calls should set A or D as appropriate. 933 Presence of this message is not a guarantee that a given outgoing 934 call will be placed by the sender if requested, just that the 935 physical capability exists. 937 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 938 this AVP MUST be set to 1. The Length (before hiding) is 10. 940 Tie Breaker (SCCRQ) 942 The Tie Breaker AVP, Attribute Type 5, indicates that the sender 943 wishes a single tunnel to exist between the given LAC-LNS pair. 945 The Attribute Value field for this AVP has the following format: 947 0 1 2 3 948 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Tie Break Value... 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 ...(64 bits) | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 The Tie Breaker Value is an 8 octet value that is used to choose a 956 single tunnel where both LAC and LNS request a tunnel 957 concurrently. The recipient of a SCCRQ must check to see if a 958 SCCRQ has been sent to the peer, and if so, must compare its Tie 959 Breaker value with the received one. The lower value "wins", and 960 the "loser" MUST silently discard its tunnel. In the case where a 961 tie breaker is present on both sides, and the value is equal, both 962 sides MUST discard their tunnels. 964 If a tie breaker is received, and an outstanding SCCRQ had no tie 965 breaker value, the initiator which included the Tie Breaker AVP 966 "wins". If neither side issues a tie breaker, then two separate 967 tunnels are opened. 969 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 970 this AVP MUST be set to 0. The Length of this AVP is 14. 972 Firmware Revision (SCCRP, SCCRQ) 974 The Firmware Revision AVP, Attribute Type 6, indicates the 975 firmware revision of the issuing device. 977 The Attribute Value field for this AVP has the following format: 979 0 1 980 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Firmware Revision | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 The Firmware Revision is a 2 octet unsigned integer encoded in a 986 vendor specific format. 988 For devices which do not have a firmware revision (general purpose 989 computers running L2TP software modules, for instance), the 990 revision of the L2TP software module may be reported instead. 992 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 993 this AVP MUST be set to 0. The Length (before hiding) is 8. 995 Host Name (SCCRP, SCCRQ) 997 The Host Name AVP, Attribute Type 7, indicates the name of the 998 issuing LAC or LNS. 1000 The Attribute Value field for this AVP has the following format: 1002 0 1 2 3 1003 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Host Name ... (arbitrary number of octets) 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 The Host Name is of arbitrary length, but MUST be at least 1 1009 octet. 1011 This name should be as broadly unique as possible; for hosts 1012 participating in DNS [RFC1034], a hostname with fully qualified 1013 domain would be appropriate. 1015 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1016 this AVP MUST be set to 1. The Length of this AVP is 6 plus the 1017 length of the Host Name. 1019 Vendor Name (SCCRP, SCCRQ) 1021 The Vendor Name AVP, Attribute Type 8, contains a vendor specific 1022 (possibly human readable) string describing the type of LAC or LNS 1023 being used. 1025 The Attribute Value field for this AVP has the following format: 1027 0 1 2 3 1028 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Vendor Name ...(arbitrary number of octets) 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 The Vendor Name is the indicated number of octets representing the 1034 vendor string. Human readable text for this AVP MUST be provided 1035 in the UTF-8 charset using the Default Language [RFC2277]. 1037 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1038 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1039 is 6 plus the length of the Vendor Name. 1041 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 1043 The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being 1044 assigned to this tunnel by the sender. 1046 The Attribute Value field for this AVP has the following format: 1048 0 1 1049 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Assigned Tunnel ID | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 The Assigned Tunnel ID is a 2 octet non-zero unsigned integer. 1056 The Assigned Tunnel ID AVP establishes a value used to multiplex 1057 and demultiplex multiple tunnels between the LNS and LAC. The L2TP 1058 peer MUST place this value in the Tunnel ID header field of all 1059 control and data messages that it subsequently transmits over the 1060 associated tunnel. Before the Assigned Tunnel ID AVP is received 1061 from a peer, messages MUST be sent to that peer with a Tunnel ID 1062 value of 0 in the header of all control messages. 1064 In the StopCCN control message, the Assigned Tunnel ID AVP MUST be 1065 the same as the Assigned Tunnel ID AVP first sent to the receiving 1066 peer, permitting the peer to identify the appropriate tunnel even 1067 if StopCCN is sent before an Assigned Tunnel ID AVP is received. 1069 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1070 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1071 is 8. 1073 Receive Window Size (SCCRQ, SCCRP) 1075 The Receive Window Size AVP, Attribute Type 10, specifies the 1076 receive window size being offered to the remote peer. 1078 The Attribute Value field for this AVP has the following format: 1080 0 1 1081 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Window Size | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 The Window Size is a 2 octet unsigned integer. 1088 If absent, the peer must assume a Window Size of 4 for its 1089 transmit window. The remote peer may send the specified number of 1090 control messages before it must wait for an acknowledgment. 1092 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1093 this AVP MUST be set to 0. The Length of this AVP is 8. 1095 Challenge (SCCRP, SCCRQ) 1097 The Challenge AVP, Attribute Type 11, indicates that the issuing 1098 peer wishes to authenticate the tunnel endpoints using a CHAP- 1099 style authentication mechanism. 1101 The Attribute Value field for this AVP has the following format: 1103 0 1 2 3 1104 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Challenge ... (arbitrary number of octets) 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 The Challenge is one or more octets of random data. 1111 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1112 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1113 is 6 plus the length of the Challenge. 1115 Challenge Response (SCCCN, SCCRP) 1117 The Response AVP, Attribute Type 13, provides a response to a 1118 challenge received. 1120 The Attribute Value field for this AVP has the following format: 1122 0 1 2 3 1123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Response ... 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 ... (16 octets) | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 The Response is a 16 octet value reflecting the CHAP-style 1135 [RFC1994] response to the challenge. 1137 This AVP MUST be present in an SCCRP or SCCCN if a challenge was 1138 received in the preceeding SCCRQ or SCCRP. For purposes of the ID 1139 value in the CHAP response calculation, the value of the Message 1140 Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for 1141 an SCCCN). 1143 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1144 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1145 is 22. 1147 4.3.4 Call Management AVPs 1149 Q.931 Cause Code (CDN) 1151 The Q.931 Cause Code AVP, Attribute Type 12, is used to give 1152 additional information in case of unsolicited call disconnection. 1154 The Attribute Value field for this AVP has the following format: 1156 0 1 2 3 1157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Cause Code | Cause Msg | Advisory Msg... 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 Cause Code is the returned Q.931 Cause code, and Cause Msg is the 1163 returned Q.931 message code (e.g., DISCONNECT) associated with the 1164 Cause Code. Both values are returned in their native ITU 1165 encodings [DSS1]. An additional ASCII text Advisory Message may 1166 also be included (presence indicated by the AVP Length) to further 1167 explain the reason for disconnecting. 1169 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1170 this AVP MUST be set to 1. The Length of this AVP is 9, plus the 1171 size of the Advisory Message. 1173 Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) 1175 The Assigned Session ID AVP, Attribute Type 14, encodes the ID 1176 being assigned to this session by the sender. 1178 The Attribute Value field for this AVP has the following format: 1180 0 1 1181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Assigned Session ID | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 The Assigned Session ID is a 2 octet non-zero unsigned integer. 1187 The Assigned Session ID AVP is establishes a value used to 1188 multiplex and demultiplex data sent over a tunnel between the LNS 1189 and LAC. The L2TP peer MUST place this value in the Session ID 1190 header field of all control and data messages that it subsequently 1191 transmits over the tunnel that belong to this session. Before the 1192 Assigned Session ID AVP is received from a peer, messages MUST be 1193 sent to that peer with a Session ID of 0 in the header of all 1194 control messages. 1196 In the CDN control message, the same Assigned Session ID AVP first 1197 sent to the receiving peer is used, permitting the peer to 1198 identify the appropriate tunnel even if CDN is sent before an 1199 Assigned Session ID is received. 1201 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1202 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1203 is 8. 1205 Call Serial Number (ICRQ, OCRQ) 1207 The Call Serial Number AVP, Attribute Type 15, encodes an 1208 identifier assigned by the LAC or LNS to this call. 1210 The Attribute Value field for this AVP has the following format: 1212 0 1 2 3 1213 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Call Serial Number | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 The Call Serial Number is a 32 bit value. 1220 The Call Serial Number is intended to be an easy reference for 1221 administrators on both ends of a tunnel to use when investigating 1222 call failure problems. Call Serial Numbers should be set to 1223 progressively increasing values, which are likely to be unique for 1224 a significant period of time across all interconnected LNSs and 1225 LACs. 1227 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1228 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1229 is 10. 1231 Minimum BPS (OCRQ) 1232 The Minimum BPS AVP, Attribute Type 16, encodes the lowest 1233 acceptable line speed for this call. 1235 The Attribute Value field for this AVP has the following format: 1237 0 1 2 3 1238 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Minimum BPS | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 The Minimum BPS is a 32 bit value indicates the speed in bits per 1244 second. 1246 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1247 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1248 is 10. 1250 Maximum BPS (OCRQ) 1252 The Maximum BPS AVP, Attribute Type 17, encodes the highest 1253 acceptable line speed for this call. 1255 The Attribute Value field for this AVP has the following format: 1257 0 1 2 3 1258 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Maximum BPS | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 The Maximum BPS is a 32 bit value indicates the speed in bits per 1264 second. 1266 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1267 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1268 is 10. 1270 Bearer Type (ICRQ, OCRQ) 1272 The Bearer Type AVP, Attribute Type 18, encodes the bearer type 1273 for the incoming or outgoing call. 1275 The Attribute Value field for this AVP has the following format: 1277 0 1 2 3 1278 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Reserved for future Bearer Types |A|D| 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 The Bearer Type is a 32-bit bit mask, which indicates the bearer 1284 capability of the call (ICRQ) or required for the call (OCRQ). If 1285 set, bit A indicates that the call refers to an analog channel. If 1286 set, bit D indicates that the call refers to a digital channel. 1287 Both may be set, indicating that the call was either 1288 indistinguishable, or can be placed on either type of channel. 1290 Bits in the Value field of this AVP MUST only be set by the LNS 1291 for an OCRQ if it was set in the Bearer Capabilities AVP received 1292 from the LAC during control connection establishment. 1294 It is valid to set neither the A nor D bits in an ICRQ. Such a 1295 setting may indicate that the call was not received over a 1296 physical link (e.g if the LAC and PPP are located in the same 1297 subsystem). 1299 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1300 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1301 is 10. 1303 Framing Type (ICCN, OCCN, OCRQ) 1305 The Framing Type AVP, Attribute Type 19, encodes the framing type 1306 for the incoming or outgoing call. 1308 The Attribute Value field for this AVP has the following format: 1310 0 1 2 3 1311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Reserved for future Framing Types |A|S| 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 The Framing Type is a 32-bit mask, which indicates the type of PPP 1317 framing requested for an OCRQ, or the type of PPP framing 1318 negotiated for an OCCN or ICCN. The framing type MAY be used as an 1319 indication to PPP on the LNS as to what link options to use for 1320 LCP negotiation [RFC1662]. 1322 Bit A indicates that asynchronous framing. Bit S indicates that 1323 synchronous framing. For an OCRQ, both may be set, indicating that 1324 either type of framing may be used. 1326 Bits in the Value field of this AVP MUST only be set by the LNS 1327 for an OCRQ if it was set in the Framing Capabilities AVP received 1328 from the LAC during control connection establishment. 1330 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1331 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1332 is 10. 1334 Called Number (ICRQ, OCRQ) 1336 The Called Number AVP, Attribute Type 21, encodes the telephone 1337 number to be called for an OCRQ, and the Called number for an 1338 ICRQ. 1340 The Attribute Value field for this AVP has the following format: 1342 0 1 2 3 1343 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Called Number... (arbitrary number of octets) | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 The Called Number is an ASCII string. Contact between the 1349 administrator of the LAC and the LNS may be necessary to 1350 coordinate interpretation of the value needed in this AVP. 1352 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1353 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1354 is 6 plus the length of the Called Number. 1356 Calling Number (ICRQ) 1358 The Calling Number AVP, Attribute Type 22, encodes the originating 1359 number for the incoming call. 1361 The Attribute Value field for this AVP has the following format: 1363 0 1 2 3 1364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | Calling Number... (arbitrary number of octets) | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 Calling Number is an ASCII string. Contact between the 1370 administrator of the LAC and the LNS may be necessary to 1371 coordinate interpretation of the value in this AVP. 1373 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1374 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1375 is 6 plus the length of the Calling Number. 1377 Sub-Address (ICRQ, OCRQ) 1379 The Sub-Address AVP, Attribute Type 23, encodes additional dialing 1380 information. 1382 The Attribute Value field for this AVP has the following format: 1384 0 1 2 3 1385 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Sub-Address ... (arbitrary number of octets) | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 The Sub-Address is an ASCII string. Contact between the 1391 administrator of the LAC and the LNS may be necessary to 1392 coordinate interpretation of the value in this AVP. 1394 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1395 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1396 is 6 plus the length of the Sub-Address. 1398 (Tx) Connect Speed (ICCN, OCCN) 1400 The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the 1401 speed of the facility chosen for the connection attempt. 1403 The Attribute Value field for this AVP has the following format: 1405 0 1 2 3 1406 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | BPS | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 The (Tx) Connect Speed BPS is a 4 octet value indicating the speed 1412 in bits per second. 1414 When the optional Rx Connect Speed AVP is present, the value in 1415 this AVP represents the transmit connect speed, from the 1416 perspective of the LAC (e.g. data flowing from the LAC to the 1417 remote system). When the optional Rx Connect Speed AVP is NOT 1418 present, the connection speed between the remote system and LAC is 1419 assumed to be symmetric and is represented by the single value in 1420 this AVP. 1422 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1423 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1424 is 10. 1426 Physical Channel ID (ICRQ, OCRP) 1428 The Physical Channel ID AVP, Attribute Type 25, encodes the vendor 1429 specific physical channel number used for a call. 1431 The Attribute Value field for this AVP has the following format: 1433 0 1 2 3 1434 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Physical Channel ID | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 Physical Channel ID is a 4 octet value intended to be used for 1440 logging purposes only. 1442 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1443 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1444 is 10. 1446 4.3.5 Proxy LCP and Authentication AVPs 1448 The LAC may have answered the call and negotiated LCP with the remote 1449 system, perhaps in order to establish the system's apparent identity. 1450 In this case, these AVPs may be included to indicate the link 1451 properties the remote system initially requested, properties the 1452 remote system and LAC ultimately negotiated, as well as PPP 1453 authentication information sent and received by the LAC. This 1454 information may be used to initiate the PPP LCP and authentication 1455 systems on the LNS, allowing PPP to continue without renegotiation of 1456 LCP. Note that the LNS policy may be to enter an additional round of 1457 LCP negotiation and/or authentication if the LAC is not trusted. 1459 Initial Received LCP CONFREQ (ICCN) 1461 In the Initial Received LCP CONFREQ AVP, Attribute Type 26, 1462 provides the LNS with the Initial CONFREQ received by the LAC from 1463 the PPP Peer. 1465 The Attribute Value field for this AVP has the following format: 1467 0 1 2 3 1468 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | LCP CONFREQ... (arbitrary number of octets) | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 LCP CONFREQ is a copy of the body of the initial CONFREQ received, 1474 starting at the first option within the body of the LCP message. 1476 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1477 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1478 is 6 plus the length of the CONFREQ. 1480 Last Sent LCP CONFREQ (ICCN) 1482 In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the 1483 LNS with the Last CONFREQ sent by the LAC to the PPP Peer. 1485 The Attribute Value field for this AVP has the following format: 1487 0 1 2 3 1488 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | LCP CONFREQ... (arbitrary number of octets) | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 The LCP CONFREQ is a copy of the body of the final CONFREQ sent to 1494 the client to complete LCP negotiation, starting at the first 1495 option within the body of the LCP message. 1497 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1498 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1499 is 6 plus the length of the CONFREQ. 1501 Last Received LCP CONFREQ (ICCN) 1503 The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the 1504 LNS with the Last CONFREQ received by the LAC from the PPP Peer. 1506 The Attribute Value field for this AVP has the following format: 1508 0 1 2 3 1509 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | LCP CONFREQ... (arbitrary number of octets) | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 The LCP CONFREQ is a copy of the body of the final CONFREQ 1515 received from the client to complete LCP negotiation, starting at 1516 the first option within the body of the LCP message. 1518 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1519 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1520 is 6 plus the length of the CONFREQ. 1522 Proxy Authen Type (ICCN) 1524 The Proxy Authen Type AVP, Attribute Type 29, determines if proxy 1525 authentication should be used. 1527 The Attribute Value field for this AVP has the following format: 1529 0 1 1530 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Authen Type | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 Authen Type is a 2 octet unsigned integer, holding: 1537 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1538 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1539 is 8. 1541 Defined Authen Type values are: 1542 0 - Reserved 1543 1 - Textual username/password exchange 1544 2 - PPP CHAP 1545 3 - PPP PAP 1546 4 - No Authentication 1547 5 - Microsoft CHAP Version 1 (MSCHAPv1) 1549 This AVP MUST be present if proxy authentication is to be 1550 utilized. If it is not present, then it is assumed that this 1551 peer cannot perform proxy authentication, requiring 1552 a restart of the authentication phase at the LNS if the client 1553 has already entered this phase with the 1554 LAC (which may be determined by the Proxy LCP AVP if present).. 1556 Associated AVPs for each type of authentication follow. 1558 Proxy Authen Name (ICCN) 1560 The Proxy Authen Name AVP, Attribute Type 30, specifies the name 1561 of the authenticating client when using proxy authentication. 1563 The Attribute Value field for this AVP has the following format: 1565 0 1 2 3 1566 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Authen Name... (arbitrary number of octets) | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 Authen Name is a string of octets of arbitrary length. It 1572 contains the name specified in the client's authentication 1573 response. 1575 This AVP MUST be present in messages containing a Proxy Authen 1576 Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable 1577 to employ AVP hiding for obscuring the cleartext name. 1579 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1580 this AVP MUST be set to 0. The Length (before hiding) is 6 plus 1581 the length of the cleartext name. 1583 Proxy Authen Challenge (ICCN) 1585 The Proxy Authen Challenge AVP, Attribute Type 31, specifies the 1586 challenge sent by the LAC to the PPP Peer, when using proxy 1587 authentication. 1589 The Attribute Value field for this AVP has the following format: 1591 0 1 2 3 1592 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | Challenge... (arbitrary number of octets) | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 The Challenge is a string of one or more octets. 1599 This AVP MUST be present for Proxy Authen Types 2 and 5. The 1600 Challenge field contains the CHAP challenge presented to the 1601 client by the LAC. 1603 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1604 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1605 is 6, plus the length of the Challenge. 1607 Proxy Authen ID (ICCN) 1609 The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value 1610 of the PPP Authentication that was started between the LAC and the 1611 PPP Peer, when proxy authentication is being used. 1613 The Attribute Value field for this AVP has the following format: 1615 0 1 1616 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Reserved | ID | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 ID is a 2 octet unsigned integer, the most significant octet MUST 1622 be 0. 1624 The Proxy Authen ID AVP MUST be present for Proxy authen types 2, 1625 3 and 5. For 2 and 5, the ID field contains the byte ID value 1626 presented to the client by the LAC in its Challenge. For 3, it is 1627 the Identifier value of the Authenticate-Request. 1629 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1630 this AVP MUST be set to 0. 1632 Proxy Authen Response (ICCN) 1634 The Proxy Authen Response AVP, Attribute Type 33, specifies the 1635 PPP Authentication response received by the LAC from the PPP Peer, 1636 when proxy authentication is used. 1638 The Attribute Value field for this AVP has the following format: 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 | Response... (arbitrary number of octets) | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 The Response is a string of octets. 1648 This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The 1649 Response field contains the client's response to the challenge. 1650 For Proxy authen types 2 and 5, this field contains the response 1651 value received by the LAC. For types 1 or 3, it contains the clear 1652 text password received from the client by the LAC. In the case of 1653 cleartext passwords, AVP hiding is recommended. 1655 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1656 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1657 is 6 plus the length of the Response. 1659 4.3.6 Call Status AVPs 1661 Call Errors (WEN) 1663 The Call Errors AVP, Attribute Type 34, is used by the LAC to send 1664 error information to the LNS. 1666 The Attribute Value field for this AVP has the following format: 1668 0 1 2 3 1669 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 | Reserved | CRC Errors (H) | 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | CRC Errors (L) | Framing Errors (H) | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Framing Errors (L) | Hardware Overruns (H) | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Hardware Overruns (L) | Buffer Overruns (H) | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | Buffer Overruns (L) | Time-out Errors (H) | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | Time-out Errors (L) | Alignment Errors (H) | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Alignment Errors (L) | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 The following fields are defined: 1688 Reserved - Not used, MUST be 0 1689 CRC Errors - Number of PPP frames received with CRC errors 1690 since call was established 1691 Framing Errors - Number of improperly framed PPP packets 1692 received 1693 Hardware Overruns - Number of receive buffer over-runs since 1694 call was established 1695 Buffer Overruns - Number of buffer over-runs detected since 1696 call was established 1697 Time-out Errors - Number of time-outs since call was 1698 established 1699 Alignment Errors - Number of alignment errors since call was 1700 established 1702 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this 1703 AVP MUST be set to 1. The Length (before hiding) of this AVP is 32. 1705 ACCM (SLI) 1706 The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC 1707 of the ACCM negotiated with the PPP Peer by the LNS. 1709 The Attribute Value field for this AVP has the following format: 1711 0 1 2 3 1712 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | Reserved | Send ACCM (H) | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | Send ACCM (L) | Receive ACCM (H) | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Receive ACCM (H) | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 Send ACCM and Receive ACCM are each 4 octet values preceeded by a 1722 2 octet reserved quantity. The send ACCM value should be used by 1723 the LAC to process packets it sends on the connection. The receive 1724 ACCM value should be used by the LAC to process incoming packets 1725 on the connection. The default values used by the LAC for both 1726 these fields are 0xFFFFFFFF. The LAC should honor these fields 1727 unless it has specific configuration information to indicate that 1728 the requested mask must be modified to permit operation. 1730 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1731 this AVP MUST be set to 1. The Length of this AVP is 16. 1733 Private Group ID (ICCN) 1735 The Private Group ID AVP, Attribute Type 37, is used by the LAC to 1736 indicate that this call is to be associated with a particular 1737 customer group. 1739 The Attribute Value field for this AVP has the following format: 1741 0 1 2 3 1742 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | Private Group ID ... (arbitrary number of octets) | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 The Private Group ID is a string of octets of arbitrary length. 1749 The LNS MAY treat the PPP session as well as network traffic 1750 through this session in a special manner determined by the peer. 1751 For example, if the LNS is individually connected to several 1752 private networks using unregistered addresses, this AVP may be 1753 included by the LAC to indicate that a given call should be 1754 associated with one of the private networks. 1756 The Private Group ID is a string corresponding to a table in the 1757 LNS that defines the particular characteristics of the selected 1758 group. A LAC MAY determine the Private Group ID from a RADIUS 1759 response, local configuration, or some other source. 1761 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1762 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1763 is 6 plus the length of the Private Group ID. 1765 Rx Connect Speed (ICCN, OCCN) 1767 The Rx Connect Speed AVP, Attribute Type 38, represents the speed 1768 of the connection from the perspective of the LAC (e.g. data 1769 flowing from the remote system to the LAC). 1771 The Attribute Value field for this AVP has the following format: 1773 0 1 2 3 1774 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | BPS (H) | BPS (L) | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 BPS is a 4 octet value indicating the speed in bits per second. 1781 Presence of this AVP implies that the connection speed may be 1782 asymmetric with respect to the transmit connect speed given in the 1783 (Tx) Connect Speed AVP. 1785 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1786 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1787 is 10. 1789 Sequencing Required (ICCN, OCCN) 1791 The Sequencing Required AVP, Attribute Type 39, indicates to the 1792 LNS that Sequence Numbers MUST always be present on the data 1793 channel. 1795 This AVP has no Attribute Value field. 1797 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1798 this AVP MUST be set to 1. The Length of this AVP is 6. 1800 5.0 Protocol Operation 1802 The necessary setup for tunneling a PPP session with L2TP consists of 1803 two steps, (1) establishing the Control Connection for a Tunnel, and 1804 (2) establishing a Session as triggered by an incoming or outgoing 1805 call request. The Tunnel and corresponding Control Connection MUST be 1806 established before an incoming or outgoing call is initiated. An L2TP 1807 Session MUST be established before L2TP can begin to tunnel PPP 1808 frames. Multiple Sessions may exist across a single Tunnel and 1809 multiple Tunnels may exist between the same LAC and LNS.. 1811 +-----+ +-----+ 1812 | |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| | 1813 | LAC | | LNS | 1814 | #######Control Connection######## | 1815 [Remote] | | | | 1816 [System]------Call----------*============L2TP Session=============* | 1817 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 1818 | | | | 1819 [Remote] | | | | 1820 [System]------Call----------*============L2TP Session=============* | 1821 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 1822 | | | | 1823 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | 1824 +-----+ +-----+ 1826 Figure 5.1 Tunneling PPP 1828 5.1 Control Connection Establishment 1830 The Control Connection is the initial connection that must be 1831 achieved between an LAC and LNS before sessions may be brought up. 1832 Establishment of the control connection includes securing the 1833 identity of the peer, as well as identifying the peer's L2TP version, 1834 framing, and bearer capabilities, etc. 1836 A three message exchange is utilized to setup the control connection. 1837 Following is a typical message exchange: 1839 LAC or LNS LAC or LNS 1840 ---------- ---------- 1841 SCCRQ -> 1842 <- SCCRP 1843 SCCCN -> 1844 <- ZLB ACK 1846 The ZLB ACK is sent if there are no further messages waiting in queue 1847 for that peer. 1849 5.1.1 Tunnel Authentication 1851 L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel 1852 authentication system during control connection establishment. If 1853 an LAC or LNS wishes to authenticate the identity of the peer it 1854 is contacting or being contacted by, a Challenge AVP is included 1855 in the SCCRQ or SCCRP message. If a Challenge AVP is received in 1856 an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the 1857 following SCCRP or SCCCN, respectively. If the expected response 1858 and response received from a peer does not match, establishment of 1859 the tunnel MUST be disallowed. 1861 To participate in tunnel authentication, a single shared secret 1862 MUST exist between the LAC and LNS. This is the same shared secret 1863 used for AVP hiding (see Section 4.2). See Section 4.3.3 for 1864 details on construction of the Challenge and Response AVPs. 1866 5.2 Session Establishment 1868 After successful control connection establishment, individual 1869 sessions may be created. Each session corresponds to single PPP 1870 stream between the LAC and LNS. Unlike control connection 1871 establishment, session establishment is directional with respect to 1872 the LAC and LNS. The LAC requests the LNS to accept a session for an 1873 incoming call, and the LNS requests the LAC to accept a session for 1874 placing an outgoing call. 1876 5.2.1 Incoming Call Establishment 1878 A three message exchange is employed to setup the session. 1879 Following is a typical sequence of events: 1881 LAC LNS 1882 --- --- 1883 (Call 1884 Detected) 1886 ICRQ -> 1887 <- ICRP 1888 ICCN -> 1889 <- ZLB ACK 1891 The ZLB ACK is sent if there are no further messages waiting in 1892 queue for that peer. 1894 5.2.2 Outgoing Call Establishment 1896 A three message exchange is employed to setup the session. 1897 Following is a typical sequence of events: 1899 LAC LNS 1900 --- --- 1901 <- OCRQ 1902 OCRP -> 1904 (Perform 1905 Call 1906 Operation) 1908 OCCN -> 1909 <- ZLB ACK 1911 The ZLB ACK is sent if there are no further messages waiting in 1912 queue for that peer. 1914 5.3 Forwarding PPP Frames 1916 Once tunnel establishment is complete, PPP frames from the remote 1917 system are received at the LAC, stripped of CRC, link framing, and 1918 transparency bytes, encapsulated in L2TP, and forwarded over the 1919 appropriate tunnel. The LNS receives the L2TP packet, and processes 1920 the encapsulated PPP frame as if it were received on a local PPP 1921 interface. 1923 The sender of a message associated with a particular session and 1924 tunnel places the Session ID and Tunnel ID (specified by its peer) in 1925 the Session ID and Tunnel ID header for all outgoing messages. In 1926 this manner, PPP frames are multiplexed and demultiplexed over a 1927 single tunnel between a given LNS-LAC pair. Multiple tunnels may 1928 exist between a given LNS-LAC pair, and multiple sessions may exist 1929 within a tunnel. 1931 The value of 0 for Session ID and Tunnel ID is special and MUST NOT 1932 be used as an Assigned Session ID or Assigned Tunnel ID. For the 1933 cases where a Session ID has not yet been assigned by the peer (i.e., 1934 during establishment of a new session or tunnel), the Session ID 1935 field MUST be sent as 0, and the Assigned Session ID AVP within the 1936 message MUST be used to identify the session. Similarly, for cases 1937 where the Tunnel ID has not yet been assigned from the peer, the 1938 Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to 1939 identify the tunnel. 1941 5.4 Using Sequence Numbers on the Data Channel 1943 Sequence numbers are defined in the L2TP header for control messages 1944 and optionally for data messages (see Section 3.1). These are used to 1945 provide a reliable control message transport (see Section 5.8) and 1946 optional data message sequencing. Each peer maintains separate 1947 sequence numbers for the control connection and each individual data 1948 session within a tunnel. 1950 Unlike the L2TP control channel, the L2TP data channel does not use 1951 sequence numbers to retransmit lost data messages. Rather, data 1952 messages may use sequence numbers to detect lost packets and/or 1953 restore the original sequence of packets that may have been reordered 1954 during transport. The LAC may request that sequence numbers be 1955 present in data messages via the Sequencing Required AVP (see Section 1956 4.3.6). If this AVP is present during session setup, sequence numbers 1957 MUST be present at all times. If this AVP is not present, sequencing 1958 presence is under control of the LNS. The LNS controls enabling and 1959 disabling of sequence numbers by sending a data message with or 1960 without sequence numbers present at any time during the life of a 1961 session. Thus, if the LAC receives a data message without sequence 1962 numbers present, it MUST stop sending sequence numbers in future data 1963 messages. If the LAC receives a data message with sequence numbers 1964 present, it MUST begin sending sequence numbers in future outgoing 1965 data messages. If the LNS enables sequencing after disabling it 1966 earlier in the session, the sequence number state picks up where it 1967 left off before. 1969 The LNS may initiate disabling of sequencing at any time during the 1970 session (including the first data message sent). It is recommended 1971 that for connections where reordering or packet loss may occur, 1972 sequence numbers always be enabled during the initial negotiation 1973 stages of PPP and disabled only when and if the risk is considered 1974 acceptable. For example, if the PPP session being tunneled is not 1975 utilizing any stateful compression or encryption protocols and is 1976 only carrying IP (as determined by the PPP NCPs that are 1977 established), then the LNS might decide to disable sequencing as IP 1978 is tolerant to datagram loss and reordering. 1980 5.5 Keepalive (Hello) 1982 A keepalive mechanism is employed by L2TP in order to differentiate 1983 tunnel outages from extended periods of no control or data activity 1984 on a tunnel. This is accomplished by injecting Hello control messages 1985 (see Section 6.5) after a specified period of time has elapsed since 1986 the last data or control message was received on a tunnel. As for any 1987 other control message, if the Hello message is not reliably delivered 1988 then the tunnel is declared down and is reset. The transport reset 1989 mechanism along with the injection of Hello messages ensures that a 1990 connectivity failure between the LNS and the LAC will be detected at 1991 both ends of a tunnel. 1993 5.6 Session Teardown 1995 Session teardown may be initiated by either the LAC or LNS and is 1996 accomplished by sending a CDN control message. After the last session 1997 is cleared, the control connection MAY be torn down as well (and 1998 typically is). Following is an example of a typical control message 1999 exchange: 2001 LAC or LNS LAC or LNS 2003 CDN -> 2004 (Clean up) 2006 <- ZLB ACK 2007 (Clean up) 2009 5.7 Control Connection Teardown 2011 Control connection teardown may be initiated by either the LAC or LNS 2012 and is accomplished by sending a single StopCCN control message. The 2013 receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of 2014 the message and maintain enough control connection state to properly 2015 accept StopCCN retransmissions over at least a full retransmission 2016 cycle (in case the ZLB ACK is lost). The recommended time for a full 2017 retransmission cycle is 31 seconds (see section 5.8). Following is an 2018 example of a typical control message exchange: 2020 LAC or LNS LAC or LNS 2022 StopCCN -> 2023 (Clean up) 2025 <- ZLB ACK 2026 (Wait) 2027 (Clean up) 2029 An implementation may shut down an entire tunnel and all sessions on 2030 the tunnel by sending the StopCCN. Thus, it is not necessary to clear 2031 each session individually when tearing down the whole tunnel. 2033 5.8 Reliable Delivery of Control Messages 2035 L2TP provides a lower level reliable transport service for all 2036 control messages. The Nr and Ns fields of the control message header 2037 (see section 3.1) belong to this transport. The upper level 2038 functions of L2TP are not concerned with retransmission or ordering 2039 of control messages. The reliable control message is a sliding window 2040 transport that provides control message retransmission and congestion 2041 control. Each peer maintains separate sequence number state for the 2042 control connection within a tunnel. 2044 The message sequence number, Ns, begins at 0. Each subsequent message 2045 is sent with the next increment of the sequence number. The sequence 2046 number is thus a free running counter represented modulo 65536. The 2047 sequence number in the header of a received message is considered 2048 less than or equal to the last received number if its value lies in 2049 the range of the last received number and the preceding 32767 values, 2050 inclusive. For example, if the last received sequence number was 15, 2051 then messages with sequence numbers 0 through 15, as well as 32784 2052 through 65535, would be considered less than or equal. Such a message 2053 would be considered a duplicate of a message already received and 2054 dropped silently. 2056 All control messages take up one slot in the control message sequence 2057 number space, except the ZLB acknowledgement. Thus, Ns is not 2058 incremented after a ZLB message is sent. 2060 The last received message number, Nr, is used to acknowledge messages 2061 received by an L2TP peer. It contains the sequence number of the 2062 message the peer expects to receive next (e.g. the last Ns of a non- 2063 ZLB message received plus 1, modulo 65536). While the Nr in a 2064 received ZLB is used to flush messages from the local retransmit 2065 queue (see below), Nr of the next message sent is not be updated by 2066 the Ns of the ZLB. 2068 The reliable transport at a receiving peer is responsible for making 2069 sure that control messages are delivered in order and without 2070 duplication to the upper level. Messages arriving out of order may be 2071 queued for in-order delivery when the missing messages are received, 2072 or they may be discarded requiring a retransmission by the peer. 2074 Each tunnel maintains a queue of control messages to be transmitted 2075 to its peer. The message at the front of the queue is sent with a 2076 given Ns value, and is held until a control message arrives from the 2077 peer in which the Nr field indicates receipt of this message. After a 2078 period of time (a recommended default is 1 second) passes without 2079 acknowledgement, the message is retransmitted. The retransmitted 2080 message contains the same Ns value, but the Nr value MUST be updated 2081 with the sequence number of the next expected message. 2083 Each subsequent retransmission of a message MUST employ an 2084 exponential backoff interval. Thus, if the first retransmission 2085 occurred after 1 second, the next retransmission should occur after 2 2086 seconds has elapsed, then 4 seconds, etc. An implementation MAY place 2087 a cap upon the maximum interval between retransmissions. This cap 2088 MUST be no less than 8 seconds per retransmission. If no peer 2089 response is detected after several retransmissions, (a recommended 2090 default is 5, but SHOULD be configurable), the tunnel and all 2091 sessions within MUST be cleared. 2093 When a tunnel is being shut down for reasons other than loss of 2094 connectivity, the state and reliable delivery mechanisms MUST be 2095 maintained and operated for the full retransmission interval after 2096 the final message exchange has occurred. 2098 A sliding window mechanism is used for control message transmission. 2099 Consider two peers A & B. Suppose A specifies a Receive Window Size 2100 AVP with a value of N in the SCCRQ or SCCRP messages. B is now 2101 allowed to have up to N outstanding control messages. Once N have 2102 been sent, it must wait for an acknowledgment that advances the 2103 window before sending new control messages. An implementation may 2104 support a receive window of only 1 (i.e., by sending out a Receive 2105 Window Size AVP with a value of 1), but MUST accept a window of up to 2106 4 from its peer (e.g. have the ability to send 4 messages before 2107 backing off). A value of 0 for the Receive Window Size AVP is 2108 invalid. 2110 When retransmitting control messages, a slow start and congestion 2111 avoidance window adjustment procedure SHOULD be utilized. The 2112 recommended procedure for this is described in Appendix A. 2114 A peer MUST NOT withhold acknowledgment of messages as a technique 2115 for flow controlling control messages. An L2TP implementation is 2116 expected to be able to keep up with incoming control messages, 2117 possibly responding to some with errors reflecting an inability to 2118 honor the requested action. 2120 Appendix B contains examples of control message transmission, 2121 acknowledgement, and retransmission. 2123 6.0 Control Connection Protocol Specification 2125 The following control connection messages are used to establish, 2126 clear and maintain L2TP tunnels. All data is sent in network order 2127 (high order octets first). Any "reserved" or "empty" fields MUST be 2128 sent as 0 values to allow for protocol extensibility. 2130 6.1 Start-Control-Connection-Request (SCCRQ) 2132 Start-Control-Connection-Request (SCCRQ) is a control message used to 2133 initialize a tunnel between an LNS and an LAC. It is sent by either 2134 the LAC or the LNS to being the tunnel establishement process. 2136 The following AVPs MUST be present in the SCCRQ: 2138 Message Type AVP 2139 Protocol Version 2140 Host Name 2141 Framing Capabilities 2142 Assigned Tunnel ID 2144 The Following AVPs MAY be present in the SCCRQ: 2146 Bearer Capabilities 2147 Receive Window Size 2148 Challenge 2149 Tie Breaker 2150 Firmware Revision 2151 Vendor Name 2153 6.2 Start-Control-Connection-Reply (SCCRP) 2155 Start-Control-Connection-Reply (SCCRP) is a control message sent in 2156 reply to a received SCCRQ message. SCCRP is used to indicate that the 2157 SCCRQ was accepted and establishment of the tunnel should continue. 2159 The following AVPs MUST be present in the SCCRP: 2161 Message Type 2162 Protocol Version 2163 Framing Capabilities 2164 Host Name 2165 Assigned Tunnel ID 2167 The following AVPs MAY be present in the SCCRP: 2169 Bearer Capabilities 2170 Firmware Revision 2171 Vendor Name 2172 Receive Window Size 2173 Challenge 2174 Challenge Response 2176 6.3 Start-Control-Connection-Connected (SCCCN) 2178 Start-Control-Connection-Connected (SCCCN) is a control message sent 2179 in reply to an SCCRP. SCCCN completes the tunnel establishment 2180 process. 2182 The following AVP MUST be present in the SCCCN: 2184 Message Type 2186 The following AVP MAY be present in the SCCCN: 2188 Challenge Response 2190 6.4 Stop-Control-Connection-Notification (StopCCN) 2192 Stop-Control-Connection-Notification (StopCCN) is a control message 2193 sent by either the LAC or LNS to inform its peer that the tunnel is 2194 being shutdown and the control connection should be closed. In 2195 addition, all active sessions are implicitly cleared (without sending 2196 any explicit call control messages). The reason for issuing this 2197 request is indicated in the Result Code AVP. There is no explicit 2198 reply to the message, only the implicit ACK that is received by the 2199 reliable control message transport layer. 2201 The following AVPs MUST be present in the StopCCN: 2203 Message Type 2204 Assigned Tunnel ID 2205 Result Code 2207 6.5 Hello (HELLO) 2209 The Hello (HELLO) message is an L2TP control message sent by either 2210 peer of a LAC-LNS control connection. This control message is used as 2211 a "keepalive" for the tunnel. 2213 The sending of HELLO messages and the policy for sending them are 2214 left up to the implementation. A peer MUST NOT expect HELLO messages 2215 at any time or interval. As with all messages sent on the control 2216 connection, the receiver will return either a ZLB ACK or an 2217 (unrelated) message piggybacking the necessary acknowledgement 2218 information. 2220 Since a HELLO is a control message, and control messages are reliably 2221 sent by the lower level transport, this keepalive function operates 2222 by causing the transport level to reliably deliver a message. If a 2223 media interruption has occurred, the reliable transport will be 2224 unable to deliver the HELLO across, and will clean up the tunnel. 2226 Keepalives for the tunnel MAY be implemented by sending a HELLO if a 2227 period of time (a recommended default is 60 seconds, but SHOULD be 2228 configurable) has passed without receiving any message (data or 2229 control) from the peer. 2231 HELLO messages are global to the tunnel. The Session ID in a HELLO 2232 message MUST be 0. 2234 The Following AVP MUST be present in the HELLO message: 2236 Message Type 2238 6.6 Incoming-Call-Request (ICRQ) 2240 Incoming-Call-Request (ICRQ) is a control message sent by the LAC to 2241 the LNS when an incoming call is detected. It is the first in a three 2242 message exchange used for establishing a session within an L2TP 2243 tunnel. 2245 ICRQ is used to indicate that a session is to be established between 2246 the LAC and LNS for this call and provides the LNS with parameter 2247 information for the session. The LAC may defer answering the call 2248 until it has received an ICRP from the LNS indicating that the 2249 session should be established. This mechanism allows the LNS to 2250 obtain sufficient information about the call before determining 2251 whether it should be answered or not. Alternatively, the LAC may 2252 answer the call, negotiate LCP and PPP authentication, and use the 2253 information gained to choose the LNS. In this case, the call has 2254 already been answered by the time the ICRP message is received; the 2255 LAC simply spoofs the "call indication" and "call answer" steps in 2256 this case. 2258 The following AVPs MUST be present in the ICRQ: 2260 Message Type 2261 Assigned Session ID 2262 Call Serial Number 2264 The following AVPs MAY be present in the ICRQ: 2266 Bearer Type 2267 Physical Channel ID 2268 Calling Number 2269 Called Number 2270 Sub-Address 2272 6.7 Incoming-Call-Reply (ICRP) 2274 Incoming-Call-Reply (ICRP) is a control message sent by the LNS to 2275 the LAC in response to a received ICRQ message. It is the second in 2276 the three message exchange used for establishing sessions within an 2277 L2TP tunnel. 2279 ICRP is used to indicate that the ICRQ was successful and for the LAC 2280 to answer the call if it has not already done so. It also allows the 2281 LNS to indicate necessary parameters for the L2TP session. 2283 The following AVPs MUST be present in the ICRP: 2285 Message Type 2286 Assigned Session ID 2288 6.8 Incoming-Call-Connected (ICCN) 2290 Incoming-Call-Connected (ICCN) is a control message sent by the LAC 2291 to the LNS in response to a received ICRP message. It is the third 2292 message in the three message exchange used for establishing sessions 2293 within an L2TP tunnel. 2295 ICCN is used to indicate that the ICRP was accepted, the call has 2296 been answered, and that the L2TP session should move to the 2297 established state. It also provides additional information to the 2298 LNS about parameters used for the answered call (parameters that may 2299 not always available at the time the ICRQ is issued). 2301 The following AVPs MUST be present in the ICCN: 2303 Message Type 2304 (Tx) Connect Speed 2305 Framing Type 2307 The following AVPs MAY be present in the ICCN: 2309 Initial Received LCP CONFREQ 2310 Last Sent LCP CONFREQ 2311 Last Received LCP CONFREQ 2312 Proxy Authen Type 2313 Proxy Authen Name 2314 Proxy Authen Challenge 2315 Proxy Authen ID 2316 Proxy Authen Response 2317 Private Group ID 2318 Rx Connect Speed 2319 Sequencing Required 2321 6.9 Outgoing-Call-Request (OCRQ) 2323 Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to 2324 the LAC to indicate that an outbound call from the LAC is to be 2325 established. It is the first in a three message exchange used for 2326 establishing a session within an L2TP tunnel. 2328 OCRQ is used to indicate that a session is to be established between 2329 the LNS and LAC for this call and provides the LAC with parameter 2330 information for both the L2TP session, and the call that is to be 2331 placed 2333 An LNS MUST have received a Bearer Capabilities AVP during tunnel 2334 establishment from an LAC in order to request an outgoing call to 2335 that LAC. 2337 The following AVPs MUST be present in the OCRQ: 2339 Message Type 2340 Assigned Session ID 2341 Call Serial Number 2342 Minimum BPS 2343 Maximum BPS 2344 Bearer Type 2345 Framing Type 2346 Called Number 2348 The following AVPs MAY be present in the OCRQ: 2350 Sub-Address 2352 6.10 Outgoing-Call-Reply (OCRP) 2354 Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to 2355 the LNS in response to a received OCRQ message. It is the second in a 2356 three message exchange used for establishing a session within an L2TP 2357 tunnel. 2359 OCRP is used to indicate that the LAC is able to attempt the outbound 2360 call and returns certain parameters regarding the call attempt. 2362 The following AVPs MUST be present in the OCRP: 2364 Message Type 2365 Assigned Session ID 2367 The following AVPs MAY be present in the OCRP: 2369 Physical Channel ID 2371 6.11 Outgoing-Call-Connected (OCCN) 2373 Outgoing-Call-Connected (OCCN) is a control message sent by the LAC 2374 to the LNS following the OCRP and after the outgoing call has been 2375 completed. It is the final message in a three message exchange used 2376 for establishing a session within an L2TP tunnel. 2378 OCCN is used to indicate that the result of a requested outgoing call 2379 was successful. It also provides information to the LNS about the 2380 particular parameters obtained after the call was established. 2382 The following AVPs MUST be present in the OCCN: 2384 Message Type 2385 (Tx) Connect Speed 2386 Framing Type 2388 The following AVPs MAY be present in the OCCN: 2390 Rx Connect Speed 2391 Sequencing Required 2393 6.12 Call-Disconnect-Notify (CDN) 2395 The Call-Disconnect-Notify (CDN) message is an L2TP control message 2396 sent by either the LAC or LNS to request disconnection of a specific 2397 call within the tunnel. Its purpose is to inform the peer of the 2398 disconnection and the reason why the disconnection occurred. The peer 2399 MUST clean up any resources, and does not send back any indication of 2400 success or failure for such cleanup. 2402 The following AVPs MUST be present in the CDN: 2404 Message Type 2405 Result Code 2406 Assigned Session ID 2408 The following AVPs MAY be present in the CDN: 2410 Q.931 Cause Code 2412 6.13 WAN-Error-Notify (WEN) 2414 The WAN-Error-Notify message is an L2TP control message sent by the 2415 LAC to the LNS to indicate WAN error conditions (conditions that 2416 occur on the interface supporting PPP). The counters in this message 2417 are cumulative. This message should only be sent when an error 2418 occurs, and not more than once every 60 seconds. The counters are 2419 reset when a new call is established. 2421 The following AVPs MUST be present in the WEN: 2423 Message Type 2424 Call Errors 2426 6.14 Set-Link-Info (SLI) 2428 The Set-Link-Info message is an L2TP control message sent by the LNS 2429 to the LAC to set PPP-negotiated options. These options can change 2430 at any time during the life of the call, thus the LAC MUST be able to 2431 update its internal call information and behavior on an active PPP 2432 session. 2434 The following AVPs MUST be present in the SLI: 2436 Message Type 2437 ACCM 2439 7.0 Control Connection State Machines 2441 The control messages defined in section 6 are exchanged by way of 2442 state tables defined in this section. Tables are defined for incoming 2443 call placement, outgoing call placement, as well as for initiation of 2444 the tunnel itself. The state tables do not encode timeout and 2445 retransmission behavior, as this is handled in the underlying 2446 semantics defined in Section 5.8. 2448 7.1 Control Connection Protocol Operation 2450 This section describes the operation of various L2TP control 2451 connection functions and the Control Connection messages which are 2452 used to support them. 2454 Receipt of an invalid or malformed Control Connection message should 2455 be logged appropriately, and the control connection should be closed 2456 and restarted to ensure recovery into a known state. 2458 In several cases in the following tables, a protocol message is sent, 2459 and then a "clean up" occurs. Note that regardless of the initiator 2460 of the tunnel destruction, the reliable delivery mechanism must be 2461 allowed to run (see Section 5.8) before destroying the tunnel. This 2462 permits the tunnel management messages to be reliably delivered to 2463 the peer. 2465 Appendix B.1 contains an example of lock-step tunnel establishment. 2467 7.2 Control Connection States 2469 The L2TP control connection protocol is not distinguishable between 2470 the LNS and LAC, but is distinguishable between the originator and 2471 receiver. The originating peer is the one which first initiates 2472 establishment of the tunnel (in a tie breaker situation, this is the 2473 winner of the tie). Since either LAC or LNS can be the originator, a 2474 collision can occur. See the Tie Breaker AVP in Section 4.3.3 for a 2475 description of this and its resolution. 2477 7.2.1 Control Connection Establishment 2479 State Event Action New State 2480 ----- ----- ------ --------- 2481 idle Local Send SCCRQ wait-ctl-reply 2482 Open request 2484 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 2485 acceptable 2487 idle Receive SCCRQ, Send StopCCN, idle 2488 not acceptable Clean up 2490 idle Receive SCCRP Send StopCCN idle 2491 Clean up 2493 idle Receive SCCCN Clean up idle 2495 wait-ctl-reply Receive SCCRP, Send SCCCN, established 2496 acceptable Send tunnel-open 2497 event to waiting 2498 sessions 2500 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 2501 not acceptable Clean up 2503 wait-ctl-reply Receive SCCRQ, Clean up, idle 2504 lose tie-breaker Re-queue SCCRQ 2505 for idle state 2507 wait-ctl-reply Receive SCCCN Send StopCCN idle 2508 Clean up 2510 wait-ctl-conn Receive SCCCN, Send tunnel-open established 2511 acceptable event to waiting 2512 sessions 2514 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 2515 not acceptable Clean up 2517 wait-ctl-conn Receive SCCRP, Send StopCCN, idle 2518 SCCRQ Clean up 2520 established Local Send tunnel-open established 2521 Open request event to waiting 2522 (new call) sessions 2524 established Admin Send StopCCN idle 2525 Tunnel Close Clean up 2527 established Receive SCCRQ, Send StopCCN idle 2528 SCCRP, SCCCN Clean up 2530 idle Receive StopCCN Clean up idle 2531 wait-ctl-reply, 2532 wait-ctl-conn, 2533 established 2535 The states associated with the LNS or LAC for control connection 2536 establishment are: 2538 idle 2539 Both initiator and recipient start from this state. An initiator 2540 transmits an SCCRQ, while a recipient remains in the idle state 2541 until receiving an SCCRQ. 2543 wait-ctl-reply 2544 The originator checks to see if another connection has been 2545 requested from the same peer, and if so, handles the collision 2546 situation described in Section 5.8. 2548 When an SCCRP is received, it is examined for a compatible 2549 version. If the version of the reply is lower than the version 2550 sent in the request, the older (lower) version should be used 2551 provided it is supported. If the version in the reply is earlier 2552 and supported, the originator moves to the established state. If 2553 the version is earlier and not supported, a StopCCN MUST be sent 2554 to the peer and the originator cleans up and terminates the 2555 tunnel. 2557 wait-ctl-conn 2558 This is where an SCCCN is awaited; upon receipt, the challenge 2559 response is checked. The tunnel either is established, or is torn 2560 down if an authorization failure is detected. 2562 established 2563 An established connection may be terminated by either a local 2564 condition or the receipt of a Stop-Control-Connection- 2565 Notification. In the event of a local termination, the originator 2566 MUST send a Stop-Control-Connection-Notification and clean up the 2567 tunnel. 2569 If the originator receives a Stop-Control-Connection-Notification 2570 it MUST also clean up the tunnel. 2572 7.3 Timing considerations 2574 Due to the real-time nature of telephone signaling, both the LNS and 2575 LAC should be implemented with multi-threaded architectures such that 2576 messages related to multiple calls are not serialized and blocked. 2577 The call and connection state figures do not specify exceptions 2578 caused by timers. These are addressed in Section 5.8. 2580 7.4 Incoming calls 2582 An Incoming-Call-Request message is generated by the LAC when an 2583 incoming call is detected (for example, an associated telephone line 2584 rings). The LAC selects a Session ID and serial number and indicates 2585 the call bearer type. Modems should always indicate analog call type. 2586 ISDN calls should indicate digital when unrestricted digital service 2587 or rate adaption is used and analog if digital modems are involved. 2588 Calling Number, Called Number, and Subaddress may be included in the 2589 message if they are available from the telephone network. 2591 Once the LAC sends the Incoming-Call-Request, it waits for a response 2592 from the LNS but it does not necessarily answer the call from the 2593 telephone network yet. The LNS may choose not to accept the call if: 2595 - No resources are available to handle more sessions 2596 - The dialed, dialing, or subaddress fields do not correspond to 2597 an authorized user 2598 - The bearer service is not authorized or supported 2600 If the LNS chooses to accept the call, it responds with an Incoming- 2601 Call-Reply. When the LAC receives the Incoming-Call-Reply, it 2602 attempts to connect the call. A final call connected message from 2603 the LAC to the LNS indicates that the call states for both the LAC 2604 and the LNS should enter the established state. If the call 2605 terminated before the LNS could accept it, a Call-Disconnect-Notify 2606 is sent by the LAC to indicate this condition. 2608 When the dialed-in client hangs up, the call is cleared normally and 2609 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 2610 clear a call, it sends a Call-Disconnect-Notify message and cleans up 2611 its session. 2613 7.4.1 LAC Incoming Call States 2615 State Event Action New State 2616 ----- ----- ------ --------- 2617 idle Bearer Ring or Initiate local wait-tunnel 2618 Ready to indicate tunnel open 2619 incoming conn. 2621 idle Receive ICCN, Clean up idle 2622 ICRP, CDN 2624 wait-tunnel Bearer line drop Clean up idle 2625 or local close 2626 request 2628 wait-reply Local Clean up idle 2629 close request or 2630 Bearer line drop 2632 wait-tunnel tunnel-open Send ICRQ wait-reply 2634 wait-reply Receive ICRP, Send ICCN established 2635 acceptable 2637 wait-reply Receive ICRP, Send CDN, idle 2638 Not acceptable Clean up 2640 wait-reply Receive ICRQ Send CDN idle 2641 Clean up 2643 wait-reply Receive CDN Clean up idle 2644 ICCN 2646 wait-reply Local Send CDN, idle 2647 close request or Clean up 2648 Bearer line drop 2650 established Receive CDN Clean up idle 2652 established Receive ICRQ, Send CDN, idle 2653 ICRP, ICCN Clean up 2655 established Bearer line Send CDN, idle 2656 drop or local Clean up 2657 close request 2659 The states associated with the LAC for incoming calls are: 2661 idle 2662 The LAC detects an incoming call on one of its interfaces. 2663 Typically this means an analog line is ringing or an ISDN TE has 2664 detected an incoming Q.931 SETUP message. The LAC initiates its 2665 tunnel establishment state machine, and moves to a state waiting 2666 for confirmation of the existence of a tunnel. 2668 wait-tunnel 2669 In this state the session is waiting for either the control 2670 connection to be opened or for verification that the tunnel is 2671 already open. Once an indication that the tunnel has/was opened, 2672 session control messages may be exchanged. The first of these is 2673 the Incoming-Call-Request. 2675 wait-reply 2676 The LAC receives either a CDN message indicating the LNS is not 2677 willing to accept the call (general error or don't accept) and 2678 moves back into the idle state, or an Incoming-Call-Reply message 2679 indicating the call is accepted, the LAC sends an Incoming-Call- 2680 Connected message and enters the established state. 2682 established 2683 Data is exchanged over the tunnel. The call may be cleared 2684 following: 2685 + An event on the connected interface: The LAC sends a Call- 2686 Disconnect-Notify message 2687 + Receipt of a Call-disconnect-Notify message: The LAC cleans 2688 up, disconnecting the call. 2689 + A local reason: The LAC sends a Call-Disconnect-Notify 2690 message. 2692 7.4.2 LNS Incoming Call States 2694 State Event Action New State 2695 ----- ----- ------ --------- 2696 idle Receive ICRQ, Send ICRP wait-connect 2697 acceptable 2699 idle Receive ICRQ, Send CDN, idle 2700 not acceptable Clean up 2702 idle Receive ICRP Send CDN idle 2703 Clean up 2705 idle Receive ICCN Clean up idle 2707 wait-connect Receive ICCN Prepare for established 2708 acceptable data 2710 wait-connect Receive ICCN Send CDN, idle 2711 not acceptable Clean up 2713 wait-connect Receive ICRQ, Send CDN idle 2714 ICRP Clean up 2716 idle, Receive CDN Clean up idle 2717 wait-connect, 2718 established 2720 wait-connect Local Send CDN, idle 2721 established Close request Clean up 2723 established Receive ICRQ, Send CDN idle 2724 ICRP, ICCN Clean up 2726 The states associated with the LNS for incoming calls are: 2728 idle 2729 An Incoming-Call-Request message is received. If the request is 2730 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 2731 and the LNS remains in the idle state. If the Incoming-Call- 2732 Request message is acceptable, an Incoming-Call-Reply is sent. The 2733 session moves to the wait-connect state. 2735 wait-connect 2736 If the session is still connected on the LAC, the LAC sends an 2737 Incoming-Call-Connected message to the LNS which then moves into 2738 established state. The LAC may send a Call-Disconnect-Notify to 2739 indicate that the incoming caller could not be connected. This 2740 could happen, for example, if a telephone user accidentally places 2741 a standard voice call to an LAC resulting in a handshake failure 2742 on the called modem. 2744 established 2745 The session is terminated either by receipt of a Call-Disconnect- 2746 Notify message from the LAC or by sending a Call-Disconnect- 2747 Notify. Clean up follows on both sides regardless of the 2748 initiator. 2750 7.5 Outgoing calls 2752 Outgoing calls are initiated by an LNS and instruct an LAC to place a 2753 call. There are three messages for outgoing calls: Outgoing-Call- 2754 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 2755 sends an Outgoing-Call-Request specifying the dialed party phone 2756 number, subaddress and other parameters. The LAC MUST respond to the 2757 Outgoing-Call-Request message with an Outgoing-Call-Reply message 2758 once the LAC determines that the proper facilities exist to place the 2759 call and the call is administratively authorized. For example, is 2760 this LNS allowed to dial an international call? Once the outbound 2761 call is connected, the LAC sends an Outgoing-Call-Connected message 2762 to the LNS indicating the final result of the call attempt: 2764 7.5.1 LAC Outgoing Call States 2766 State Event Action New State 2767 ----- ----- ------ --------- 2768 idle Receive OCRQ, Send OCRP, wait-cs-answer 2769 acceptable Open bearer 2771 idle Receive OCRQ, Send CDN, idle 2772 not acceptable Clean up 2774 idle Receive OCRP Send CDN idle 2775 Clean up 2777 idle Receive OCCN, Clean up idle 2778 CDN 2780 wait-cs-answer Bearer answer, Send OCCN established 2781 framing detected 2783 wait-cs-answer Bearer failure Send CDN, idle 2784 Clean up 2786 wait-cs-answer Receive OCRQ, Send CDN idle 2787 OCRP, OCCN Clean up 2789 established Receive OCRQ, Send CDN idle 2790 OCRP, OCCN Clean up 2792 wait-cs-answer, Receive CDN Clean up idle 2793 established 2795 established Bearer line drop, Send CDN, idle 2796 Local close Clean up 2797 request 2799 The states associated with the LAC for outgoing calls are: 2801 idle 2802 If Outgoing-Call-Request is received in error, respond with a 2803 Call-Disconnect-Notify. Otherwise, allocate a physical channel and 2804 send an Outgoing-Call-Reply. Place the outbound call and move to 2805 the wait-cs-answer state. 2807 wait-cs-answer 2808 If the call is not completed or a timer expires waiting for the 2809 call to complete, send a Call-Disconnect-Notify with the 2810 appropriate error condition set and go to idle state. If a circuit 2811 switched connection is established and framing is detected, send 2812 an Outgoing-Call-Connected indicating success and go to 2813 established state. 2815 established 2816 If a Call-Disconnect-Notify is received by the LAC, the telco call 2817 MUST be released via appropriate mechanisms and the session 2818 cleaned up. If the call is disconnected by the client or the 2819 called interface, a Call-Disconnect-Notify message MUST be sent to 2820 the LNS. The sender of the Call-Disconnect-Notify message returns 2821 to the idle state after sending of the message is complete. 2823 7.5.2 LNS Outgoing Call States 2825 State Event Action New State 2826 ----- ----- ------ --------- 2827 idle Local Initiate local wait-tunnel 2828 open request tunnel-open 2830 idle Receive OCCN, Clean up idle 2831 OCRP, CDN 2833 wait-tunnel tunnel-open Send OCRQ wait-reply 2835 wait-reply Receive OCRP, none wait-connect 2836 acceptable 2838 wait-reply Receive OCRP, Send CDN idle 2839 not acceptable Clean up 2841 wait-reply Receive OCCN, Send CDN idle 2842 OCRQ Clean up 2844 wait-connect Receive OCCN none established 2846 wait-connect Receive OCRQ, Send CDN idle 2847 OCRP Clean up 2849 idle, Receive CDN, Clean up idle 2850 wait-reply, 2851 wait-connect, 2852 established 2854 established Receive OCRQ, Send CDN idle 2855 OCRP, OCCN Clean up 2857 wait-reply, Local Send CDN idle 2858 wait-connect, Close request Clean up 2859 established 2861 wait-tunnel Local Clean up idle 2862 Close request 2864 The states associated with the LNS for outgoing calls are: 2866 idle, wait-tunnel 2867 When an outgoing call is initiated, a tunnel is first created, 2868 much as the idle and wait-tunnel states for an LAC incoming call. 2869 Once a tunnel is established, an Outgoing-Call-Request message is 2870 sent to the LAC and the session moves into the wait-reply state. 2872 wait-reply 2873 If a Call-Disconnect-Notify is received, an error occurred, and 2874 the session is cleaned up and returns to idle. If an Outgoing- 2875 Call-Reply is received, the call is in progress and the session 2876 moves to the wait-connect state. 2878 wait-connect 2879 If a Call-Disconnect-Notify is received, the call failed; the 2880 session is cleaned up and returns to idle. If an Outgoing-Call- 2881 Connected is received, the call has succeeded and the session may 2882 now exchange data. 2884 established 2885 If a Call-Disconnect-Notify is received, the call has been 2886 terminated for the reason indicated in the Result and Cause Codes; 2887 the session moves back to the idle state. If the LNS chooses to 2888 terminate the session, it sends a Call-Disconnect-Notify to the 2889 LAC and then cleans up and idles its session. 2891 7.6 Tunnel Disconnection 2893 The disconnection of a tunnel consists of either peer issuing a 2894 Stop-Control-Connection-Notification. The sender of this Notification 2895 should wait a finite period of time for the acknowledgment of this 2896 message before releasing the control information associated with the 2897 tunnel. The recipient of this Notification should send an 2898 acknowledgment of the Notification and then release the associated 2899 control information. 2901 When to release a tunnel is an implementation issue and is not 2902 specified in this document. A particular implementation may use 2903 whatever policy is appropriate for determining when to release a 2904 control connection. Some implementations may leave a tunnel open for 2905 a period of time or perhaps indefinitely after the last session for 2906 that tunnel is cleared. Others may choose to disconnect the tunnel 2907 immediately after the last user connection on the tunnel disconnects. 2909 8.0 L2TP Over Specific Media 2911 L2TP is self-describing, operating at a level above the media over 2912 which it is carried. However, some details of its connection to media 2913 are required to permit interoperable implementations. The following 2914 sections describe details needed to permit interoperability over 2915 specific media. 2917 8.1 L2TP over UDP/IP 2919 L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP 2920 packet, including payload and L2TP header, is sent within a UDP 2921 datagram. The initiator of an L2TP tunnel picks an available source 2922 UDP port (which may or may not be 1701), and sends to the desired 2923 destination at port 1701. The recipient picks a free port on its own 2924 system (which may or may not be 1701), and sends its reply to the 2925 initiator's UDP port, setting its own UDP source port to the free 2926 port it found. Once the source and destination ports are established, 2927 they MUST remain static for the life of the tunnel. 2929 IP fragmentation may occur as the L2TP packet travels over the IP 2930 substrate. L2TP makes no special efforts to optimize this. A LAC 2931 implementation MAY cause its LCP to negotiate for a specific MRU, 2932 which could optimize for LAC environments in which the MTU's of the 2933 path over which the L2TP packets are likely to travel have a 2934 consistent value. 2936 The default for any L2TP implementation is that UDP checksums MUST be 2937 enabled for both control and data messages. An L2TP implementation 2938 MAY provide an option to disable UDP checksums for data messages. It 2939 is recommended that UDP checksums always be enabled on control 2940 packets. 2942 Port 1701 is used for both L2F [RFC2341] and L2TP packets. The 2943 Version field in each header may be used to discriminate between the 2944 two packet types (L2F uses a value of 1, and L2TP as described in 2945 this document uses a value of 2). An L2TP implementation running on a 2946 system which does not support L2F MUST silently discard all L2F 2947 packets. 2949 To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has 2950 the characteristic of being able to reorder or silently drop packets. 2951 The former may break non-IP protocols being carried by PPP, 2952 especially LAN-centric ones such as bridging. The latter may break 2953 protocols which assume per-packet indication of error, such as TCP 2954 header compression. Sequencing may be handled by using L2TP data 2955 message sequence numbers if any protocol being transported by the PPP 2956 tunnel cannot tolerate reordering. The sequence dependency 2957 characteristics of individual protocols are outside the scope of this 2958 document. 2960 Allowing packets to be dropped silently is perhaps more problematic 2961 with some protocols. If PPP reliable delivery [RFC1663] is enabled, 2962 no upper PPP protocol will encounter lost packets. If L2TP sequence 2963 numbers are enabled, L2TP can detect the packet loss. In the case of 2964 an LNS, the PPP and L2TP stacks are both present within the LNS, and 2965 packet loss signaling may occur precisely as if a packet was received 2966 with a CRC error. Where the LAC and PPP stack are co-resident, this 2967 technique also applies. Where the LAC and PPP client are physically 2968 distinct, the analogous signaling MAY be accomplished by sending a 2969 packet with a CRC error to the PPP client. Note that this would 2970 greatly increase the complexity of debugging client line problems, 2971 since the client statistics can not distinguish between true media 2972 errors and LAC-initiated ones. This technique is also not possible on 2973 all hardware. 2975 If VJ comprssion is used, and neither PPP reliable delivery nor 2976 sequence numbers are enabled, each lost packet results in a 1 in 2977 2**16 chance of a TCP segment being forwarded with incorrect contents 2978 [RFC1144]. Where the combination of the packet loss rate with this 2979 statistical exposure is unacceptable, TCP header compression SHOULD 2980 NOT be used. 2982 In general, it is wise to remember that the L2TP/UDP/IP transport is 2983 an unreliable transport. As with any PPP media that is subject to 2984 loss, care should be taken when using protocols that are particularly 2985 loss-sensitive. Such protocols include compression and encryption 2986 protocols that employ history. 2988 8.2 IP 2990 When operating in IP environments, L2TP MUST offer the UDP 2991 encapsulation described in 8.1 as its default configuration for IP 2992 operation. Other configurations (perhaps corresponding to a 2993 compressed header format) MAY be defined and made available as a 2994 configurable option. 2996 9.0 Security Considerations 2998 L2TP encounters several security issues in its operation. The 2999 general approach of L2TP to these issues is documented here. 3001 9.1 Tunnel Endpoint Security 3003 The tunnel endpoints may optionally perform an authentication 3004 procedure of one another during tunnel establishment. This 3005 authentication has the same security attributes as CHAP, and has 3006 reasonable protection against replay and snooping during the tunnel 3007 establishment process. This mechanism is not designed to provide any 3008 authentication beyond tunnel establishment; it is fairly simple for a 3009 malicious user who can snoop the tunnel stream to inject packets once 3010 an authenticated tunnel establishment has been completed 3011 successfully. 3013 For authentication to occur, the LAC and LNS MUST share a single 3014 secret. Each side uses this same secret when acting as authenticatee 3015 as well as authenticator. Since a single secret is used, the tunnel 3016 authentication AVPs include differentiating values in the CHAP ID 3017 fields for each message digest calculation to guard against replay 3018 attacks. 3020 The Assigned Tunnel ID and Assigned Session ID (See Section 4.3.3) 3021 SHOULD be selected in an unpredictable manner rather than 3022 sequentially or otherwise. Doing so will help to deter hijacking of 3023 a session by a malicious user who does not have access to packet 3024 traces between the LAC and LNS. 3026 For L2TP tunnels over IP, IPSEC [RFC2401] provides very strong 3027 protection of the tunnel. This requires no modification to the L2TP 3028 protocol, and leverages extensive IETF work in this area. 3030 9.2 Proxy PPP Authentication 3032 L2TP defines AVPs that MAY be exchanged during session establishment 3033 to provide forwarding of PPP authentication information obtained at 3034 the LAC to the LNS for validation (see Section 4.3.5). This implies a 3035 direct trust relationship of the LAC on behalf of the LNS. If the 3036 LNS chooses to implement proxy authentication, it MUST be able to be 3037 configured off, requiring a new round a PPP authentication initiated 3038 by the LNS (which may or may not include a new round of LCP 3039 negotiation). 3041 10.0 IANA Considerations 3043 This document defines a number of "magic" numbers to be maintained by 3044 the IANA. This section explains the criteria to be used by the IANA 3045 to assign additional numbers in each of these lists. The following 3046 subsections describe the assignment policy for the namespaces defined 3047 elsewhere in this document. 3049 10.1 AVP Attributes 3051 As defined in Section 4.1, AVPs contain vendor ID, Attribute and 3052 Value fields. For vendor ID value of 0, IANA will maintain a registry 3053 of assigned Attributes and in some case also values. Attributes 0-39 3054 are assigned as defined in Section 4.3. The remaining values are 3055 available for assignment through IETF Consensus [RFC 2434]. 3057 10.2 Message Type AVP Values 3059 As defined in Section 4.3.1, Message Type AVPs (Attribute Type 0) 3060 have an associated value maintained by IANA. Values 0-16 are defined 3061 in Section 3.2, the remaining values are available for assignment via 3062 IETF Consensus [RFC 2434] 3064 10.3 Result Code AVP Values 3066 As defined in Section 4.3.2, Result Code AVPs (Attribute Type 1) 3067 contain three fields. Two of these fields (the Result Code and Error 3068 Code fields) have associated values maintained by IANA. 3070 10.3.1 Result Code Field Values 3072 The Result Code AVP may be included in CDN and StopCCN messages. The 3073 allowable values for the Result Code field of the AVP differ 3074 depending upon the value of the Message Type AVP. For the StopCCN 3075 message, values 0-7 are defined in Section 4.3.2; for the StopCCN 3076 message, values 0-11 are defined in the same section. The remaining 3077 values of the Result Code field for both messages are available for 3078 assignment via IETF Consensus [RFC 2434]. 3080 10.3.1 Error Code Field Values 3082 Values 0-7 are defined in Section 4.3.2. Values 8-32767 are 3083 available for assignment via IETF Consensus [RFC 2434]. The remaining 3084 values of the Error Code field are available for assignment via First 3085 Come First Served [RFC 2434]. 3087 10.4 Framing Capabilities & Bearer Capabilities 3089 The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in 3090 Section 4.3.3) both contain 32-bit bitmasks. Additional bits should 3091 only be defined via a Standards Action [RFC 2434]. 3093 10.5 Proxy Authen Type AVP Values 3095 The Proxy Authen Type AVP (Attribute Type 29) has an associated value 3096 maintained by IANA. Values 0-5 are defined in Section 4.3.5, the 3097 remaining values are available for assignment via First Come First 3098 Served [RFC 2434]. 3100 10.6 AVP Header Bits 3102 There are four remaining reserved bits in the AVP header. Additional 3103 bits should only be assigned via a Standards Action [RFC 2434]. 3105 11.0 References 3107 [DSS1]ITU-T Recommendation, "Digital subscriber Signaling System No. 1 3108 (DSS 1) - ISDN user-network interface layer 3 specification for 3109 basic call control", Rec. Q.931(I.451), May 1998 3111 [KPS]Kaufman, C., Perlman, R., and Speciner, M., "Network Security: 3112 Private Communications in a Public World", Prentice Hall, March 3113 1995, ISBN 0-13-061466-1 3115 [PPTP]K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn, 3116 "Point-to-Point Tunneling Protocol (PPTP)", ``work in progress'', 3117 October 1998 3119 [RFC791] 3120 Postel, J., Internet Protocol, STD 5, RFC 791, September 1981 3122 [RFC1034] 3123 Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, 3124 RFC 1034, November 1987 3126 [RFC1144] 3127 Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial 3128 Links", RFC 1144, February 1990 3130 [RFC1661] 3131 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 3132 July 1994 3134 [RFC1662] 3135 Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 3136 1994 3138 [RFC1663] 3139 Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994 3141 [RFC1700] 3142 Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 3143 October 1994 3145 [RFC1990] 3146 Sklower, K., et al., "The PPP Multilink Protocol (MP)", RFC 1990, 3147 August 1996 3149 [RFC1994] 3150 Simpson, W., "PPP Challenge Handshake Authentication Protocol 3151 (CHAP)", RFC 1994, August 1996 3153 [RFC1918] 3154 Rekhter, Y., et al., Address Allocation for Private Internets, BCP 3155 5, RFC 1918, February 1996 3157 [RFC2119] 3158 Bradner, S., "Key words for use in RFCs to Indicate Requirement 3159 Levels", BCP 14, RFC 2119, March 1997 3161 [RFC2138] 3162 Rigney, C., et al., "Remote Authentication Dial In User Service 3163 (RADIUS)", RFC 2138, April 1997 3165 [RFC2277] 3166 Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 3167 18, RFC 2277, January 1998 3169 [RFC2341] 3170 Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two Forward- 3171 ing (Protocol) L2F", RFC 2341, May 1998 3173 [RFC2434] 3174 Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Con- 3175 siderations Section in RFCs", BCP 26, RFC 2434, October 1998 3177 [RFC2401] 3178 Kent, S., Atkinson, R., "Security Architecture for the Internet 3179 Protocol", RFC 2401, November 1998 3181 [STEVENS] 3182 Stevens, W. Richard, "TCP/IP Illustrated, Volume I The Protocols", 3183 Addison-Wesley Publishing Company, Inc., March 1996, ISBN 3184 0-201-63346-9 3186 12.0 Acknowledgments 3188 The basic concept for L2TP and many of its protocol constructs were 3189 adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A. 3190 Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, 3191 J. Taarud, W. Little, and G. Zorn. 3193 Dory Leifer made valuable refinements to the protocol definition of 3194 L2TP and contributed to the editing of this document. 3196 Steve Cobb and Evan Caves redesigned the state machine tables. 3198 Barney Wolff provided a great deal of design input on the endpoint 3199 authentication mechanism. 3201 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 3202 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and 3203 review at the 43rd IETF in Orlando, FL., which led to improvement of 3204 the overall readability and clarity of this document. 3206 13.0 Author's Addresses 3208 Gurdeep Singh Pall 3209 Microsoft Corporation 3210 Redmond, WA 3211 gurdeep@microsoft.com 3213 Bill Palter 3214 RedBack Networks, Inc 3215 1389 Moffett Park Drive 3216 Sunnyvale, CA 94089 3217 palter@zev.net 3219 Allan Rubens 3220 Ascend Communications 3221 1701 Harbor Bay Parkway 3222 Alameda, CA 94502 3223 acr@del.com 3225 W. Mark Townsley 3226 cisco Systems 3227 7025 Kit Creek Road 3228 PO Box 14987 3229 Research Triangle Park, NC 27709 3230 townsley@cisco.com 3232 Andrew J. Valencia 3233 cisco Systems 3234 170 West Tasman Drive 3235 San Jose CA 95134-1706 3236 vandys@cisco.com 3238 Glen Zorn 3239 Microsoft Corporation 3240 One Microsoft Way 3241 Redmond, WA 98052 3242 gwz@acm.org 3244 Appendix A: Control Channel Slow Start and Congestion Avoidance 3246 Although each side has indicated the maximum size of its receive win- 3247 dow, it is recommended that a slow start and congestion avoidance 3248 method be used to transmit control packets. The methods described 3249 here are based upon the TCP congestion avoidance algorithm as 3250 described in section 21.6 of TCP/IP Illustrated, Volume I, by W. 3251 Richard Stevens [STEVENS]. 3253 Slow start and congestion avoidance make use of several variables. 3254 The congestion window (CWND) defines the number of packets a sender 3255 may send before waiting for an acknowledgment. The size of CWND 3256 expands and contracts as described below. Note however, that CWND is 3257 never allowed to exceed the size of the advertised window obtained 3258 from the Receive Window AVP (in the text below, it is assumed any 3259 increase will be limited by the Receive Window Size). The variable 3260 SSTHRESH determines when the sender switches from slow start to 3261 congestion avoidance. Slow start is used while CWND is less than 3262 SSHTRESH. 3264 A sender starts out in the slow start phase. CWND is initialized to 3265 one packet, and SSHTRESH is initialized to the advertised window 3266 (obtained from the Receive Window AVP). The sender then transmits 3267 one packet and waits for its acknowledgement (either explicit or pig- 3268 gybacked). When the acknowledgement is received, the congestion win- 3269 dow is incremented from one to two. During slow start, CWND is 3270 increased by one packet each time an ACK (explicit ZLB or pig- 3271 gybacked) is received. Increasing CWND by one on each ACK has the 3272 effect of doubling CWND with each round trip, resulting in an 3273 exponential increase. When the value of CWND reaches SSHTRESH, the 3274 slow start phase ends and the congestion avoidance phase begins. 3276 During congestion avoidance, CWND expands more slowly. Specifically, 3277 it increases by 1/CWND for every new ACK received. That is, CWND is 3278 increased by one packet after CWND new ACKs have been received. Win- 3279 dow expansion during the congestion avoidance phase is effectively 3280 linear, with CWND increasing by one packet each round trip. 3282 When congestion occurs (indicated by the triggering of a retransmis- 3283 sion) one half of the CWND is saved in SSTHRESH, and CWND is set to 3284 one. The sender then reenters the slow start phase. 3286 Appendix B: Control Message Examples 3288 B.1: Lock-step tunnel establishment 3290 In this example, an LAC establishes a tunnel, with the exchange 3291 involving each side alternating in sending messages. This example 3292 is contrived, in that the final acknowledgment in the example is 3293 explicitly sent within a zero-length message, although most typi- 3294 cally the acknowledgment would have been included in the process- 3295 ing of the Incoming-Call-Request which had prompted the LAC to 3296 initiate the tunnel in the first place. 3298 LAC or LNS LNS or LAC 3299 ---------- ---------- 3301 SCCRQ -> 3302 Nr: 0, Ns: 0 3303 <- SCCRP 3304 Nr: 1, Ns: 0 3305 SCCCN -> 3306 Nr: 1, Ns: 1 3307 <- ZLB 3308 Nr: 2, Ns: 1 3310 B.2: Lost packet with retransmission 3312 An existing tunnel has a new session requested by the LAC. The ICRP 3313 is lost and must be retransmitted by the LNS. Note that loss of the 3314 ICRP has two impacts: not only does it keep the upper level state 3315 machine from progressing, but it also keeps the LAC from seeing a 3316 timely lower level acknowledgment of its ICRQ. 3318 LAC LNS 3319 --- --- 3321 ICRQ -> 3322 Nr: 1, Ns: 2 3323 (packet lost) <- ICRP 3324 Nr: 3, Ns: 1 3326 (pause; LAC's timer started first, so fires first) 3328 ICRQ -> 3329 Nr: 1, Ns: 2 3331 (LNS realizes it has already seen this 3332 packet and discards it.) 3334 (LNS's timer fires.) 3336 <- ICRP 3337 Nr: 3, Ns: 1 3338 ICCN -> 3339 Nr: 2, Ns: 3 3341 <- ZLB 3342 Nr: 4, Ns: 2